| ??? 09/21/07 21:07 Read: times Msg Score: +1 +1 Good Answer/Helpful |
#144897 - block vs nonblocking Responding to: ???'s previous message |
Russ Cooper said:
reg [15:0] clockDivider; // A 16-bit counter
reg outputBit; // 1 KHz, 20% duty cycle signal
always @(posedge clock50Mhz) begin // On 50 MHz clock rising edge
clockDivider = clockDivider + 1; // Bump the counter
if (clockDivider == 50000) begin // One millisecond has gone by
clockDivider = 0; // Reset the counter
end // End 'one msec has gone by'
outputBit = // Assert the output for 20%
(clockDivider < 10000) ? 1 : 0; // of the one ms period
end // End 'on 50MHz rising edge'
This works fine; the waveform on the physical output pin looks exactly as expected. However, I realized as I was fiddling around that you could get the same result in many, many, many different ways. One note: you used blocking assignments. For synchronous descriptions you should use non-blocking assignments. There is a significant difference. A blocking assignment is evaluated and the left-hand-side is updated immediately, while a non-blocking assignment is scheduled such that all of its right-hand side is evaluated immediately but the assignment to the LHS occurs at the end of the simulation cycle. Your code is a really good example of this. At the rising edge of the clock, the register clockDivider is incremented. THEN the comparison is executed, possibly resetting the counter. THEN the counter is tested to drive the state of outputBit. When you simulate this, you'll get something that "looks" correct but isn't. Look closer. Consider the case where clockDivider is 49999. After the rising edge of the clock, clockDivider will be immediately incremented and it will be 50000. The next statement, the comparison of clockDivider to 50000, will then evaluate to true, and then the counter will immediately clear. The next statement tests if clockDivider is less than 10000, which evaluates to true, because clockDivider was just cleared. But that's not how the hardware actually works. In real hardware, all three of the statements in that always block are executed in parallel. At the rising edge of the clock: a) clockDivider is incremented. b) The current value of clockDivider (BEFORE the increment) is compared to 50000. If the comparison is true, then clockDivider is supposed to be cleared. But wait: that conflicts with a)! So the second assignment overrides the first. So your simulation will show clockDivider changing from 49998 to 49999 to 0, where in reality the hardware will change from 49998 to 49999 to 50000 to 0. c) The current value of clockDivider (BEFORE the increment) is compared to 10000. If clockDivider is less than 10000, then outputBit is set, otherwise, it is cleared. Your simulation with blocking assignments will show outputBit being cleared simultaneously with the value of clockDivider changing to 10000. However, in reality, that can't happen because it's comparing the wrong value of clockDivider. Basically, the non-blocking assignment properly models synchronous processes, and the rule is simple: a synchronous process block MUST use non-blocking assignments, and combinatorial processes MUST use blocking assignments. Google for "Coding Styles That Kill." BTW, it's worth noting that VHDL does not give you the choice of blocking vs non-blocking assignments, as it only has non-blocking. (Yes, VHDL has variables, to which assignments ARE blocking, but they can only be used within a process and as such their utility is rightfully limited.) BTW: when you count starting at zero, comparing against 50000 gives you 50001 counts in each cycle. So you should compare against 49999 for your rollover. (Same for the deassertion of outputBit when compared to 10000; you should really test for 9999.) For example: always @(posedge clock50Mhz or negedge rst_l) begin
if (~rst_l) begin
clockDividerNB <= 0;
outputBitNB <= 1'b0;
end else begin
if (clockDividerNB == 49999) begin
clockDividerNB <= 0;
end else begin
clockDividerNB <= clockDividerNB + 1;
end
outputBitNB <= (clockDividerNB < 9999) ? 1 : 0;
end // else: !if(~rst_l)
end // always @ (posedge clock50Mhz or negedge rst_l)
Notice how I first test for 49999 and if true then I reset clockDivider, otherwise I count. This is the standard way to code a counter that can roll over. Yes, there is a subtle difference between rolling over at 50000 and rolling over at 49999, and in this example it's trivial. You didn't see anything out-of-sorts on your 'scope because you don't have the counter available at the pins. However, in other cases this can be a show-stopper. You should simulate this as it is illuminating. (In fact, stop futzing with your board and learn about how to write a good Verilog test bench and how to simulate your code. You will spend a lot less time scratching your head.) If you simulate this, you will notice something interesting about the assertion of outputBitNB ... good luck, -a |
