Description

Multi-Cycle CPU
Hyunuk CHO
gusdnr9779@postech.ac.kr
Contents
• Objectives
• Multi-cycle CPU
• Testbench
• Assignment
• Announcements
Objectives
• To understand why a multi-cycle CPU is better than the single-cycle implementation
• To design and implement a multi-cycle CPU, which has its own datapath and control unit

Why Multi-Cycle CPU?
• Problem on single-cycle CPU : underutilization of resources
(ALU, memory, register file, etc.)
• Solution: use higher clock frequency and allocate different number of cycles for each instruction type

Multi-Cycle CPU (Datapath)

Multi-Cycle CPU (Finite state machine)

Multi-Cycle CPU (Micro-Code Controller)

Multi-Cycle CPU
•Details for multi-cycle CPU are given in the lecture note and textbook (Appendix C can be helpful)
•Please read those materials yourself to work on it
Let’s discuss the design and implementation
The Testbench File
cpu UUT (clk, reset_n, readM, writeM, address, data, num_inst, output_port, is_halted); memory NUUT(!clk, reset_n, readM, writeM, address, data);
• Note that the memory is not using the clock signal properly.
• It is done to allow the CPU to use access the memory in a single cycle and make it easier to implement
• Such clock abusing is forbidden within your code
Assignment (1)
• Implement a multi-cycle CPU
• Datapath for a 16-bit CPU
• Full support for TSC instruction set except for RWD, ENI, DSI
• num_inst should be increased when the CPU finishes executing an instruction
• The WWD instruction outputs the register value at the output_port
• The HLT instruction sets the is_halted signal
• Other instructions follow the TSC instruction set manual
• The datapath and the control unit should be separated
• The control unit controls the finite state machine
• The control unit gives appropriate signals to the datapath
Assignment (2)
• Your implementation should pass all tests in the testbench • But the message of “All pass!” does not mean you will get a full score
• Your control unit should have well-designed states
• Your control unit should be a well-implemented state machine
• Each state should generate its control signals
• All your circuits (Datapath + Control unit) should be clocksynchronized
• You should not use “delay(#)” nor “wait”
• All storage units (registers, PC, etc.) must be updated only at the clock’s positive edges
• Your code should have resource reuse, which affects your control unit design
• E.g. Using only one RAM port, combining a “PC + 1” logic with the ALU
Assignment Tips
• Do not modify cpu_TB.v, memory.v files and cpu module declaration
• You should follow the provided guideline
• Ex) wire -> reg, reg -> wire, add more input or output to the module
Submission
• Please submit your report and codes to LMS
• The file names for report and codes follow these formats
• “Lab4_TeamID_StudentID1_StudentID2.pdf”: PDF file for your report
• ex) Lab4_20_20180001_20180002.pdf
• “Lab4_TeamID_StudentID1_StudentID2.zip”: Zip files except cpu_TB.v, cpu_TB_f.v, memory.v
• If you do not follow the given format, you will get penalty on your score
Announcements
• Submit your report in PDF file
• Double check your submission file
• Use Teams message to ask questions
• Email TAs if you want to use late token for lab3
• About demo time

Q&A