Re: [myhdl-list] delta cycles

[Christopher F. <chr...@gm...>]

On 4/23/12 5:39 AM, Jan Decaluwe wrote:
<snip>
>> When this counter is simulated, count changes a delta cycle after
>> the positive clock edge.  When traceSignals is used to write a VCD file,
>> gtkwave shows that the count changes exactly at the same time as the
>> clock edge.  This is confusing (at least in more complicated cases) in
>> the timing diagram.
>
> This is typical in the zero-delay RTL methodology: delta
> cycles are a way to define causality within zero time.

Just to clarify, what we are talking about is the following:

ts ....................  (simulation time step)
C  ___|---|___|---|___|  (clock)
D  ___|-------|________  (clocked signal)
Q  ___________|-------|  (clocked signal)
       0       1

The D and Q are "clocked" on the posedge.  Visually this can be 
confusing because it is not visually clear which value is "clocked" on 
the posedge.

The delay cycle provides a visual queue.

ts ....................  (simulation time step)
C  ___|---|___|---|___|  (clock)
D  ____|-------|________ (clocked signal)
Q  ____________|-------| (clocked signal)
       0       1

The delay in the signal visually clarifies where the signal is clocked. 
  There is no visual ambiguity what value is clocked on the posedge.  In 
this simple example it is easy to follow but in a more complex display 
it can be confusing?

>
> I think most RTL designers cope with it (at least I did)
> by developing a "clocks are special" mindset.
>
> In fact, clocks are the only signals where such confusion is
> possible. Therefore, I think measures such as a default delay
> for all signals are overkill (and can lead to other types
> of confusion).

Is this practically speaking because we usually only "edge" on clocks. 
But generally it would occur for any @always(<signal>.posedge).

>
> I once saw a waveform viewer that allowed to visualize
> delta cycles, but also here I think that is overkill.
>
> If it is really a problem, I think the best way would be
> solve it a the waveform viewer level, e.g. by moving
> a clock trace backwards a little. But I am thinking
> aloud, don't know if there are waveform viewers that
> can do this.
 >
 > Jan

I am not aware of any viewer that allows the clock (or any signal) to 
shifted slightly.  But this does seem to be a common problem with other 
designers / students I have run across.

... (15 minutes elapse)

But then I decided to poke around GTKwave.  And it looks like you can 
use the "time warp" feature to do this.  I simply selected a signal 
(clk) and the used the "Edit->Time Warp->Warp Marked" and then typed in 
"-1 ns" and the clk signal was shifted to the left 1ns.

To make this useful you need to change the "delay" in the clock to 
something of significant value (depending how much you want it skewed). 
  If you use delay(1) and time warp -1 ns you will shift by half a clock 
cycle.

Regards,
Chris