always @(posedge clk) led = switch;<\/code><\/pre>\nIn our test bench module, we drove the switch values to random values on the rising edge of clk<\/em> as well.<\/p>\nalways @(posedge clk) switch = $random;<\/code><\/pre>\nSo the question is, which of these events happens first in the simulation? In real hardware, it is possible for them to happen simultaneously, but in the simulator this is not possible. So, which goes first? The answer is, quite simply, we don’t know. It’s unclear\u00a0ahead of time which one will execute first. And which one is executed first\u00a0has an impact on the simulation’s behavior. Even if it were possible to\u00a0know, this situation is so common that making a working simulation with a real-life design would be just about impossible. You would be spending all of your time trying to keep track of which block goes\u00a0before which other block. Furthermore, it is actually impossible because sometimes, two blocks might both<\/em> need to go first. Consider the code below:<\/p>\nmodule top(input clk, output reg a, output reg b);\r\n initial a = 0;\r\n initial b = 1;\r\n always @(posedge clk) a = b;\r\n always @(posedge clk) b = a;\r\nendmodule\r\n<\/code><\/pre>\nWhen I simulate this a<\/em> is set to 1 right away, and then nothing ever changes. a<\/em> and b<\/em> are both 1 for the entire simulation.<\/p>\nIf you elaborate the RTL design and look at the schematic, you’ill see the correct implementation:<\/p>\n
![\"Synthesized](\"https:\/\/www.beyond-circuits.com\/wordpress\/wp-content\/uploads\/2015\/01\/Tutorial3_Schematic1-300x157.png\")
<\/a>Synthesized design<\/p><\/div>\n
The sequential assignments above are called blocking<\/em> assignments. Verilog also supports a different assignment operator called a nonblocking<\/em> assignment. The example below shows the same code with nonblocking assignments.<\/p>\nmodule top(input clk, output reg a, output reg b);\r\n initial a = 0;\r\n initial b = 1;\r\n always @(posedge clk) a <= b;\r\n always @(posedge clk) b <= a;\r\nendmodule\r\n<\/code><\/pre>\nWhen the simulator encounters a nonblocking assignment, it evaluates the right hand side of the expression and schedules that value to be assigned to the left hand side of the expression once\u00a0all other always blocks are evaluated. It is\u00a0critically important that you always use long blocking assignments when assigning to output values in sequential always blocks. Likewise, always use a blocking assignment when assigning the output of a combinational always block.<\/span><\/p>\nYou should take the time now to modify your existing top.v<\/strong> and bench.v<\/strong> files to use the nonblocking assignment operator where appropriate.<\/p>\nHere is what I have for my top.v<\/strong> file<\/p>\n`timescale 1ns \/ 1ns\r\nmodule top\r\n (\r\n input clk,\r\n input [7:0] switch,\r\n output reg [7:0] led\r\n );\r\n always @(posedge clk) led <= switch;\r\nendmodule\r\n<\/code><\/pre>\nAnd here is my bench.v<\/strong> file<\/p>\n`timescale 1ns \/ 1ns\r\nmodule bench;\r\n reg clk = 1;\r\n always #5 clk = ~clk;\r\n\r\n reg [7:0] switch;\r\n wire [7:0] led;\r\n top top\r\n (\r\n .clk(clk),\r\n .switch(switch),\r\n .led(led)\r\n );\r\n\r\n always @(posedge clk)\r\n switch <= $random;\r\n\r\n initial\r\n begin\r\n repeat (1000) @(posedge clk);\r\n $finish;\r\n end\r\n \r\nendmodule\r\n<\/code><\/pre>\nImproving the Test Bench<\/h1>\n
The waveform below shows the last few clock cycles of my simulation. The switch<\/em> and led<\/em> values are random. However, notice how the led<\/em> values lag behind the switch<\/em> values by one clock cycle. \u00a0This is to be expected, since the led<\/em> values are captured in flip-flops on the rising edge of clk<\/em>.<\/p>\n![\"Simulation](\"https:\/\/www.beyond-circuits.com\/wordpress\/wp-content\/uploads\/2015\/01\/Tutorial3_Sim1-300x53.png\")
<\/a>Simulation Waveform<\/p><\/div>\n
We will now\u00a0add a check to the test bench to compare the led<\/em> outputs with an expected result. The first thing to do is to generate the expected result, which will be simply the switch<\/em> variable delayed by one clock cycle.<\/p>\n reg [7:0] expected_led;\r\n always @(posedge clk)\r\n expected_led <= switch;<\/code><\/pre>\nThen, we will perform the comparison between the expected output and the actual output. We declare two integer variables called num_checks<\/em> and num_errors<\/em> and initialize them to zero. Integer variables are essentially signed 32-bit reg values. Then, on every clock edge, we perform a comparison. We’ll increment the number of checks counter for each time we perform this comparison, and increment the number of errors counter if the expected output does not match the actual output.<\/p>\n integer num_checks = 0;\r\n integer num_errors = 0;\r\n always @(posedge clk)\r\n begin\r\n num_checks = num_checks+1;\r\n if (expected_led != led)\r\n\tbegin\r\n\t $display(\"ERROR: led value %0x does not match expected value %0x at time %0fns\",\r\n\t\t led,expected_led,$realtime);\r\n\t num_errors = num_errors+1;\r\n\tend\r\n end<\/code><\/pre>\nFinally, we modify the always block that\u00a0stops our simulation so that it prints out a pass\/fail message. I like to keep track of the number of comparisons so I can ensure that the fail message actually means something. It’s not a very good test if it passes with no errors and no comparisons. The message for passing and failing is distinctive and similar to allow scripts to check your simulation results. It’s a great feeling when you\u00a0have the computer run hundreds of tests overnight, and then you come in the next morning to\u00a0see all those passed messages. Automated regression testing is an important part of real-world FPGA engineering.<\/p>\n
You should be able to make changes to your test bench and reproduce my results.<\/p>\n
Synthesizable Verilog<\/h1>\n
As a final note, I should point out that there are different subsets of the Verilog language for different purposes. In these tutorials, we will discuss the Synthesizable RTL and behavioral subsets. We used lots of constructs in our test bench which have no place in an FPGA design proper. After all, what is your FPGA supposed to do if it encounters a $finish<\/b> or $display<\/b> statement?<\/p>\n
In general, code which calls system tasks (those beginning with a dollar sign) are not synthesizable. Also, you can not use the #number<\/em> construct to advance time in RTL code. Technically, strictly speaking you can use the #number<\/em> construct in synthesizable code, but the synthesis tool will ignore it.<\/p>\n","protected":false},"excerpt":{"rendered":"In this tutorial, we are going to cover a little bit more on simulation. In addition, we’ll discuss an important subject that causes some confusion. Blocking Versus Non-Blocking Assignments The very observant reader of the last tutorial might have noticed … Continue reading
![\"Synthesized](\"https:\/\/www.beyond-circuits.com\/wordpress\/wp-content\/uploads\/2015\/01\/Tutorial3_Schematic1.png\")
<\/a>