ECEU530. Schedule. ECE U530 Digital Hardware Synthesis. Datapath for the Calculator (HW 5) HW 5 Datapath Entity

Transcription

1 ECE U530 Digital Hardware Synthesis Prof. Miriam Leeser November 6, 2006 Classes November 6 and 8 are in 429 Dana! Lecture 15: Homework 5: Datapath How to write a testbench for synchronous circuits HW 5: Due Wednesday, November 8 Project Progress reports due Friday, November 10 Schedule Classes on November 6 and 8 will be in 429 Dana Homework 5 due Wednesday, November 8 Write the Datapath for the calculator from ECEU323 in VHDL Use the posted entity Project progress report due Friday, November 10: and to me telling me where your project stands some working VHDL code in your home directory Homework 6: Lab 5 due Wednesday November 15 November 15 th and 20 th : student presentations on projects: sign up for a date to do your project presentation Sign up to demo your working project code November 20 th or 21 st ECE U530 F06 2 Datapath for the Calculator (HW 5) HW 5 Datapath Entity library ieee; use ieee.std_logic_1164.all; entity datapath is port ( din : in std_logic_vector (3 downto 0); dout : out std_logic_vector (3 downto 0); cout : out std_logic; sm : in std_logic; -- mux selector sa : in std_logic_vector (2 downto 0); -- alu mode selectors ss : in std_logic_vector (1 downto 0); -- stack mode selectors clk : in std_logic -- clock ); end datapath; 3 4

2 Stack for Datapath entity stack is port( clk, reset : in std_logic; -- clock ss : in std_logic_vector (1 downto 0); din : in std_logic_vector (4 downto 0); tos : out std_logic_vector (4 downto 0) ); end stack; architecture behavioral of stack is begin -- <<enter your statements here>> end behavioral; Implement the Stack: Stack Function Stack select hold 0, 1 push 2 pop 3 In lab, used shift registers to implement the stack In VHDL, use behavioral code to implement the stack How? Hint: Create internal state for the stack Looks like a simple state machine Output is simply TOS Note: Stack has an asynchronous reset 5 6 Stack Shift Register ARCHITECTURE behavioral of stack IS SUBTYPE five_bit is std_logic_vector (4 downto 0); TYPE four_array IS ARRAY (3 downto 0) OF five_bit; SIGNAL stk, next_stack : four_array; begin -- process for updating stack state Why do you need a new stack? entity shift is port(clk, SI : in std_logic; SO : out std_logic); end shift; architecture archi of shift is signal next_state, state: std_logic_vector(3 downto 0); begin process begin next_state <= state(2 downto 0) & SI; wait until (Clk'event and Clk = '1'); state <= next_state; end process; SO <= state(3); end archi; 7 8

3 Testbench Design Already seen basics of how to write one (Lecture 7) Libraries, Entity, Architecture Instance of Unit Under Test (UUT) Process to control clock Today: More important concepts Which input combinations should I try? Self-checking testbenches Simple UUTs Combinational circuits are easy to test Inputs can come in any order Outputs are only dependent on current input, not previous inputs Usually we can test combinational circuits exhaustively (all possible combinations of inputs) loops are often useful here 9 10! " #$ $% &&' ()!%"#%% &' Simple UUT: AOI Simple UUT: Testbench (1) &** '' & + $ $%

4 Simple UUT: Testbench (2) $', -% $ $ +).,% )./% ).% ).-% ).% What does it do? cycles through 0(0000) to 15(1111) are assigned to bits of This covers all possible inputs to the circuit &$ '$$)- -0 () '' % /- & Coverage is an important term when testing any circuit How much functionality did I actually test? How do I know it works? (1) Inspection: Run it in Modelsim and see if the output is what you expect Have to figure out all the correct outputs yourself There are only 4 inputs (16 possible values) here, so this is pretty easy and doable What if I have a lot of inputs, or a more complex circuit? How do I know it works? (2) Golden Standard: Compare the output to another circuit which implements the same function Ex.: Behavioral model vs. Structural model Instantiate a standard circuit alongside the UUT, connected to the same inputs If the outputs are the same, the UUT works Requires a circuit that already works! 15 16

