In the last tutorial, we programmed our device and tested it by physically switching all the switches. That is all the testing you’re going to need for the simplest FPGA in the world. In reality, things can be somewhat more complicated. It becomes difficult to test your FPGA by manipulating it physically. This is why we use simulation. By simulating your design, you can check to see if it works,\u00a0and then spend very little time debugging it in the lab. In this tutorial we will simulate\u00a0our design. This will be the simplest simulation in the world.<\/p>\n
You can’t just simulate your design in isolation. Your design has input signals and output signals, and you need to control the inputs and verify that the outputs are correct. Ideally you want your test to create the input stimulus and verify the correctness of the output signals. In the real world, we want tests to print out what they are doing as the test runs, print any error messages if any of the tests fail, and print a summary about whether the test passed or failed.<\/p>\n
In our example, we will only have one file in our test bench. In the real world you will usually have many files that form the test bench and the tests. In fact, in complicated ASIC designs which require more elaborate testing than FPGAs, it is not uncommon for more effort to be put into the simulation and testing of the ASIC design than in the design itself.<\/p>\n
To create the test bench go to the Project Manager<\/strong> flow and click\u00a0the Add Sources<\/em> button. Check the Add or create simulation sources<\/em> radio button and click Next<\/em>. Then click Create File…<\/em> and give a file name called Unlike our FPGA, the test bench doesn’t need any input or output ports. You can think of it as the container for the simulation universe. Everything happens within the test bench. Another thing you need to know about is the simulation timescale. At the very top of the test bench file you will see (or you should type)<\/p>\n This tells the simulator that, when you give a delay value in this file<\/em>,\u00a0the delay will be in nanoseconds. That is the numerator of the fraction value. The denominator of the fraction value tells the simulator how much time precision this file requires. In general, it is OK to leave it the same as the numerator. Note that the timescale directive, like all preprocessor directives in verilog, starts with a back tick (grave accent) character. Next comes the module declaration.<\/p>\n Following that we need to declare the signals that we are going to connect to our FPGA that we will be simulating. The output signals from the FPGA need to be connected to wire<\/b> type signals in the test bench. The input signals to the FPGA can come from wire<\/b> or reg<\/b> signals. The first thing to declare is the clock input:<\/p>\n And then, we create a 100MHz clock:<\/p>\n Let’s look at this code in a little more detail. First, clk<\/em> is a reg signal, so we need to assign it in a procedural block. We can create a procedural block using an always statement. We saw in the last tutorial that an always clock had an event specifier which told it when to activate – like on the positive edge of clock. This always block has no event. It always runs. Once it finishes, it just runs all over again. Every time the block runs, it inverts the clock. What is the magical Now we need to declare a reg<\/b> signal to drive the switch inputs and a wire<\/b> signal sample the led<\/em> outputs.<\/p>\n An important feature of Verilog is that a module can contain instances<\/em> of other modules. You can create hierarchical designs this way. This feature is really useful for reusing design components, or for just creating a sense of order in your designs. In the next line, we instantiate the FPGA top module in our test bench and wire up its inputs and outputs. To instantiate a module, you first mention the name of the module, then you give an instance name\u2013 that is, a name for this particular instance of the module. Often you might instantiate the same module more than once within your module. In these cases, you’ll need to give them different names. The simulator will refer to signals within nested modules in a similar manner\u00a0to files nested within a directory structure. When doing so, the simulator will use the instance name, since the module name might\u00a0be ambiguous if there are multiple\u00a0instances of the module. An important thing to note is that module names and instance names use different namespaces<\/em>. Because of this, there is never a situation where a name\u00a0could refer to either\u00a0a module or an instance. This means that the module name and the instance name can be the same. In my opinion, exploiting this actually leads to a more easily-understood design.<\/p>\n Anyway, after the instance name we give an open parenthesis and list the module connections. This takes\u00a0the form of a period, followed by the port name within the module, then an open parenthesis and the name of the signal we are connecting up to the port. This is then followed by a close parenthesis, a comma, and finally the subsequent connections. All of these are followed by a close parenthesis and ended with a semicolon. Here is the module connections are supposed to look like:<\/p>\n We still haven’t told the simulator how to set the switch inputs during the simulation. What are our options here? Hypothetically, we could count through all 256 possible switch settings. In this case, that’s not a bad option. But you’ll often have designs where the sequence of inputs is important. If you were to count, the sequence would\u00a0always be the same no matter how many times you counted. Because of this, you might not be able to spot bugs. Usually, the better approach is to use some type of randomness. This is what we’ll be doing here. Verilog has a built-in function called $random<\/b> which you can use for this purpose. Here, we will make an always block which sets the switch inputs to a random value on every clock:<\/p>\n As it stands, we have a simulation which continues\u00a0forever. That’s probably longer than we plan for\u00a0our simulation to run. We can add some code that\u00a0causes the simulation to end after a certain amount of\u00a0time. The built-in Verilog task $finish<\/b> will cause the simulation to complete. We could just have an initial<\/b> block that waits for some fixed amount of time and then calls $finish<\/b> like this.<\/p>\n But that’s not something I prefer,\u00a0because it will just wait for an amount of time to pass, and then kills the simulation. What if we made\u00a0our clock period longer or shorter? The length of the test wouldn’t\u00a0adjust to give us the same number of clock cycles. Instead I prefer to use the Verilog repeat<\/b> construct and actually count the clock edges. That way, the simulation will always last the number of clock cycles I specify. In this case, I’ve chosen to run the simulation for 1000 clock cycles.<\/p>\n The repeat<\/b> statement tells the simulator to run the following statement 1000 times. The statement will simply\u00a0wait for the rising edge of clk<\/em>, and then, it will finish the simulation.<\/p>\n After this we just need to end the module with<\/p>\n To run the simulation, click on\u00a0Run Simulation<\/b> in the Flow Navigator window. This will bring up a drop-down menu. Select Run Behavioral Simulation<\/b>. This should bring up a simulation waveform window which resembles\u00a0the screen on a logic analyzer. It shows the changes in the simulation’s signals over time. On the left, you should see buttons that\u00a0control the varying\u00a0views of the simulation. You can zoom in on specific points in time, or zoom out to see a grand overview of the entire simulation. Go ahead and play around with the functions to get a feel for the tool.<\/p>\n In the next tutorial, I’m going to cover a few things that we glossed over in this tutorial. In particular, I’ll be talking about the difference between blocking and non-blocking assignment. It’s an important topic, so be sure to read that as well.<\/p>\n Here is my\u00a0final version of bench.v for this tutorial:<\/p>\n In the last tutorial, we programmed our device and tested it by physically switching all the switches. That is all the testing you’re going to need for the simplest FPGA in the world. In reality, things can be somewhat more … Continue reading bench.v<\/code>\u00a0and click Finish<\/em>. A new dialog will pop up and you should name the module bench<\/em>. Don’t give it any ports. Then click OK<\/em>.<\/p>\n\u00a0Test Bench Contents<\/h1>\n
`timescale 1ns\/1ns<\/code><\/pre>\nmodule bench;<\/code><\/pre>\nreg clk = 1;<\/code><\/pre>\nalways #5 clk = ~clk;<\/code><\/pre>\n#5<\/code>? That tells the simulator to advance the clock 5 nanoseconds before performing the assignment. The units are in nanoseconds because of our timescale statement. So the clock starts at one, and then at five\u00a0nanoseconds, it switches back to zero. In five more nanoseconds, it will switch back to one, and the process starts all over again, continuing forever. In effect, this is a 100MHz clock.<\/p>\nInstantiating the FPGA design<\/h2>\n
reg [7:0] switch;\r\nwire [7:0] led;\r\n<\/code><\/pre>\ntop top (.clk(clk),.switch(switch),.led(led));<\/code><\/pre>\nDriving the switches<\/h2>\n
always @(posedge clk) switch = $random;<\/code><\/pre>\nFinishing up<\/h2>\n
initial #10000 $finish;<\/code><\/pre>\ninitial\r\n begin\r\n repeat (1000) @(posedge clk);\r\n $finish;\r\n end<\/code><\/pre>\nendmodule<\/code><\/pre>\nRunning the simulation<\/h1>\n
`timescale 1ns\/1ns\r\nmodule bench;\r\n reg clk = 1;\r\n always #5 clk = ~clk;\r\n reg [7:0] switch;\r\n wire [7:0] led;\r\n top top(.clk(clk), .switch(switch), .led(led));\r\n always @(posedge clk) switch = $random;\r\n initial\r\n begin\r\n repeat (1000) @(posedge clk);\r\n $finish;\r\n end\r\nendmodule<\/pre>\n","protected":false},"excerpt":{"rendered":"