Values of signals AT the rising/falling edge

[TheGreatNed]

Hi,

My verilog, $display and EPWave are all disagreeing about the value of a signal at it's rising edge.

I'm a noob I guess   What is the rule of thumb for signals sampled exactly at their rising/falling edge? Do the sampled signals take the 'last' value or 'new'?


Code is very simple:

Code: [Select]

initial begin
      $dumpfile("dump.vcd");
      $dumpvars;
     
      #5;
      rst = 0;
      a<=1;
     
      #3
      rst = 1;
      a<=0;
     
      #1
      a<=1;
   
      $display("time:%tns, a:%d, clk:%d, f:%d", $time, a, vif.clk, f);
     
      #20;
      $finish;
end
VCS gives:
time:90ns, a:0, clk:0, f:z


As you can see, VCS and $display are disagreeing. Why?

Thank you!!!!!

[ataradov]

What happens if you change the last assignment to a blocking one ("a=1;")?

I'm not sure if evaluation rules apply to things like  $display(), but if they are, then  $display() is correct.

Although for any sort of practical situations it does not matter. This will lead to meta-stability issues.

[TheGreatNed]

Last assignment changed to 'a=1':
time:90ns, a:1, clk:0, f:z

So a=1 correctly blocks $display, but the other values surprisingly were unaffected

[ataradov]

What other values?

Blocking assignment becomes a "synchronization point". All non-blocking assignments are executed in parallel.

In your first case assignment and $display() executed at the same time, making both use the original value of 'a'. The assignment obviously did not care what the value of 'a' is, but $display() did.

[TheGreatNed]

What other values?

Blocking assignment becomes a "synchronization point". All non-blocking assignments are executed in parallel.

In your first case assignment and $display() executed at the same time, making both use the original value of 'a'. The assignment obviously did not care what the value of 'a' is, but $display() did.

I figured 'a=1' would give clk and f enough time to realize their 'new' values. But I guess it is best to never assume a rising or falling edge is a 1 or a 0.

I wonder if it makes sense to write code that always sets up data on the neg-edges of a clock and leaves the posedge for sampling?

[ataradov]

I wonder if it makes sense to write code that always sets up data on the neg-edges of a clock and leaves the posedge for sampling?

It makes sense to have all synchronous logic use non-blocking assignments and always operate on the same edge. Most often posedge is used.

This closely reflects how actual hardware works. And that also gives the most time for data to setup before the next clock edge.

[Bassman59]

I figured 'a=1' would give clk and f enough time to realize their 'new' values. But I guess it is best to never assume a rising or falling edge is a 1 or a 0.

I wonder if it makes sense to write code that always sets up data on the neg-edges of a clock and leaves the posedge for sampling?

None of the code presented is synchronous to a clock edge. It’s all written in the form of delays, and those delays are subject to the assignment type of blocking vs non-blocking (and you really need to understand the difference) as well as the order in which the assignments are written (vital for blocking assignments).

If you re-write your code so that all signals change on a clock edge and that they are all non-blocking assignments, this sort of delta-cycle ambiguity goes away. Use @(posedge clk) to wait for that event. Your code doesn’t do that.

As for setting up data on the falling edge and sampling on the rising edge, there’s no need for that if everything is properly written to be synchronous to the clock. When you do this, the signals drive on a delta after one clock edge and are sampled with the next clock edge, exactly as you’d expect in a real system. The only difference between your simulation and a real design is that your model has an infinitesimal (delta) clock-to-out, zero prop delay, and zero setup to the next clock.

[TheGreatNed]

If I did wait for the clock, what is the 'rule of thumb' for signals changing at the clock edge? For example:

Code: [Select]

@(posedge clk)
a <= 1;
f <= 1;

$display("a:%d, f:%d", a, f);
Or

Code: [Select]

always @(posedge clk or negedge clk)
  a <= clk;

always @(posedge clk)
  data <= a;

Can I really rely on this that a or data will be the 'new' values 100% of the time?

[ataradov]

The first case would print the old values. In this test-bench (non-synthesizeable) style use blocking assignments to get what you want.

In the second case I'm not exactly sure what you mean. If you mean what will be in the 'data', then it will be the value of 'a' just before the positive clock edge. So in this case it would always be 1, which was assigned at negedge of 'clk', and the value of 'clk' before the negedge was 1.

[ejeffrey]

I thought that was undefined which order separate always blocks execute when triggering on the same edge and that non blocking assignment is only deferred until the end of the current block.  In that case the second example would be undefined.

[ataradov]

It would not be undefined because first block contains "negedge clk" in the sensitivity list. That's where a will be assigned a stable value. And there is no way "posedge clk" would be undefined, since it will absolutely break every single design out there.