5 Golden Standard example $& + ).,% )./% ).% ).-% ).% $ + ).,% )./% ).% ).-% ).% How do I know it works? (3) Self-checking: Write the correct answers directly into the testbench VHDL has an function for just this sort of concept (textbook p.77) You still need to know what the outputs are supposed to be No more squinting at Modelsim waveforms! $ % Assert: Syntax Assert: Parameters 1% ' ' 5 ' )67 The error message is printed if the assertion fails, i.e. the condition is not met In other words, 1 should be the CORRECT value There is a default error message ( Assertion violation ) if you don t include one ' defaults to Setting ' to will cause your simulation to stop if the assertion fails This is configurable inside the simulator 19 20

6 Assert: Example $ +).,% )./% ).% ).-% ).% &$ '$$)- -0 () '' % / ),%/%% %-%%%% 384 ' 9 Complex Circuits What makes a circuit harder to test? Memory devices (stack, registers, RAM, FSMs) Large numbers of inputs We can t just specify all combinations anymore A, then B is now different from B, then A Our simulation would take days! We have to pick and choose our test vectors so that we cover as much functionality as possible What is a Test Vector? A collection of inputs (possibly extending across multiple clock cycles) and the expected corresponding outputs When you apply the inputs, you should get the outputs You can write your testbenches as a collection of test vectors, complete with output checking Designing Test Vectors (1) Questions to ask yourself: What functions can my circuit perform? Along what paths can the data flow? Which inputs are data, and which are control? 23 24

7 Designing Test Vectors (2) What functions can my circuit perform? An ALU can Add, Subtract, AND, XOR, etc. A stack can Push, Pop, and Hold If there s only one function, you probably have a simple circuit Different levels of abstraction lead to different answers: a datapath can Push, And(TOS,Inp), And(TOS,TOS2), etc Designing Test Vectors (3) Along what paths can the data flow? Designing Test Vectors (4) Which inputs are control? It s most important to test all possible control combinations if one of these doesn t work, part of your circuit is unusable Which inputs are data? For now, you only need to worry about each data path not all possible data words Pick input words that are convenient (5+A=F) Testbench = A Set of Vectors A good series of test vectors gives you confidence that the entire circuit works Not every vector needs to test every gate Coverage is a way of talking about which gates (or functions) are tested by which test vectors The union of the coverage of all your test vectors should be your entire circuit 27 28

8 Test Vector Example Coverage Chart (1) A ** :-1 +();-<()3--4 ()3--4()3-4 /- ()3----4()3-4 /- )3--4% # 1 Mux A B Push Stack Pop Hold PassA ALU PassB Add XOR PassA Hold Push What have we covered? Goal: Every column should have at least one check mark once all the test vectors are designed Coverage Chart (2) Implementation Details 1 Input- Mux Reg- Mux Mux- ALU Stack- ALU ALU- Reg Reg- Stack Stack- Output It s good to write testbenches as a series of test vectors Use comments (and whitespace) to delineate each test vector Use a single process with statements between vectors Run your infrastructure signals (like clk) in a second process Don t forget to count coverage on your datapaths also 31 32

9 Summary Simple circuits can be exhaustively tested using loops Simple circuits have only one or two functions and no memories or sequential elements Self-checking test vectors make debugging your circuit much easier The statement makes it easy Summary Think about complex circuits in terms of the functions they provide Make sure you test every function at least once Don t forget to cover every datapath, too Good testbenches: Have 100% coverage Are easy for a human to follow Check themselves Handshaking Handshaking En -- an input signal telling the hardware to start Valid -- an output signal saying the result is ready What is wrong with this model? Sender En Valid inputs result Hardware One signal for input: Enable One signal for output: Valid How do you know if HW is ready? How do you know that HW has read the input data? How does HW know that Sender has read the output? 35 36

10 Signaling Protocol Signaling Protocol: communication protocol req: initiate an action ack: signal completion of that action Two handshake signals for send data Control Signaling Protocol Four-phase Handshaking protocol Sender req data ack Receiver req Level signaling or return to zero ack Sender Receiver data Control Signaling Protocol Two-phase Handshaking protocol Importance of Handshaking Hardware needs to know when inputs are ready Software needs to know when results are valid Different designs can have different timing Behavioral Register Transfer Level (RTL) Pipelined version vs. non-pipelined version Transition signaling or Non-return to zero req Sender data 39 ack Receiver Can use the same testbench with different hardware timing if you use handshaking in your hardware design 40