1. Register Transfer Language Specification
Now that your assembly language and machine language specifications are complete, you should describe how you plan to implement your instruction set at the register transfer level (RTL).
Your first step in this process is to break each instruction into small steps. Each step should be of roughly equal size (i.e. they should take about the same amount of time to complete) and move data from one register to another. Complete the process by grouping steps that can be completed in parallel in a single clock cycle. Be sure to look for common steps across all of your instructions. Exploiting these can simplify your implementation.
Next, list and describe the components that will be needed to implement your RTL (e.g. "S/E is a combinational logic unit that sign-extends an 8-bit input to produce a 16-bit output").
Do not describe how the parts are connected; you just need build a 'shopping list' of generic parts (i.e. PC, IR, and ALUout are all registers). For this milestone, you are only interested in the components that are clearly needed by the RTL (so probably no muxes).
Note: Xilinx block memory does not output values from memory until the rising edge of the clock (i.e. it is synchronous). This is different from the assumption that the book makes about memory!
Be aware that your RTL specification directly impacts performance
(execution time) of and resources (the number of gates) required to
implement your design. Specifically the time required to complete the
longest step determines the cycle time (clock frequency) and the
number of groups required to complete an instruction determines the
This is most important for designs that divide instructions into multiple stages (multi-cycle).
If you plan on doing single-cycle, you don't need registers between the stages. Instead, just indicate that wires are holding information between the stages.
That is, instead of having your instruction in
IR, you might have your instruction on the
You may modify your assembly language and machine language specifications for this milestone. In fact, time spent getting the instruction set architecture correct for this milestone will save you lots of time later. Please note any changes and why they were made in your design process journal.
Do not build any datapath or control for this milestone. You need to verify your RTL is robust before continuing.
You will model, test, and debug your complete processor using the Xilinx ISE design suite. It is highly recommended that you begin implementing and testing individual components in a bottom-up manner now.
2. Turning in M2
For this milestone, you will submit the following:
An updated design document, that includes the following:
An RTL description of each instruction or set of related instructions. You should include a summary chart similar to the ones discussed in class.
A list of generic components specifications needed to implement your register transfer language (these will eventually make up your datapath). For each component give:
A list of input signals, output signals, and control signals including the number of bits in each signal.
An unambiguous English description of how the component's output will change according to its input and control signals.
A list of the RTL symbols that this component will implement. For example, a generic register component might implement both the 'PC' and 'ALUout' RTL symbols.
Now that you have RTL, you can use it to design the datapath in the next milestone. However, if your RTL has errors, it will cause your datapath to be incorrect. Go back and verify that your RTL correct.
- Give a brief overview of your process for double-checking the RTL for errors.
A note of changes made to the Assembly language and Machine language specifications.
An updated design process journal for each team member, including:
- your thought processes and rationale behind your decisions and .
- 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 design document should be updated in the
Design directory of your team's
The names of your design document and design journals should not change.