Assignment 01 Computer Architecture Lab ECSE

Transcription

1 Assignment 01 Computer Architecture Lab ECSE Date due: September 22, 2006, Trottier Assignment Box by 14:30 1 Introduction The purpose of this assignment is to re-familiarize the student with VHDL and to learn how to use industrial electronic design automation(eda) software such as ModelSim for simulation and Precision RTL for synthesis. The arithmetic logic unit (ALU) is a core component of any CPU. The ALU performs arithmetic operations such as addition and subtraction and boolean operations such as and and or. You can read more about the ALU by following this Wikipedia link or by referencing a textbook on computer architecture. 2 Functional Requirements You are required to implement a 16-bit ALU that has a similar architecture as that shown in Figure 1. A description of each port and their type (in/out) is shown in Table 1. The operations that your ALU implementation should be able to perform are listed in Table 2. You are free to add any extra input or output signals that are deemed necessary. It is also up to you to decide how many bits to use for each input and output. You will be required to explain your design decisions in your report. Figure 1: Proposed ALU architecture. Page 1 of 5

2 Table 1: Description of ALU ports. Name Type Description OPCODE in tells the ALU which operation to perform. DATA0 in the first input operand. DATA1 in the second input operand. RESET in causes the ALU to reset (outputs set to 0). CLOCK in the input clock. DATA_OUT out the result of the operation. STATUS out status information relating to the previously executed instruction. Operation Type arithmetic boolean shifting Table 2: Supported ALU operations. Operation addition, subtraction not, and, nand, or, nor, xor, xnor arithmetic shift left and right, logical shift left and right. 3 VHDL Guidelines 3.1 Generics The VHDL language has several advanced features that facilitate development. Even though it was stated in Section 2 that the ALU implementation be 16 bits, there is no reason why the same implementation should not be easily adapted to handle 8, 32 or 64 bits. If the bit-widths are hardcoded as shown in Listing 1, then changing the design to support 32-bits would require editing the source code of the entity declaration as well as making changes inside the architecture definition. This approach is tedious and error prone. Fortunately, VHDL provides a useful feature called generics. Listing 1: Hard coded data widths (16 bits) entity Module is port( din_01 : in std_logic_vector(16 downto 0 din_02 : in std_logic_vector(16 downto 0 dout : out std_logic_vector(16 downto 0 end entity; architecture arch of Module is signal s1 : std_logic_vector(16 downto 0 begin dout <=...; end; ThemoduleimplementationshowninListing1canbemodifiedtousegenericsasshowninListing2. The variable DATA_WIDTH has a default value of 16, but the data width of Module can now be easily changed to 32-bits simply by instantiating the module as shown in Listing 3. Listing 2: Using generics instead of hard-coded values entity Module is generic( DATA_WIDTH : integer := 16; Page 2 of 5

3 port( din_01 : in std_logic_vector(data_width downto 0 din_02 : in std_logic_vector(data_width downto 0 dout : out std_logic_vector(data_width downto 0 end entity; architecture arch of Module is signal s1 : std_logic_vector(data_width downto 0 begin dout <=...; end; Listing 3: 32-bit instantiation using generics. m1 : Module generic map( DATA_WIDTH => 32 ) port map( din_01 => a, din_02 => b, dout => c 3.2 Using assert and report statements Verifying that your implementation is working properly is always a challenge. One common method of checking that a module is behaving properly is to trace signals in the waveform viewer and then manually check that everything is as it should be. The problem with this approach is that it becomes confusing when the number of traced signals becomes large. VHDL provides assert and report statements that can be used to verify correct operation. For example, Listing 4 uses an assert statement to check that the fail_signal has not been asserted, otherwise the report statement will print an error message and the severity clause will cause the simulator to exit. Note that the valid severity levels are NOTE, WARNING, ERROR and FAILURE of which only FAILURE causes the simulator to exit. Note that the simulator can be configured to exit on other conditions as well. Listing 4: Using an assert statement to detect a failure condition. assert fail\_signal = 0 report f a i l signal has been asserted severity FAILURE; We can make use of the assert and report statements in order to implement an automated testbench as shown in Listing 5. Note that pairing assert statements together or using an if statement accomplishes the same thing. Since the ERROR severity level does not cause the simulator to stop execution, it will therefore be possible to generate a report showing the result of each test performed by the testbench. Listing 5: Using assert/report to automate a testbench assert result_01 = X"0001" report " test 01 passed" severity NOTE; assert result_01 /= "X0001" report "test 01 failed" severity ERROR; Page 3 of 5

4 if result_02 = X"0002" then report " test 02 passed" severity NOTE; else report "test 02 failed" severity ERROR; end if ; In addition to being useful for creating automated testbenches, you should also use assert/report statements in your code in order to report error conditions such as when an illegal operation is requested of the ALU. 4 Assignment Tasks 1. Implement an ALU as described in Section Use generics so that the data width of your ALU implementation is flexible as discussed in Section Construct an automated testbench using assert/report statements as discussed in Section 3.2 so that the marker can easily run your testbench and verify your results. Your testing strategy should test corner cases and show that all required operations have been properly implemented. Your testbench should be in a separate file. 4. Your source code should be properly commented so that the marker can follow your design. 5. Provide a waveform trace showing the execution of 2 operations. The trace should be properly annotated and easy to understand without needing to consult your source code. 6. Synthesize your design without the testbench. In your report, describe the results of the synthesis, including the number of logic cells, look-up tables, and the latency of your circuit. Identify in your design the piece that consumes the most space and the longest path. 5 Submission Guidelines A hardcopy version of your report excluding VHDL source code is to be submitted either in-class or in the assignment box in the Trottier building. An electronic copy of your report including your VHDL source files is to be submitted through WebCT in the form of a compressed archive. The archive should have the following properties: the name of the archive should be of the form firstname_lastname.tgz. the archive should extract to a directory named firstname_lastname. Your report should be no longer than 4 pages(excluding the title page, diagrams and appendices) and should include the following: front page (course number, lab title, student name, ID, date) design description: * diagram and brief description of your ALU. * brief summary of any important design choices simulation results: Page 4 of 5

5 * description of testing strategy. * simulation traces and discussion of results. synthesis results: * critical path * estimated clock speed * resource usage 6 Marking Scheme 30 : Working ALU implementation. 05 : Generics properly used. 20 : Automated testbench. 05 : Simulation traces showing two operations. 10 : Synthesis results. 10 : Well structured code including meaningful comments. 20 : Report (discussion of design decisions etc) Page 5 of 5