1. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 1 ECE 406 – Design of Complex Digital Systems Lecture 13: Regression Testing, MemAccess Block Spring 2009 W. Rhett Davis NC State University with significant material from Paul Franzon, Bill Allen, & Xun Liu

2. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 2 Announcements l HW#5 Due Today l HW#6 Due in 2 Weeks l Project #1 Due in 3 Weeks

3. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 3 Today’s Lecture l Regression Testing l MemAccess Block Specification

4. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 4 A Complicated Testing Problem l … and now you must design the Fetch block. l You designed the Controller in HW5… l … and a model for the Memory is given to you in HW6…

5. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 5 How to Test the Fetch Block? l What kinds of test-cases would you choose?

6. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 6 How to Test the Fetch Block? l Now suppose that the previous test-bench works properly, how do you know that the Controller, Fetch, and Memory blocks will work together? » Need to design another test-bench that includes all three (this is the only one you need to turn in) l What kinds of test-cases will this test-bench have?

7. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 7 Combined Test-Bench Setup

8. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 8 Test-Bench Tips l Include instances of all three blocks in the test-bench l Give the blocks recognizable instance names, rather than I0, I1, etc. Controller ctrl(…); Memory mem(…); Fetch fetch(…);

9. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 9 Debugging Quandary #1 l Option A: Debug with the current test-bench l Option B: Go back to the earlier test-benches to find the problem l Suppose you put together the test bench described here, and the design doesn’t work. What do you do?

10. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 10 Debugging Quandary #2 l Option A: Combine everything in one test-case l Option B: Create several test- cases for small groups of blocks l Once we’re done, we’ll still have 4 more blocks to design. How do we test them?

11. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 11 Debugging Quandary #3 l How do we keep from being overwhelmed by the complexity of these test-cases? l Regression Testing » Testing that code has not “regressed”, that is, that the functionality that was working yesterday is still working today. » Maintain a list of test-cases for each block, and re-run those test-cases whenever a block changes.

12. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 12 Test-Bench Tips l Keep the code for the LC-3 hardware in a separate file, such as lc3.v, then include this file in your test-bench with `include “filename” l Don’t rely completely on the waveform viewer. In order to make it easy to tell if a test-case has passed or failed, use a carefully selected set of $display statements.

13. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 13 Example Test-Case l Recall that the Controller test-bench showed that it was possible to carry your state machines through the proper states by setting the input signals: 0 Fetch Instruction 10 Decode 20 Execute Operate Instructions 30 Update Register File 40 Update PC 50 Fetch Instruction 60 Decode 70 Compute Target PC 80 Update PC 90 Fetch Instruction …

14. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 14 Example Test-Case l For the new test-case, we can use the same state display code l Add $display statements for the contents of the PC (which which will be the address lines) and dout from Memory: always @(dout) $display($time," dout=%h",dout); always @(addr) $display($time," addr=%h",addr);

15. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 15 Example Test-Case l Resulting output is easy to verify by a quick visual inspection: 0 Fetch Instruction 0 addr=3000 5 dout=54a0 10 Decode 20 Compute Target PC 30 Update PC 35 addr=3001 40 Fetch Instruction 45 dout=14aa 50 Decode …

16. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 16 Today’s Lecture l Regression Testing l MemAccess Block Specification

17. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 17 MemAccess l Receives Address to be read/written from Execute block l Receives Data to be written from Decode block l Master of the shared Memory bus during the “Read Memory”, “Write Memory”, and “Indirect Address Read” states. l Provides Data read from Memory to Writeback block Memory Controller Fetch MemAccess Writeback Decode Execute ALU RegFile IR PSR PC State

18. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 18 Detail of Memory Bus

19. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 19 MemAccess Signals l What is meant by the M_Data signal? Why does it come from the Decode block? l What is meant by the M_Addr signal? Why does it come from the Execute block? l What is meant by the memout signal?

20. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 20 MemAccess States

21. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 21 Read Memory State: LD, LDR l Determine the Memory Bus Signals: » rd » addr » din

22. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 22 Write Memory State: ST, STR l Determine the Memory Bus Signals: » rd » addr » din

23. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 23 Read Indirect Address State: LDI, STI l Determine the Memory Bus Signals: » rd » addr » din Same as the previous Read state!

24. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 24 Example: LDI l Location of Indirect Address:16’h300A l Indirect Address:16’h3010 l Value Stored at Indirect Address:16’h1234 Note that dout is the same as addr

25. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 25 Example: STI l Location of Indirect Address:16’h300A l Indirect Address:16’h3010 l Value to be Stored at Indirect Address:16’h1234 Note that dout is the same as addr

26. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 26 Read Indirect Address State l During this state, what will dout be set to? l What needs to happen to this value on the next cycle? l How can we ensure that this happens?

27. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 27 Read/Write Memory States Revisited l Read State Memory Bus Signals: » rd » addr » din l Write State Memory Bus Signals: » rd » addr » din

28. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 28 Verilog Code for MemAccess l Read Memory State: » if(M_Control==0) addr<=M_Addr; else addr<=dout; » din<=16'h0; // don’t care » rd<=1'b1; l Read Indirect Address State: » addr<=M_Addr; » din<=16'h0; // don’t care » rd<=1'b1; l Write Memory State: » if(M_Control==0) addr<=M_Addr; else addr<=dout; » din<=M_Data; » rd<=1'b0; l All Other States: » addr<=16'hz; » din<=16'h0; // don’t care » rd<=1'bz; Remember that this is combinational logic!

29. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 29 Complete the Table OperationmodeM_Control ADD0 1 AND0 1 NOT BR JMP/RET JSR JSRR LD LDR LDI LEA ST STR STI

30. Spring 2009W. Rhett DavisNC State UniversityECE 406Slide 30 What about memout ? l memout needs to present the value read from memory to the Writeback block. l There’s really no reason why it can’t just be connected to dout permanently (with an assign statement). l assign memout = dout;