Conditional insructions

Some of you have been asking the TAs what to do with the remaining 7 op codes give that we only have 9 instructions and 4 bits to describe them.  We have 7 conditional instructions that we've not discussed yet.  Basically, they are identical to unconditional instructions, but will execute only when the status nybble is not zero.  See the bottom of page 3 of the ISA for more information, but modeling them simply requires: (i) an IF statement around your unconditional definition; or (ii) copying the unconditional operation and making the copy conditional.

I plan to talk about this in class tomorrow, but some of you beat me to it and started asking questions.

Project 2 due date

Project 2 will be due in lab starting March 3.

XUP Board damange

The XUP boards in lab are getting torn up pretty badly. In particular, the USB ports are being popped off and the FLASH card ports damaged. Please be careful with the boards. In particular, don't pack them back up in their boxes after lab and try to avoid connecting and reconnecting the USB cable. Use the power switch to cycle them rather than the cable.

If you find any damage on a board, please report it to your TA asap. It's much easier for the shop to repair boards if problems are reported early.

Homework 2 Due date

The due date for Homework 2 is now officially February 19 in class.

Homework 2 is posted

Homework 2 is available on the Homework Page.  No due date is assigned, but it will almost certainly be Thursday, February 19.

PC' vs PC

In my writeup describing the KURM09 ISA, I frequently use the notation R' where R is a register, the PC or some variable.  This notation refers to the value of R in the next state.  So, when I say PC':=PC+2 when describing an instruction, I'm saying that the next value of the program counter is the current value plus 2.

This is different from software where the concept of state is hidden.  For example:

x = 1;
x = x+1;

in the software world results in a state where x=2.  However, the concept of state is hidden - we change state when each statement is executed.  In hardware, the state change must be explicit.  Thus, my use of R'.

The work package

Some of you have asked what work means in the notation:

work.mux41(beh)

All VHDL models must exist in a package.  Rather than force us to create new packages for every model, our tools provide a default package called work.  If you don't tell VHDL what package to put your designs in, they automatically go into the work package.  Thus, the above notation says to look in the work package for the beh architecture of the mux41 entity.

Project 1 thoughts

Some random thoughts on Project 1...

As many of you are realizing, just because a model simulates does not imply that it will synthesize.  Hardware synthesis is a different beast than program compilation.  The form of your model directly impacts the quality of the synthesis result.  Plus, you need more information to synthesize than to simulate.  Leave plenty of time for synthesis when you are doing your labs.

The hard problem from Project 1 is the grey code counter.  I talked to several folks about it in office hours and have a couple of thoughts to make the problem simpler.

1. Design separate circuits for counting up and counting down.  Feed the output of the state register into both circuits.  Then use a MUX and the count signals to select the "up" value or the "down" value.

2. Route enable and load directly to the appropriate signals on the register.  You don't need to include them in your truth table. If you do the design this way.

3. You'll need a number of MUXes to build the combinational circuits in your final design.  Build larger MUXes from smaller MUXes in their own model.  Then reuse that model throughout your design.



Project 2

Project 2 is up on the class website.  I realize everyone is in the midst of Project 1, but I pushed the project up for the TAs and thought I would make it available for everyone.  It is a simulation-only lab where you will develop an instruction interpreter.  Due date is not set.

Project 1 due dates

Project 1 will be due in your lab section starting Tuesday, February 10.  You must submit your lab report and demo your synthesis results in the laboratory section you are enrolled in unless you have permission from me not to.

I should be getting lab codes sometime next week, but the simulation tools are available on machines in the computing commons.  Thus, you can get your simulations running well before your lab section meets.
0