myhdl-list

[myhdl-list] delta cycles

[Thomas H. <th...@ct...>]

Please consider a standard counter, something like this:

def Counter(clock, count):
     @always(clock.posedge)
     def logic():
         count.next = count + 1
     return logic

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.

Of course, MyHDL allows to simulate a propagation delay for the count
signal by specifying a delay parameter in the creation of the count
signal:

count = Signal(intbv(0)[16:], delay=1)

Typically, the signal instantiation takes place in the testbench, not
in the instance.  I would like to define the prop-delay in the instance;
I found two ways of doing that.

First:

def Counter(clock, count):
     @instance
     def logic():
         while 1:
             yield clock.posedge
             yield delay(1)
             count.next = count + 1
     return logic

Second (with an appropriate definition of the clone_signal() function):

def Counter(clock, count):
     count_internal = clone_signal(count, delay=1)
     @always(clock.posedge)
     def logic():
         count_internal.next = count_internal + 1
     @always_comb
     def output():
         count.next = count_internal
     return logic, output

I guess (haven't tried) the first one would create non-synthesizable
VHDL, but the second one should.


Thomas

Re: [myhdl-list] delta cycles

[Ben <ben...@gm...>]

On Thu, Apr 19, 2012 at 09:10, Thomas Heller <th...@ct...> wrote:
> Please consider a standard counter, something like this:
>
> def Counter(clock, count):
>     @always(clock.posedge)
>     def logic():
>         count.next = count + 1
>     return logic
>
> 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.
>

The solution I found that suited the most my need for this feature was
to alter the following line:

http://hg.myhdl.org/cgi-bin/hgwebdir.cgi/myhdl/file/7a860a7fb408/myhdl/_Signal.py#l86

And change the default value of delay from None to 1

The reasoning behind that is that is that you almost never want this
setting to be set per Signal, you want it project-wide or you're gonna
be stucked in inconsistency loops ... This has for unique consequence
to make the VCD easier to debug. The generated code will look exactly
the same.

The drawback of this method is that you have to set the duration of
your clock(s) accordingly so that your system be stable before the
next clock rises.

Regards,
Benoît.

> Of course, MyHDL allows to simulate a propagation delay for the count
> signal by specifying a delay parameter in the creation of the count
> signal:
>
> count = Signal(intbv(0)[16:], delay=1)
>
> Typically, the signal instantiation takes place in the testbench, not
> in the instance.  I would like to define the prop-delay in the instance;
> I found two ways of doing that.
>
> First:
>
> def Counter(clock, count):
>     @instance
>     def logic():
>         while 1:
>             yield clock.posedge
>             yield delay(1)
>             count.next = count + 1
>     return logic
>
> Second (with an appropriate definition of the clone_signal() function):
>
> def Counter(clock, count):
>     count_internal = clone_signal(count, delay=1)
>     @always(clock.posedge)
>     def logic():
>         count_internal.next = count_internal + 1
>     @always_comb
>     def output():
>         count.next = count_internal
>     return logic, output
>
> I guess (haven't tried) the first one would create non-synthesizable
> VHDL, but the second one should.
>
>
> Thomas
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] delta cycles

[Thomas H. <th...@ct...>]

Am 19.04.2012 10:22, schrieb Ben:
> On Thu, Apr 19, 2012 at 09:10, Thomas Heller<th...@ct...>  wrote:
>> Please consider a standard counter, something like this:
>>
>> def Counter(clock, count):
>>      @always(clock.posedge)
>>      def logic():
>>          count.next = count + 1
>>      return logic
>>
>> 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.
>>
>
> The solution I found that suited the most my need for this feature was
> to alter the following line:
>
> http://hg.myhdl.org/cgi-bin/hgwebdir.cgi/myhdl/file/7a860a7fb408/myhdl/_Signal.py#l86
>
> And change the default value of delay from None to 1
>
> The reasoning behind that is that is that you almost never want this
> setting to be set per Signal, you want it project-wide or you're gonna
> be stucked in inconsistency loops ... This has for unique consequence
> to make the VCD easier to debug. The generated code will look exactly
> the same.

Since I'm using factory functions to create my signals I can get a
similar effect by changing their 'delay=' default value.  Except if
MyHDL decides to create signals behind my back ;-).

