Lab 5 - ECE 385_ Digital Systems Laboratory (Spring 2022) - Illinois Wiki

pdf

School

University of Illinois, Urbana Champaign *

*We aren’t endorsed by this school

Course

385

Subject

Electrical Engineering

Date

Dec 6, 2023

Type

pdf

Pages

Uploaded by MatePuppyMaster1948

5/15/23, 11:14 PM Lab 5 - ECE 385: Digital Systems Laboratory (Spring 2022) - Illinois Wiki https://wiki.illinois.edu/wiki/display/ECE385SP22/Lab+5 1/6 Dashboard / … / Labs Created by Julieanne Chapman, last modified by Cheng, Zuofu on Mar 03, 2022 Lab 5 Simple Computer SLC-3.2 in SystemVerilog In this experiment, you will design a simple microprocessor using SystemVerilog. It will be a subset of the LC-3 ISA, a 16-bit processor with 16-bit Program Counter (PC), 16-bit instructions, and 16-bit registers. For a general understanding of the LC-3 CPU, see Patt and Patel (ECE 120 textbook). Assignment Read the Lab 5 description in the lab manual and complete the Lab 5 Pre-Lab before the lab section. Work on Lab 5 report and Lab 6 Pre-Lab after the Lab 5 Week 2 section. Demo Week 1 Simulation of PC loading into MAR and PC incrementing. (1 points) Simulation of MDR loading into IR. (1 points) Correct FETCH operation on the board, showing IR on the hex displays. Must use the physical on-chip memory (slc3_sramtop.sv with instantiateram.sv). (1 point) The above demo is due in Week 1. No makeup demo is allowed in Week 2. The demo points and the workloads of week 1 and week 2 are not evenly distributed. Week 2 - Note that all demo points are on the physical DE10-Lite FPGA board. No points are given during demo for simulations. Basic I/O Test 1. (1.0 point) Basic I/O Test 2. (1.0 point) Self-Modifying Code Test. (1.0 point) XOR Test (1.0 point) Multiplication Test. (1.0 point) Sort Test. (1.0 point) Correct “Act Once” Behavior. (1.0 point) Reserve your demo slot by enter your NetID(s)

5/15/23, 11:14 PM Lab 5 - ECE 385: Digital Systems Laboratory (Spring 2022) - Illinois Wiki https://wiki.illinois.edu/wiki/display/ECE385SP22/Lab+5 2/6 Current Demo: Final Demo (in- Find your section below and sign up for a d by entering you and your partner's NetIDs Note: do not sign up prior to the Wednesda available demo slots will not be finalized un when the demo schedule updates. Zoom room for demos are found on your TA Remember to zip and upload your code to Landing Page ME YD HL DJ DT GL HW For details, refer to the Week 2 Test Programs Documentation below. Resources Appendix A - Appendix A of 190 textbook. Instruction set reference. Appendix C - Appendix C of 190 textbook. Design your state machine as shown in this appendix, and design your datapath. (See below for updated diagrams and tables.) ECE 120 Control Signals Reference (from Prof. Lumetta's notes - note that this also refers to the full LC-3) Provided SV files in (.zip) archive ( updated 03/02/2021 updated naming to Lab 5 instead of Lab 6, changed slc3.sv DRMUX and SR1MUX to be 1 bit instead of 2) - Includes 5 parts in 8 files: The top level entity ( slc3_sramtop.sv for synthesis ) and ( slc3_testtop.sv for simulation ) depending on whether you are using the test_memory dummy RAM or on-chip memory.

