New models posted

I've just posted a new set of models for the KURM on the Resources Page. The sign extend components are included and some modifications have been made to the controller and datapath.

Memory issues

Some of you have reported problems with the 2 port memory crashing. The TAs have reported to me that you must initialize inputs to the model when your simulation starts. Specifically, the addresses and read/write strobes. Setting them to 0 is the simplest thing to do.

Controller and datapath update

I just pushed up a replacement for the data path posted earlier today. The new zip file contains both a data path and a controller. As a reminder, I would prefer that you use your designs for Project 5 if you were successful, or nearly successful with Project 4. Please watch the blog for further updates.

Data path for Project 5

I have posted a data path model from Vijay to the Resources Page that you may use for Project 5 if you did not get Project 4 working. I would prefer that you use your own data path, but you may use this one if you would rather not spend more time debugging Project 4.

Project 5

I've finally posted a brief description of Project 5. It is as you expect - synthesize results from Project 4. You'll need to update your model to use the 2 port memory and then use the Xilinx tools to synthesize the entire model to the XUP board. The trick, as always, will be testing.

The TAs are working on a Project 4 model for you to use if you did not get Project 4 working completely. I will let you know when that becomes available.

I've not assigned a due date for this lab yet. We'll talk about that in class Thursday.

Project 4 library pushed up

The library for Project 4 is now available on the Resources Page. This is the same library that you used for Project 3 with an example ALU and register file in case you did not get your behavioral models working for Project 3. You can just as easily use your models as the models provided in the library.

Project 4 due date

As I outlined in class, Project 4 will be due starting April 21. Remember that it is a simulation only lab.

Simplification for Projects 4 and 5

I've decided to make a couple of simplifications of KURM09 for Projects 4 and 5.

First, you do not need to implement conditional instructions. Recall that conditional instructions (addc, subc, etc) only execute if the status register is non-zero and are no-ops otherwise. Thus, the only instruction that will look at the status register is bra and we covered that instruction in class. I don't think we've discussed them sufficiently in class for me to ask you to implement them and it should simplify the last two labs a bit.

Second, the status register will be updated after every instruction. This simply means that the status register is clocked and will never be disabled. Note that bra does not access the register file in any defined way. Thus, the contents of the status register can be any value after bra executes. In effect, status register values for the next state after bra are don't cares.

Hopefully these changes will simplify things by making the enable logic for the register file and the status register simpler. The status register is no longer involved in determining when the register file should be enabled and the status register is now always enabled.

Project 4 available

Project 4 is now available from the Laboratory Page. The objective of the lab is to design a data path exactly like the one we've been talking about in class.

To things to note. First, it is a simulation only lab - no synthesis this time around. Second, the library for designing your data path will be available after completing Project 3. The only difference between the Project 4 and Project 3 libraries is the inclusion of ALU and register file models. If you want to use your own models for those components, feel free to do so.

Combinational not Sequential ALU

The project 3 description specifies a sequential ALU. It should be combinational. Also, the VHDL skeleton uses a control input with 3 values (2 downto 0). Only two are required. I have posted an updated project description should you want to download a new version. However, these are the only changes.

Project 3 due date

Project 3 due date is the week starting April 7. Note that the Monday lab is still a week behind.

Project 3 due date

Project 3 due date is the week starting April 7. Note that the Monday lab is still a week behind.

Project 3 due date

Project 3 due date is the week starting April 7. Note that the Monday lab is still a week behind.

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.

Laboratory 1

The schedule for performing Project 1 is now on the Project 1 page. Basically, you'll go over it in lab starting January 27 and demonstrate it the following week. (Note that the Monday lab is a week behind, thus the Tuesday start date.)
0