assert and report

As you are writing your VHDL models for the instruction interpreter, you may find that you want to print things out to the screen.  Viewing signals is great, but at times you may want to know if code is executing or grab the value of variable.  There are two commands that will help with this.

report "message"; - will print a message to the simulator output during execution.  This is handy to display information during execution.  The string value can be any string value, including strings containing simulation data.  Thus, you can print the value of variables during execution.

assert condition; - will abort execution if condition is false when it is executed.  By itself, this is not much fun to use.  However, the following is:

assert condition report message;

This command will not do anything if executed and condition is true.  However, if it is false it will terminate and report message to the output.  If you want to get fancy, you can also use a severity indicator:

assert condition report message severity severity_level;

where severity_level is either note, warning, error, or failure.  In most simulators, if you use note or warning, the assertion will not cause the simulator to abort and just produce the error.  Either error or failure will cause the simulation to abort.

For more info, look in the index of the Ashenden book under either report or assert.

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.
0