5/15/23, 11:14 PM Lab 5 - ECE 385: Digital Systems Laboratory (Spring 2022) - Illinois Wiki https://wiki.illinois.edu/wiki/display/ECE385SP22/Lab+5 3/6 The SLC-3 module ( slc3.sv ) - you need to design the datapath module. Remember to comment and uncomment some codes for week 2. See comments for details. Control Unit ( ISDU.sv ) skeleton - you need to fill in the control unit for week 2. The required memory controller files ( Mem2IO.sv and instantiateram.sv ) (You don't need to modify them, but are strongly recommended to understand how they work.) Simulation memory ( test_memory.sv ) is meant to be in place of physical on-chip memory in simulation. (requires SLC3_2.sv and memory_contents.sv ) It only works in simulation and will be synthesized into a blank module in synthesis. Week 2 Test Programs Documentation ( updated 2/13/2018) - Details about the tests you will need to run on your CPU during week 2 of the demo. Tutorial on Instantiating Megafunctions (you will need to create an on-chip memory Megafunction for your RAM) Updated diagrams and tables: Updated Block Diagram - Shows how the physical SRAM should be connected to the SLC microprocessor. Note that this is no longer accurate when using the MAX10 on-chip memory, though it is provided for you as a reference/starting point for modification. Updated State Machine - LC3 state machine with extra states removed and added pause states ( JUST TO REMIND: You cannot use the state transition diagram from the Lab Manual directly(i.e. without modification) because it is NOT what you actually implemented (you don't have R signal, and you have, say, 33_1, 33_2 ...). Please draw one by yourself (or modify based on the given diagram). There are many tools you can download or find on EWS to help you draw the diagrams.) Updated Data Path Control Signals - Similar to Table C.1 in Appendix C. Shows what values each control signal can take and their meanings. For the full datasheet on using Embedded Memory Blocks, consult the Max10 Embedded Memory User Guide Useful Readings Cummings, Clifford E. "Nonblocking assignments in verilog synthesis, coding styles that kill!." SNUG (Synopsys Users Group) 2000 User Papers (2000). Cummings, Clifford E. "State machine coding styles for synthesis." SNUG'98 (Synopsys Users Group San Jose, CA, 1998) Proceedings . 1998. Sutherland, Stuart. "SystemVerilog Saves the Day—the Evil Twins are Defeated!“unique” and “priority” are the new Heroes." (2005). Lab 5 Report Extra Credit Warning: This extra credit assignment requires working Lab 5 SLC-3 and also requires some experimentation with SignalTap and is only worth 4 points - so make sure you are completely done with Lab 6 before attempting this assignment - otherwise it is likely not an efficient use of time. Lab 5 report extra credit will require that you use the SignalTap integrated logic analyzer (ILA) to evaluate the performance of your Lab 6 SLC-3 on the FPGA. You will do this by running 3 test programs XOR, Multiplication, and Sort, and generating a trace using SignalTap. As a start, watch the following videos and check out the following tutorial to get familiarized with SignalTap: Signaltap for Verilog Designs Tutorial (with corresponding video from Intel) Video tutorial: SignalTap Video Tutorial Then set up a SignalTap trigger starting at the following points for each test program: PC = 0x1A for XOR test (this starts the capture right after you enter the second value to be XOR'ed) PC = 0x3A for the Multiplier test (this starts the capture right after you enter the second operand) PC = 0x77 for the Sort test, entry into the sort subroutine The goal is to generate a logic analyzer capture of your SLC3 CPU running the 'core algorithm' for each of the above 3 test programs. From that point, you can estimate the actual performance of the SLC3 CPU when running the test programs in lieu of having performance counters on the CPU itself. To this, read test programs and determine when the correct output is first

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