[Bassman59]

The first case would print the old values. In this test-bench (non-synthesizeable) style use blocking assignments to get what you want.

Just to clarify for "the Great Ned," what Alex means here is that on the rising edge of the clock, a is scheduled to be assigned the value 1 and f is also scheduled to be assigned the value 1. This is what the non-blocking assignment does: at the time of the trigger event (in this case, the rising edge of clk), it evaluates all of the right-hand-sides of the signals which are triggered, in this case, a and f. The evaluation here is trivial, it's just the constant 1. But for more complex statements, all of the signals on that right-hand side are "captured," and using those values the combinatorial logic on the RHS is worked out. And by "scheduled," we mean that all right-hand-sides of all signals triggered by the event in question. (A large FPGA design may have hundreds of signals all sensitive to the rising edge of the clock!)

However, the $display function is blocking. That means it will use whatever value is currently driven on its inputs (a and f in this case). These are the values of those signals before the scheduled update takes place. This is why is prints, as Alex says, "the old values."

Homework: what should the output of the following always block be? And why?

Code: [Select]

always @(posedge clk) begin
    counter <= counter + 1;
    foobar <= counter;
end

[Bassman59]

If I did wait for the clock, what is the 'rule of thumb' for signals changing at the clock edge? For example:

Code: [Select]

always @(posedge clk or negedge clk)
  a <= clk;

always @(posedge clk)
  data <= a;

Can I really rely on this that a or data will be the 'new' values 100% of the time?

In this case (and it's bizarre and you'd never do it, but ...), what will happen is clear.

On the rising edge of clk, we look at the current values of clk and a. Assuming an initializer on a (clearing to 0), and that a rising edge means clk is 1, this means we schedule an assignment to a of 1, and we schedule an assignment to data of 0 (the initial value of a).

The next thing that happens (of interest) is a falling edge on clk. This schedules a new assignment to a, of 0. Since the other always block is not sensitive to the falling edge of clk, it doesn't get triggered. data remains the same.

Then there's another rising edge of clk. This again schedules a new assignment of 1 to a. It also schedules a new assignment to data. It uses the current value of a -- which is 0 (from the negedge event).

And so forth. It helps to draw it out on paper.

[ataradov]

That case is somewhat interesting. In theory "data" would always be 0. But in practice with naive synthesis with real elements with delays, "a" would be assigned 1 on the negedge. Basically if you directly connect "clk" to the clock and data inputs.

So I wonder if tools will recognize this and will actually attempt to simulate ideal simulation result with non-ideal building blocks. This never happens is real life, so I have no idea and I'm too lazy to try.

[ataradov]

Well, ok, curiosity got the best of me. Here is what Lattice Diamond  generated.

It basically only kept the posedge part and literally connected clk to the input. The log also contains this warning "WARNING - demo.v(11): assignment under multiple single edges is not supported for synthesis. VERI-1466".

So real tools don't want to do anything with that craziness.

And yes, what the value of "a" would be in a real hardware depends on the internal propagation delays within the logic block.

[SiliconWizard]

Code: [Select]

always @(posedge clk or negedge clk)
  a <= clk;

Note that most FPGAs don't have dual-edge flip-flops, so the above code will either be reject by the synthesis tool, or it will at least yield warnings and will be implemented in a way that is likely to give you timing issues, and/or not even act on both edges at all.

Usually, the only structures that support dual-edge stuff on FPGAs are IOBs supporting DDR, but of course what you can do with this is restricted and won't usually be inferred from "general-purpose" code.

[Bassman59]

That case is somewhat interesting. In theory "data" would always be 0. But in practice with naive synthesis with real elements with delays, "a" would be assigned 1 on the negedge. Basically if you directly connect "clk" to the clock and data inputs.

I thought this discussion was all about simulation. A synthesizer will barf on everything presented here.

So I wonder if tools will recognize this and will actually attempt to simulate ideal simulation result with non-ideal building blocks. This never happens is real life, so I have no idea and I'm too lazy to try.

It will simulate — no problem. Whether the results are what are expected is the question.

[Bassman59]

Well, ok, curiosity got the best of me. Here is what Lattice Diamond  generated.

It basically only kept the posedge part and literally connected clk to the input. The log also contains this warning "WARNING - demo.v(11): assignment under multiple single edges is not supported for synthesis. VERI-1466".

So real tools don't want to do anything with that craziness.

And yes, what the value of "a" would be in a real hardware depends on the internal propagation delays within the logic block.

Diamond is a synthesis tool, and as such, synthesis barfed, as expected. Try it in ModelSim or in Active-HDL.

[ataradov]

I'm aware, but have assumed that there is more than purely theoretical interest.