Milestone 3

1. Multi-cycle RTL

For this milestone, you will design multi-cycle RTL for your instruction set. Follow the process from class where we split up the single-cycle RTL by steps that can be completed in parallel during a single clock cycle without major dependencies. Be sure to look for common steps across all of your instructions. Exploiting these common steps can simplify a multicycle hardware implementation.

Note that some things that used to be wires must now be registers to save the values across clock cycles. For example inst became IR in class and changed from a wire to a register.

1.1 Multi-Cycle Components List

Like in M2, you now must create a components list for your multicycle RTL. You can begin by making a copy of what you had for single-cycle, but you will possibly need to add or remove components and change the control signals. EVERY Symbol of your multi-cycle RTL must appear in the new components list.

2. Datapath Design

Choose either your multicycle or single-cycle RTL for this next step.

Your chosen RTL description contains all of the information about how the data flows through your processor. Your next step is to use that information to draw a block diagram of your datapath. Do not use Quartus to create this diagram, you can use any software you wish to draw this diagram (some students use draw.io or Microsoft Visio).

The block diagram should include the components identified in your components list for your chosen single- or multi-cycle RTL.
When a component's input might come from more than one source, the diagram should show a multiplexer to select between the sources. The diagram should also show the control signals for the components, including the multiplexers. Once the block diagram is complete, you should list all of the control signals and describe them.

3. Project setup

You should set up the Quartus project for your processor this milestone. One person on your team should create a project in your git repo. In that project create one Verilog file for each component in your generic component list. Additionally add a test bench file for each component.

These files can be totally empty at this point, they should just be named clearly.

After all the files are committed you should commit the entire project to github, you need to add all the .v files as well as the Quartus project files (.qpf .qsf .qws). DO NOT add the other intermediate files to your repo (e.g. .bpm .cdb .hdb). If you add these then you will have many merge conflicts in your future.

After this is committed ensure that others on your team can pull the project an open it in Quartus.

Moving forward, when you make edits you will only be changing the .v files. After you make changes you should git add only those Verilog files you directly edited.

If you add new files to the project you will need to git add the Quartus project files again. That is the only time you should add these files. As soon as you commit these files everyone on your team should do a pull so that they do not have merge conflicts on the project files.

4. Testing

Since the datapath will invariably involve a large number of components, inputs, outputs and busses, it is important to have an comprehensive test plan. There are three levels of testing. Testing each component of the datapath (unit testing), testing small groups of components and subsystems as they are built up (integration testing) and finally testing the entire datapath (system testing). A good approach is to test bottom-up from individual components to small groups of components to subsystems and so on.

4.1. Unit Testing:

Every component must be tested. Most combinational logic components will be small enough to test exhaustively. Test cases for sequential logic components should ensure that they satisfy the state transition and output behavior required to implement the RTL specifications (including timing considerations). For this milestone, include a test plan to test each component. Your plan should specify inputs, wait times, and expected outputs for each suite of tests. The description should be detailed enough that someone unfamiliar with your hardware could take your test plan and write the testbench with no other context.

4.2. Integration plan and testing:

Once individual components have been tested, you should develop a plan to combine them into smaller subsystems in your datapath. These subsystems should be combined to form larger parts of your datapath. Continue describing how to combine these datapath subsystems into the full datapath.

For each step in your integration plan, define a set of tests to verify the datapath subsystem is designed and implemented correctly. You could have many levels of integration and testing before reaching the full datapath. Carefully consider your design when making your integration plan so that you minimize integration and testing time, while maximizing ease of integration and correctness. You should include a version of your datapath that highlights each subsystem you plan on testing.

5. Other

Now that you have a datapath, you can identify the control bits needed by the datapath. Add the control unit(s) to your list of components. Be sure to note the input, output, and control bits, as well as to describe the basic function of the unit. It may be useful to have a 'reset' control bit on the control unit, to help initialize the processor. Do not specify the logic of the control unit! You will design the logic in a later milestone, after the datapath has been reviewed.

You should be building the components you defined in Milestone 2. It is highly recommended that you implement your datapath from the bottom up by incrementally by building up subsystems from individual components. At this stage, simply leave the control signals as inputs that you can specify during testing.

You may modify your register transfer language specification, during the datapath design, but not your assembly language or machine language specifications (unless you obtain instructor approval). If you do change your RTL, make sure that your unit tests are still valid, and your integration tests are for your new RTL.

6. Turning in M3

For this milestone, submit the following:

  1. Update your design document with Multi-Cycle RTL and components.
  1. Choose either single- or multi-cycle, and update your design document with:
  1. Update your design document to explain how you will gradually implement your datapath. Include:

  1. A partial implementation in your Implementation directory:

    • Complete implementations of some components, built according to your spec in Milestone 2.
    • Tests for some components, designed according to your spec in this Milestone.

  2. Updated design journals. For this milestone, you might include things like:

    • A discussion of your strategy for creating tests.
    • If you found any errors while testing, indicate what they were and how you fixed them here.
    • Describe how your choice in architecture affected your datapath design and component specification.
    • You should be keeping a log of how you deal with isses you run into while using Quartus and ModelSim. This is so you can go look at your own notes when you run into a similar problem again.

  3. An updated individual itemized log of each member's work for the week and an estimated work time for each item. Each member is responsible for their own log.

Your (updated) design document and (updated) design process journals should be committed to git in the Design directory of your team's repository.

Your implementation files should be placed in the Implementation directory of your team's repository. You should have most of the individual components completed for this milestone, and should be beginning to unit test as you design integration tests.

The names of your design document and design process journal should not change.