5/15/23, 11:14 PM Lab 5 - ECE 385: Digital Systems Laboratory (Spring 2022) - Illinois Wiki https://wiki.illinois.edu/wiki/display/ECE385SP22/Lab+5 4/6 available (e.g. on in the case of the XOR test, it is where PC=0x29). Subtract this from the starting point, yielding 15 instructions (note that XOR has no loops in the subroutine itself, but Multiplier and Sort do - so you will need to account for loop iterations as well). Then from your SignalTap trace, determine how many cycles this took (you can do this by capturing and inspecting the PC value). Suppose (that from reading the SignalTap trace) this takes 100 cycles, then you can say that your CPU is capable of 7.5 MIPS (millions of instructions per second) on the XOR test (15 instructions / 100 cycles * 50,000,000 cycles per second) Deliverables Show 3 SignalTap traces on your physical SLC-3 CPU from the above entry vectors. You should be able to capture enough data to see the PC at the output. You may want to capture additional data (e.g. the contents of the register file) or the MDR as SignalTap memory permits. Note that for the Multiplier and Sort tests, the trace screenshots won't fit nicely on the report page, it is acceptable to show the beginning and the end. (1 point each) Compute the 'average' SLC-3 MIPS as the average of the 3 individual MIPS calculations. Explain how you estimated the number of instructions for each test program and where you denoted the start and end of the clock cycle count (can be integrated with your 3 SignalTap traces above). Note that each MIPS value will be somewhat different, since each test program has a different mix of instructions, and not all instructions take the same number of clock cycles to execute. (1 point) FAQ "What exactly is the Mem2IO.sv file? Is this the on chip memory and if not how do we connect to the on chip memory?" Mem2IO is the interface between your CPU and the outside world (memory, IO, etc.). It is like the northbridge chip on a motherboard. It connects the CPU with either the memory or the IO by memory address (address x'FFFF' means interaction with the IO, all other addresses means interaction with the SRAM), and thus the name 'Mem2IO'. Figure 3 in the Lab 6 manual shows how the Mem2IO is used in this lab, where 'CPU' means your SLC-3 entity, and 'Physical Memory' is either the physical on-chip memory (when you use slc3_sramtop.sv ) for the demo, or the dummy memory entity ( slc3_testtop.sv , no pin assignment to the physical memory in this case) for the simulation. "Do we have two states (S_33_1 & S_33_2) because we have the R_not symbol looping back? If thats the case, wouldnt we have to check for the R_not signal before continuing and just have one S_33 state? I am a bit confused. Could you explain to me why there are two S_33 state partitions (S_33_1 & S_33_2)." Due to the configuration of the on-chip memory blocks, fetching from the memory will take more than a clock cycle. So originally there's a 'R' flag indicating when the memory has been successfully fetched, so the state machine can proceed. The data is guaranteed to be ready in 2 clock cycles, however, you may need a third clock cycle to get the data into MDR depending on the design of the state machine. So this is why instead of having an 'R' flag, we simply extend State_33 into two/three states. Similarly, for any other state which you have to implement for fetching or storing from and to the memory, you can extend them into two states. "So for Lab 5 Week 1, are we suppose to create an entity for MDR, MAR, PC, and IR? Are all of those just 16 bit registers? Also how/where are we getting the instructions?" Yes each one of them are simply 16-bit registers, and you will have to create all the other relevant entities and wire them together to be able to retrieve instructions from the physical memory. For the physical memory, you will follow the tutorial for the on-chip memory. For the simulation, a memory entity (test_memory.sv) is provided on the course website. Follow the steps described on the course website to load instructions into the test memory. "I'm a bit confused about the interfacing of the LC-3 CPU and the memory. In the lab manual, it says that "Additionally, when not writing to the memory, you should assign the bus a high-impedance value. Otherwise, when reading from memory, [bad things will happen]." A general rule to a bus is that while multiple components are connected to the bus, only one single component is allowed to be spitting out data onto the bus. You can have multiple components reading the bus without causing any problem, but if more than one component is outputting onto the bus, the data will be scrambled into garbage. This is why high-impedance value should be assigned to the outputs of the resting components (assigning 'Z' practically means an open circuit at the gate, so nothing will be flowing from the output onto the bus, not even '0'). However modern FPGAs do not allow high-Z buffers internal in the FPGA . This is because floating signals on the chip are bad for power and reliability reasons. For the CPU bus, you should use MUXes to control which component is driving the bus. "What entities are we suppose to create. I know that for this weeks lab we need to finish the ISDU file to correctly implement Fetch cycle, and that we need to create the PC, gatePC, MDR, gateMDR, MAR, gateMAR,

