In this lab you will modify a Number Sequencing Computer (NSC), a stored program machine that displays a series of digits. In the prelab, you'll alter the NSC so that it displays your own phone number. For the first task, you will adapt the NSC to allow it to accommodate a program that can contain up to 32 instructions. For the second task, you will add a new function to increment the last digit output by one.
As always, read through the entire lab before starting to work.
In-depth information about the basic functioning of the NSC can be found in the Chapter 2 Lecture Slides (Number Sequencing Computer) on Canvas and will not be repeated here.
If you have not installed Quartus and Modelsim, visit the Lab 0 page to download them.
Put the nsc_quartus folder in C:\ece3724. This also should have been done during Lab 0. In this lab and all other labs:
Do not use spaces in filenames or folder names: C:\Users\Bob Smith\Documents and Settings
Do not use file paths greater than 64 characters:
C:\Desktop\ece\lab0\Quartus\lab1(1)\Bob_Smith\lab1(Copy)\ece3724\Microprocessors\Spring_2025\Number_Sequencing_Computer
Do not use nested folders: C:\ece3724\nsc_quartus\nsc_quartus\
Do not install programs to or load projects from cloud storage services like OneDrive or Dropbox.
Do not run programs or load projects that are inside zip files. Extract them first.
We will not be programming the NSC onto an FPGA board. If Quartus demands that you choose a device, select Cyclone IV.
Run Quartus Prime Lite
Open the project (not open file) C:\ece3724\nsc_quartus\nsc.qpf
If you get this pop-up, click Yes.
Close the IP Catalog on the right. We won't be using it and this will make it easier to see your screen:
You can also drag the bar on the left to shrink the Project Navigator and Tasks windows.
Change "Hierarchy" to "Files" in the dropdown menu in the top left:
This lets us see the files associated with the project:
nsc.bdf - the overall schematic
myrom.v, myreg.v, mycounter.v - Verilog code files that control how the "black box" components on the schematic function
nsc.vt - Verilog test bench template file that simulates sending input to the NSC so that we can check the output in ModelSim. We'll only be making one small change to this file.
nsc_sim.do - configuration for ModelSim. You won't need to edit this.
Doubleclick nsc.bdf to open it:
You should see that it is functionally identical to the diagrams of the NSC from the lecture notes:
However there are several cosmetic differences:
In the Quartus version, the controller is not a single component, but rather an assortment of logic gates.
The other components have different names:
myrom = program memory
mycounter = program counter
myreg = output register
The components have been moved around to make the schematic visible in one laptop screen.
Not all connections are shown by drawing wires between two parts. For example, here we see the output from dout of myrom is called mem. The [5..0] suffix means that it is 6 bits wide:
If we take a look at the d input to mycounter, we see that it is 4 bits wide, and that the line connected to it is mem[3..0] - the lower four bits of the output from myrom :
Later in this lab we'll be editing both components and connections. For now, just keep in mind that they need to correspond with each other sensibly, or Quartus will complain:
mycounter expects a 4 bit input. We cannot change the input line to mem[4..0], i.e. make it 5 bits wide, unless we edit the mycounter component.
Likewise, if we want to make the output line from myreg 7 bits wide, we could change it to mem[6..0], but we will have to edit the myreg component so that dout is also 7 bits wide.
References to bits (mem[9..7]), or lines (mum[3..0]) that don't exist will also cause problems.
Compile the project by Processing > Start Compilation. You can also hit Ctrl-L or press the little blue play button on the toolbar. Compilation will halt at 83% - this is fine, it's because there's no board to program.
ModelSim should open automatically. If it does not, or if compilation fails for some reason, check the Troubleshooting page for solutions. You should get something that looks like this:
Close the Instance and Objects window on the right. You can also shrink the Transcript window underneath. This will give you more room to view the waveform on a small laptop screen:
To zoom in and examine the beginning of the waveform, press 'f'. If this isn't adequate, you can also use 'i' and 'o' and scroll the bar underneath as needed:
If we examine the green signals, from top to bottom, we can see:
the clock
LOC (local) which the testbench sets to high after the first iteration of the phone number
the address (memory location) where the program counter currently is
Jenny's phone number, first the whole thing, and then just the last 4 digits repeated endlessly
If you close the entire ModelSim window by mistake you can get it back by recompiling, or, if you haven't made any changes, by Tools >Run Simulation Tool >Gate-Level Simulation. To stop compilation (so you can make edits in Quartus), just close the ModelSim window. If that doesn't work for some reason, select Processing > Stop Processing, or click the red stop sign icon on the toolbar:
Complete the pre-lab checkoff requirements below before you enter the lab. Note that Quartus and ModelSim should already be installed on your computer and tested. If you experience technical difficulties, notify a TA well before the lab begins so these issues can be resolved ahead of time. Waiting until lab time to discover that your software has become inoperational means that you will forfeit your prelab points. If you arrive later than 15 minutes after the beginning of your scheduled lab time, you cannot receive prelab credits. If you miss lab with an unexcused absence, you cannot receive prelab credits at a later lab. Please see the lab policy summary for further details. Note: There is nothing to hand in for this pre-lab. The TA checks it off at the beginning of lab.
Open the myrom.v file within Quartus.
Edit the Verilog code in the case statement to contain your 7-digit phone number.
Alter the comments so that they match the machine code:
Here I have changed the first digit of my phone number to a 7. Notice that I've also changed the assembly instruction in the comments to match. Also notice that underscores have no effect on numbers in Verilog - they're just there to make the code easier to read by separating the opcode and the address/output.
Recompile the design, and re-simulate. Verify that the number displayed in ModelSim is now your 7-digit phone number.
Do not stop here! It is highly recommended on this and all labs that you make an attempt to complete the tasks on your own before entering the lab. If you get stuck, contact a TA ahead of time and they'll be glad to help you via email rather than watch you sitting alone in lab, struggling to finish. Waiting until you come into lab to open the webpage and then racing to complete the prelab before the TA comes around to check you off is a strategy that will cause you difficulties later in the course. You have been warned.
Your myrom.v file has your own phone number in it, and the comments match the machine code (20)
Didn't comment code or change machine code (10)
Didn't complete; changed only one number of phone number (0).
You can start Task 2 on first lab and take rest for another week or you can start the Task 2 next week as Lab 1 is expanded for Two weeks.
For Task 1, you're going to expand the NSC design to support 32 memory locations. This means:
It will now be able to hold 32 instructions. We're going to move our program to line 8 to make use of these new memory locations.
It will now be able to output numbers 16-31. (Admittedly, this is not very useful for phone numbers.)
Before we begin, let's take a look at exactly what this means:
As you can see in the above table:
Everywhere in the NSC where we were previously referring to [5..0] needs to be changed to [6..0] because the total instruction is now 7 bits wide.
References to bits [3..0] need to be updated to [4..0] because the address/output is now 5 bits wide.
OP[1] is now bit 6, and OP[0] is now bit 5. If we continue to use bits 5 and 4 for the opcode, the NSC will behave erratically.
These changes affect not only the mem line as shown in the table, but most other components and connections as well. One small change has resulted in a lot of work for us in Quartus!
The address bus must be increased in width from 4 bits to 5 bits; change the statement input [3:0] addr to input [4:0] addr .
The data bus must be increased from 6 bits to 7 bits since the address field in the instruction has increased by one bit. Change the statement output [5:0] dout to output [6:0] dout. Also change the statement reg [5:0] dout to reg [6:0] dout.
Modify the case statement:
Addresses must be five bits in width.
Instructions must be seven bits in width.
Change line (address) 0 to jump unconditionally to line 8.
The local: label will now be at address 12.
The start: label is now at address 8, so that's where your last line should jump to (rather than 0).
Change the default case as well to jump to 00000. (Because of the default case, we don't need to write lines 1-7 or any other lines we're not using).
Be sure all comments are correct.
Here's what the beginning of my program looks like now:
You compile your program now if you want, but it will output nonsense in ModelSim. Even though we've changed myrom.v to give the component a 5-bit input and 7-bit output, the schematic has not updated to reflect this: We need to do it manually. Open nsc.bdf.
First, stop compilation (red stop sign) if it is ongoing (ModelSim is open). Otherwise the following steps won't work. (Even worse, they won't give any error messages so you won't know any better.)
Right-click myrom.v in the Project Navigator window. Select "Create Symbol Files for Current File":
You should see something like the above in the Messages window.
Now right-click on the symbol in the schematic and select "Update Symbol or Block...":
Note: You only have to take these steps if you add, remove, or change the widths of inputs/outputs of a component. I.e. it's not necessary if you just alter your case statement, thought it won't hurt anything.
We're done with myrom for now, but a glance at the schematic shows that we need to make a lot more changes:
If we try to compile the project now, Quartus will have a fit.
The counter has to be changed from a 4-bit counter to a 5-bit counter. Open mycounter.v and:
Change the statement input [3:0] d to input [4:0] d (width is now 5 bits).
Change the statement output [3:0] q to output [4:0] q (width is now 5 bits).
Change the statement reg [3:0] q to reg [4:0] q (width is now 5 bits).
Change the statement if (!r) q <= 'b0000 to if (!r) q <= 'b00000 (reset value is now 5 bits).
Go back to nsc.bdf and Create/Update symbol like you did for myrom.
Open the file myreg.v
Change [3:0] to [4:0] in three places, like you just did for mycounter.v
Add a zero to the reset value in the same way.
Update the schematic (Create/Update symbol)
Check that everything is connected on your schematic. When I updated myreg, this happened:
This can be fixed by selecting "Orthogonal Bus Tool" from the toolbar and drawing a line to connect things back up. (If it's a single line rather than a bus, use "Orthogonal Node Tool", which is next icon to the left.):
Good as new.
Open the file nsc.vt and change these two 3s to 4s so that ModelSim will display the addresses and outputs properly:
Go back to nsc.bdf. You need to update various connections so they match the components they are attached to. For example, we discussed earlier that the opcode is now mem[6] and mem[5]. But here we see mem[5] and mem[4]:
To change them, right-click and go to Properties:
And simply change it to what you want it to be, like this:
You can also try doubleclicking then editing them, though this can be fussy. You do not have to delete or add any components or connections; all you have to do is rename existing nets. For example, the bus that is connected to the q[4..0] port of mycounter must be renamed from addr[3..0] to addr[4..0]. Everywhere on the schematic, you have to change:
[4] to [5]
[5] to [6]
[3..0] to [4..0]
and [5..0] to [6..0]
In all, there are nine changes to make to the schematic.
When you're done, compile your project and examine the result in ModelSim. You should see something like this, but with your own phone number:
If the two-digit numbers appear missing from the address signal, zoom in.
If the addresses jump back to 0 or 1, or deviate from the pattern in the above screenshot, something is wrong with your code in myrom.v.
If your phone number is wrong, like all 1s, or it's not repeating the local portion, it is likely also an issue with your code.
If you're getting Zs in your phone number or addresses, it's probably something with your schematic.
If you're seeing negative, hexadecimal, or binary numbers in your waveform, change the Radix of the offending signal to Unsigned:
Check out the troubleshooting page if you're still stuck.
Your ModelSim waveform looks correct.
Screenshotting is discussed in detail here.
Take a good screenshot of your ModelSim waveform, showing the numbers clearly and the last four digits repeating several times:
Good.
Bad.
Take a good screenshot of your schematic:
Good - though this was taken before Task 1 was completed, so yours should have different numbers on it.
Awful.
You can start Task 2 on first lab and take rest for another week or you can start the Task 2 next week as Lab 1 is expanded for Two weeks.
In this task you will add a new instruction called 'INC' that will increment the value the NSC outputs by one. To accomplish this, you need to make three changes to the Quartus project.
Start by editing the myreg.v file. Add a new input called inc (look at the mycounter.v file - it's a single line of code and you can just copy it over)
Erase this block of code from the bottom of the myreg.v file:
Copy this block of code from mycounter.v into its place:
In mycounter.v, the input is called d and the output is called q. But in myreg.v, the input line is din and the output line is dout. To fix this, in the block of code you just pasted, replace d with din, and q with dout (4x).
Go back to nsc.bdf, create a symbol for myreg, then right-click it and update. It should now have an additional input called inc.
In the current version of the NSC, opcode 00 is JMP, opcode 01 is JC, and opcode 10 is OUT. Since opcode 11 is unused, we'll make it INC. If you completed Task 1, the MSB of the opcode is mem[6] and the LSB is mem[5].
Since you want the INC input high when mem[5] and mem[6] are both high, you will need to connect both of these lines to an AND gate and then connect the output to INC on myreg.
To add a symbol, click the little AND gate at the top of the schematic:
It's next to the A.
Select and2, click OK, then click the schematic to place it.
If you have the "Repeat-insert mode" selected like in this diagram, then hit Esc when you are done inserting AND gates.
Draw a line extending from each input to the AND gate. Then right-click the "X" at the end of each line and select "Properties". Name them mem[5] and mem[6].
When you're done, it should look like this:
Your inputs may be in a different order. And it doesn't matter where you place your components or labels, as long as they are connected properly.
Right now the LD (Load) input is just connected to mem[6]. That's because in the old version of the NSC, the only instruction that had a 1 in the MSB of the opcode was OUT. But now we only want LD to be true when mem[6] = 1 and mem[5] = 0, So you will need to add another and2 gate and a not gate, then connect them appropriately.
Be sure to remove this wire labelled mem[6], or it will ignore the new gates!
You're going to add three increment instructions after your phone number. An INC instruction looks like this: 'b11_ZZZZZ. The Zs can be either 0s or 1s, it doesn't matter; if the NSC gets the opcode 11, it will increment the current digit and ignore the rest of the instruction.
Make lines 16-18 (right after your phone number ends) increment instructions. Comment them like the other lines.
This will bump the JMP start line down to line 19.
The end of your case statement should now look like this:
Compile your project. Your ModelSim output should now look like this:
Your ModelSim output looks correct. The TA has looked over your myrom.v file to ensure that you:
Have filled out the header on top with your name and etc.
Have put correct comments (assembly instructions) on every line.
Have not made a big mess of it.
Screenshot of your ModelSim waveform. Be sure it shows the beginning of the waveform and at least one complete local iteration.
Screenshot of your schematic (nsc.bdf). Make it large enough to be legible and crop unnecessary portions of the Quartus screen.
See Lab Policy Summary for formatting guidance and a sample report.
The title page should contain the following: Lab name & number, your name & NetID, and course & lab section on successive lines.
Second page should begin a brief description of the overall lab activity, intelligible to an outside reader.
Task 1: Write a brief description of Task 1, intelligible to an outside reader. Include your screenshot of the waveform and your schematic and label them.
Task 2: Write a brief description of Task 2, intelligible to an outside reader. Include your screenshot of the waveform and your schematic and label them.
Include the source code of myrom.v as an attachment to your Lab 1 submission - the actual file, not a screenshot. Be sure it has the header on top filled out with your name and etc. Just like in the original program, next to each line of machine code (the binary) should be a comment containing the correct line number and assembly code that accurately states what the machine code does.
Make sure your screenshots are decent. Here's a guide to taking good screenshots. The two main things to check:
Is it readable on your laptop screen without having to zoom in or lean forward?
Do you explain what you're showing the grader like the sample report does?
GOOD: "Below is my updated schematic showing the changes:"
GOOD: "The above waveform shows the last digit of my phone number, 9, being incremented 3 times, so the numbers 10, 11, and 12 are output in succession."
BAD: "Below is my screenshots for Task 1"
If you do not successfully complete a task and your report fails to mention or glosses over this fact, you will receive a zero for the report portion of your grade as well as for the task. If you attempt to deceive the grader, e.g. by including screenshots not generated by the code you submitted, your instructor will be notified and you will be recommended for an Honor Code violation.
The report is worth 20 points for neatly and coherently presenting your information to a reader. The following non-exhaustive list of errors will result in losing credit from the report portion of the lab grade:
bad screenshots (not cropped properly, blurry, too small)
text is "lab jargon" unintelligible to an outside reader ("I made mem[5] mem[6] so my NSC had more memory")
text is phrased as instructions to a second party ("Add a second AND gate.")
text is copy-pasted from the lab directions rather than using your own words.
text is a literal recap of the activities you performed rather than communicating your results and understanding ("First, I changed the statement output [5:0] dout to output [6:0] dout ...")
blatantly erroneous text ("I attached the C++ code.")
garbled / confusing / gibberish text ("Sure, I can help you with that! In electronic engineering, an ADC or analog-to-digital converter is used to transform analog signals into digital, or binary, encoding. Typically...")
using vague or incorrect terminology ("We used Intel to create the Number Sequenced Calculator")
excessive text
careless use of pagebreaks that leave blank pages, 1-2 lines of text on a page, etc.
general unprofessional appearance
code is untidy
code is missing header and/or contains default header
code has inaccurate/inadequate comments
The tasks are worth 60 points. If your report indicates that you did not successfully complete or do not understand a task, you will lose credit, even if you performed it during the lab. The same is true for tasks performed during the prelab. There are two tasks. The first task is worth 30 points. The second task is worth 30 points. The following non-exhaustive list of errors will result in losing credit from a task:
missing screenshot
screenshot of the wrong thing
waveform screenshots show incorrect results
schematic screenshot shows that modifications have not been made or are made incorrectly.
cannot read screenshot
code won't build
code performs incorrectly
code is convoluted
code uses incorrect methodology; doesn't follow lab directions.
Lab reports that flagrantly violate submission policy (wrong lab, no screenshots, no title page, no text besides headings/labels, mostly blank, code pasted into pdf, paragraphs of lab text pasted in, extremely sloppy/unprofessional, missing code etc.) will not be accepted. You will receive a zero for the lab and may resubmit with late penalty.
B.A. Jones, R. Reese, and JW Bruce, Microcontrollers: From Assembly Language to C Using the PIC24 Family, 2nd ed. Cengage Learning, 2015. This textbook is the original source for Dr. Reese's NSC and contains a wealth of information about the PIC and assembly programming which you will find helpful during this course. It is highly recommended that you obtain a copy.