> The drawback of this method is that you have to set the duration of
> your clock(s) accordingly so that your system be stable before the
> next clock rises.

Yes, it would be nice to be able to specify delay values smaller than
1ns; see my other post about the timescale.
Probably I should patch myhdl.traceSignals to report a timescale of
1ps to the vcd file, and get used to specify delay values in ps.

Thanks,
Thomas

Re: [myhdl-list] delta cycles

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

On 4/19/12 7:36 AM, Thomas Heller wrote:
> Am 19.04.2012 10:22, schrieb Ben:
>> On Thu, Apr 19, 2012 at 09:10, Thomas Heller<th...@ct...>   wrote:
>>> Please consider a standard counter, something like this:
>>>
>>> def Counter(clock, count):
>>>       @always(clock.posedge)
>>>       def logic():
>>>           count.next = count + 1
>>>       return logic
>>>
>>> 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.
>>>
>>
>> The solution I found that suited the most my need for this feature was
>> to alter the following line:
>>
>> http://hg.myhdl.org/cgi-bin/hgwebdir.cgi/myhdl/file/7a860a7fb408/myhdl/_Signal.py#l86
>>
>> And change the default value of delay from None to 1
>>
>> The reasoning behind that is that is that you almost never want this
>> setting to be set per Signal, you want it project-wide or you're gonna
>> be stucked in inconsistency loops ... This has for unique consequence
>> to make the VCD easier to debug. The generated code will look exactly
>> the same.
>
> Since I'm using factory functions to create my signals I can get a
> similar effect by changing their 'delay=' default value.  Except if
> MyHDL decides to create signals behind my back ;-).
>
>> The drawback of this method is that you have to set the duration of
>> your clock(s) accordingly so that your system be stable before the
>> next clock rises.
>
> Yes, it would be nice to be able to specify delay values smaller than
> 1ns; see my other post about the timescale.
> Probably I should patch myhdl.traceSignals to report a timescale of
> 1ps to the vcd file, and get used to specify delay values in ps.
>
> Thanks,
> Thomas
>
>

I think there could be a long and interesting conversation if this 
visual "delay" should be used or not.  In both Verilog/VHDL the default 
behavior is the no delay.  You have to explicitly state the delays in 
the assignments.

MyHDL is unique in that the MyHDL package is the HDL (the syntax and 
compiler to describe hardware behavior) and the simulator.  In my mind a 
better proposal, might be, additional arguments/methods to provide 
information to the simulator.  E.g. what is the *precision* in absolute 
time and should a _global_ propagation delay be used.

This would allow the HDL description to remain agnostic of absolute time 
and building in prop-delays that don't model anything other than a 
visual cue.

Regards,
Chris

Re: [myhdl-list] delta cycles

[Jan D. <ja...@ja...>]

On 04/19/2012 09:10 AM, Thomas Heller wrote:
> Please consider a standard counter, something like this:
>
> def Counter(clock, count):
>       @always(clock.posedge)
>       def logic():
>           count.next = count + 1
>       return logic
>
> 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.

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).

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

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

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

Re: [myhdl-list] delta cycles

[Thomas H. <th...@ct...>]

>>> 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.
>>

> 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.

Cool! Thanks for the hint.

Thomas

Re: [myhdl-list] delta cycles

[Jan D. <ja...@ja...>]

On 04/24/2012 04:06 AM, Christopher Felton wrote:
> On 4/23/12 5:39 AM, Jan Decaluwe wrote:

>>
>> 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.

Good catch! I had also searched for this but didn't find it
readily. After warping, you can then use 'Pattern Search' to
mark rising edges; it creates markers that run over the whole
waveform viewer window.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com