5/15/23, 11:14 PM Lab 5 - ECE 385: Digital Systems Laboratory (Spring 2022) - Illinois Wiki https://wiki.illinois.edu/wiki/display/ECE385SP22/Lab+5 5/6 and IR because fetch uses all these 3 components. Are we suppose to create an entity for Memory, INMUX, ADDR. CTL LOGIC, REG FILE, PCMUX and all the muxes and the adder in between?" Since the FETCH stage involves three states (18, 33, 35), you will have to implement all the necessary components and wirings so you can successfully complete the tasks for the three states. For example, you need the complete PC package (PC, PCMUX, '+1', GatePC), and also the complete MDR, MAR, IR package etc. to complete the tasks dictated by these states (refer to ISDU for the specific flags). On the other hand, you won't need entities like ADDR or REGFILE for Week 1, because you don't have to deal with them in the three FETCH states. If you want to do simulation then you can replace the top level with the alternative top level we provide. "We were just wondering if we could read from a register and load to that same register (from the register file) in one clock cycle? i.e. Can the AND, ADD, NOT computation be done in one clock cycle and so one state in our control unit?" Yes you can. Notice that the datapath between the output of the Regfile and the eventual input of the Regfile have no clocked components in between. Therefore, during the corresponding state, all the relevant signals are raised, all the relevant paths are populated with the two parameters, and the ALU has computed the results and route the result to right before the input of the Regfile. So, when the next clock ticks and states shifts, as long as you have already raised the loading signal for Regfile, the computed result will be loaded into the Regfile, so you can finish everything in a single state. "I have some questions about LDR. The test_memory file with the Mem_array filled with the large list of lc3 commands given to us on the website has some commands that have an input of "inSW" which is something that exists in SLC3_2.sv (as a constant of -1). I assumed we were supposed to add an input signal in test_memory that was the switches in order to change the value of offset6 for LDR. Are we supposed to do this or should we leave the "inSW" as -1?" The translator library will translate the "-1" into binary, which is xFFFF. And guess what, that's the memory- mapped address which tells the Mem2IO to fetch from the switches rather than from the memory! Therefore, when the LDR with "inSW" is invoked the values on your switches will be transferred into the CPU (you are still doing R(BaseR)+SEXT(offset6), but that's R0+SEXT(FFFF), which is xFFFF since R0 is cleared to 0). So, the first three lines of the list is read like this: Set R0 to x0000; loads the desired address from the switches to R1; jump to the address in R1. For the user, it means that you should set the switches pointing to the starting address of your test program, then you hit 'Run', and since PC always starts at x0000, your processor will automatically jump the PC to the address on the switches using the first three lines of instructions. Therefore, you can safely leave the inSW and the test_memory alone without any modification. "Why is there a state 20? This state would never happen because the JSR operation always has a 1 in IR11 so it's not possible to go from state 4 to state 20 with the JSR operation." Yes you're right. We only deal with the IR[11]=1 case in this lab. Therefore you can go directly from State 4 to State 21 without having to make the decision. "For the Lab 5 report, what should we write for the "Description of how the instruction sequencer/decoder works". Do we need to write out the outputs of the control for every one of the states we are in?" Yes you do. You always need to assume the reader have no prior knowledge on your lab, so you need to put down the design information, including the state transition diagram (ok, you didn't "design" it, but it's what your circuit is based on, so you still need to include it), as detail as possible. Same thing goes for the instruction sets, the block diagrams, and any provided parts (such as Mem2IO, you will have to describe how it works instead of simply say it was provided). "My CPU executes some instructions, but then crashes. The simulations look just fine." Here is the master list of things to try if your CPU crashes when executing the test programs: a. Make sure you have synchronizers on all the asynchronous inputs to your CPU (especially to the state machine). b. Make sure you have a constraint file (.SDC) which creates a 50 MHz clock constraint for the "clk" signal. See Lecture 9 slides. Make sure that your design can actually hit the 50 MHz target (Timequest will throw an error if you cannot, so long as you have the constraint file included in your project) c. Make sure you are waiting the appropriate number of clock cycles for the read/write operations to and from memory. No labels 1 Comment Ye, Elijah There is a typo on the lab5 page: the title is spelled wrong. Verlog → Verilog.

5/15/23, 11:14 PM Lab 5 - ECE 385: Digital Systems Laboratory (Spring 2022) - Illinois Wiki https://wiki.illinois.edu/wiki/display/ECE385SP22/Lab+5 6/6

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Lab 5 - ECE 385_ Digital Systems Laboratory (Spring 2022) - Illinois Wiki

Related Documents