VHDL expert puzzle

On 27 Nov., 17:20, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> The crazy thing is that he says he does see a difference,
> in the sense that the version with delays "reveals the problem."
> In particular, he claims that the output clock clk_out
> never toggles in the version with delays, which is what
> he says he sees on the FPGA also.
>
> He includes waveforms and uses that observation to claim
> that "the mystery has been solved".
>
> But I see clk_out toggling correctly (as I would expect).
> In particular, in my simulations it toggles at exactly
> the same moments as in the version without delays.

I advice using delays in general to help debuging code and to detect
inadverted clock-2-data race conditions when clock is going over
several signal assignments, but for me, this means, that I usually
only delay signal assignments from clock edge in clocked process, in
usual code thats enough to see, if data changes before or after clock
edge.

This particular code is no example, of code in which I expect delays
to matter (when using correct simulator).
I can only guess, that the simulator the author is using messes up
with this two lines

>   process(clk,clk_i,lfsr,rst) begin
>          if rising_edge(clk) then

and execute the code inside the if rising_edge clause also in delta
cycles that have no rising clock edge. In that case the trouble might
result from a mixture of unlucky sensitivity list with broken
simulator and missing delays and any one of the three can be used to
fix this issue.

bye Thomas

On 11/28/2012 09:34 AM, Thomas Stanka wrote:
> On 27 Nov., 17:20, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>> The crazy thing is that he says he does see a difference,
>> in the sense that the version with delays "reveals the problem."
>> In particular, he claims that the output clock clk_out
>> never toggles in the version with delays, which is what
>> he says he sees on the FPGA also.
>>
>> He includes waveforms and uses that observation to claim
>> that "the mystery has been solved".
>>
>> But I see clk_out toggling correctly (as I would expect).
>> In particular, in my simulations it toggles at exactly
>> the same moments as in the version without delays.
>
> I advice using delays in general to help debuging code and to detect
> inadverted clock-2-data race conditions when clock is going over
> several signal assignments, but for me, this means, that I usually
> only delay signal assignments from clock edge in clocked process, in
> usual code thats enough to see, if data changes before or after clock
> edge.
>
> This particular code is no example, of code in which I expect delays
> to matter (when using correct simulator).
> I can only guess, that the simulator the author is using messes up
> with this two lines
>
>>    process(clk,clk_i,lfsr,rst) begin
>>           if rising_edge(clk) then
>
> and execute the code inside the if rising_edge clause also in delta
> cycles that have no rising clock edge.

A VHDL simulator broken in this way? Hard to imagine.


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

>
>I advice using delays in general to help debuging code and to detect
>inadverted clock-2-data race conditions when clock is going over
>several signal assignments, but for me, this means, that I usually
>only delay signal assignments from clock edge in clocked process, in
>usual code thats enough to see, if data changes before or after clock
>edge.
>
>bye Thomas
>

I can't understand your advice. For more than a decade I have used ModelSim
to
functionally verify chains of DSP modules and never needed to put any
delay
inside RTL code. In the top level testbench all inputs are generated on the

clocks so I wouldn't worry about delta delay problem.

Kaz


  	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On 11/27/2012 3:07 PM, Jan Decaluwe wrote:
> On 11/27/2012 07:22 PM, Christopher Felton wrote:
>
>> For giggles I ran the simulation, both are identical (except
>> clock_out is delayed by tpd in the second).
>
> Many thanks!
>
> Mm, that holds for the intermediate clock signal clk_i, but
> clk_out itself has no delay, correct?
>
Correct, I misstated.  Only the internal nets will see the added delay.

>>  The two waveforms he has
>> in the post are not on the same "zoom".  The first is zoomed way out
>> where you can see clock_out (solid for clock_in).  The second is
>> zoomed way in where you can see the individual clock_in.
>>
>> So, clock_out is probably toggling but he's not centered over an edge
>> to actually view it.
>
> Could that be it? He wouldn't have bothered to do a full zoom first?
> That would be such silly error that I admit I didn't consider it!
>
> My hypothesis of initially faulty code would be consistent
> with what he sees on the fpga.

I think your hypothesis is correct; we are missing part of the story. 
Either the code is not the original code, he had some other error in the 
process, or he ignored the timing reports and the second run he just 
happened to meet timing.  To your point, if he runs syn+P&R again, it 
might fail.  Nothing solved or fixed.


>
> Heck, perhaps I should just throw the towel. Noone on APP seems
> to care.
>

Which is odd, they should care.  In my mind that is the beauty of a 
technical *community*, in the end you get a much better result.  This is 
a perfect example, his goal was to show simulating/testing can be 
beneficial.  But his example *failed* to prove the point.  To the rescue 
the community ... except the author didn't want to participate?

In general this is bad, because the correct feedback is available to the 
author and it is not being fixed.  Hopefully, the poor quality will will 
only reflect on the author and not APP's reputations.  And yes, it 
doesn't seem like any progress is being made, what's the saying, the 
advice is falling on deaf ears.

>> If he used a self checking testbench he might
>> have caught it (or rather not caught it) instead of relying on
>> manually viewing the waveform.
>
> Of course. Actually, sometimes I think that if it's not
> self-checking, it shouldn't be called a testbench.

wiggle_bench

>
> It wouldn't be hard for a case like this (by checking edges,
> you can verify whether the generated clock with some
> frequence or period spec.)
>
> Jan
>

On 11/28/2012 3:17 AM, kaz wrote:
>>
>> I advice using delays in general to help debuging code and to detect
>> inadverted clock-2-data race conditions when clock is going over
>> several signal assignments, but for me, this means, that I usually
>> only delay signal assignments from clock edge in clocked process, in
>> usual code thats enough to see, if data changes before or after clock
>> edge.
>>
>> bye Thomas
>>
>
> I can't understand your advice. For more than a decade I have used ModelSim
> to
> functionally verify chains of DSP modules and never needed to put any
> delay
> inside RTL code. In the top level testbench all inputs are generated on the
>
> clocks so I wouldn't worry about delta delay problem.
>
> Kaz
>
>

I agree, I don't like and would not advocate adding these type of delays 
to behavioral simulations.  If you want a more "physical" simulation 
there are other methods.  If you don't trust the static timing analysis 
you can simulate gate-level structural simulation with back-annotated 
timing information.  You can do this with an FPGA and the FPGA tools. 
But this is usually not done because we typically are ok with the static 
timing results and then take it to the lab, for an FPGA.

Regards,
Chris

On 27/11/2012 14:44, Thomas Stanka wrote:
> On 26 Nov., 19:14, rickman <gnu...@gmail.com> wrote:
>> This is one of the reasons why I've never created a blog or other
>> "expert" column on the web.  I may be fairly experienced, but by writing
>> things like this blog I may be showing what things I *don't* know rather
>> than what I do... lol
>
> I sign this statement ;)
>

I would agree to this further.  For this puzzle, some vendor 
synthesisers have treated sensitivity lists differently and made 
different assumptions to complicate things still further.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

On Wed, 28 Nov 2012 03:17:44 -0600, kaz wrote:


>>I advice using delays in general to help debuging code and to detect
>>inadverted clock-2-data race conditions when clock is going over several
>>signal assignments, but for me, this means, that I usually only delay
>>signal assignments from clock edge in clocked process, in usual code
>>thats enough to see, if data changes before or after clock edge.
>>
> I can't understand your advice. For more than a decade I have used
> ModelSim to functionally verify chains of DSP modules and never needed
> to put any delay inside RTL code. In the top level testbench all inputs
> are generated on the 
> clocks so I wouldn't worry about delta delay problem.

I have sometimes had to put delays on I/O signals between my FPGA and 
vendor-supplied models, e.g. for memory devices, to make a board level 
behavioural simulation match the real world. 
If I didn't, data would appear a cycle early, or be written to an off-by-
one address, or the "data stable" eye would miss my sampling point, etc.

I think this is justifiable as making the FPGA model more closely match 
its real world behaviour, but I have never had to do the same internally!

- Brian

On 11/28/2012 02:15 PM, Mike Perkins wrote:
> On 27/11/2012 14:44, Thomas Stanka wrote:
>> On 26 Nov., 19:14, rickman <gnu...@gmail.com> wrote:
>>> This is one of the reasons why I've never created a blog or
>>> other "expert" column on the web.  I may be fairly experienced,
>>> but by writing things like this blog I may be showing what things
>>> I *don't* know rather than what I do... lol
>>
>> I sign this statement ;)
>>
>
> I would agree to this further.  For this puzzle, some vendor
> synthesisers have treated sensitivity lists differently and made
> different assumptions to complicate things still further.

There a issues at multiple levels with this. However
a major one has only to do with modeling and simulation,
namely whether adding the delays should make a difference
to the behavior of the clock output (as he claims),
or not (which is what we see and expect).

Any standard VHDL simulator should give the same answer here.

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

On Nov 25, 9:11=A0pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> In the following link, a design is presented that alledgedly
> has a flaw. The claim is that this is a simple case and
> that any experienced designer will see the flaw immediately.
>
> (I don't.)
>
> http://www.programmableplanet.com/author.asp?section_id=3D2551&doc_id=3D2=
...
>
> --
> Jan Decaluwe - Resources bvba -http://www.jandecaluwe.com
> =A0 =A0 =A0Python as a HDL:http://www.myhdl.org
> =A0 =A0 =A0VHDL development, the modern way:http://www.sigasi.com
> =A0 =A0 =A0World-class digital design:http://www.easics.com

An original code is o.k. except for bad style, as mentioned by just
about everybody above, and for kludgy idea to use MLSR to divide
clock.
At least what's implemented is real 14-bit MLSR with period =3D 2^14-1.
It appears to divide the input clock by 24998 and that's supposedly
was an original intention. Or did he tried to divide by 25000? Or, may
be he really divides by 25000 and I miscalculated by one somewhere?
Anyway, it's pretty close :-)

A "fixed" code is much worse.
It, supposedly unintentionally, implements 15-bit LSR with
period=3D7905, i.e. *not* MLSR. Input clock is divided by 11684. It's
sounds damn unlikely that that was an intention.

On Nov 27, 5:10=A0pm, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
wrote:
> On 25 Nov., 20:11, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>
> > In the following link, a design is presented that alledgedly
> > has a flaw. The claim is that this is a simple case and
> > that any experienced designer will see the flaw immediately.
>
> If this code is from an experienced designer I see that much flaws,
> that have no effect of synthesis or simulation itself, but on
> readability.
> The sensitivity list is horrible and will cause unnecessary simulator
> load, the code indention is best effort to confuse readers. Some code
> beautify would do better. And as simple as this design is, a real
> world code without any comments is only good for protecting your
> failures from reviewers.
>
> The usage of integer as start value for a lfsr is quite error prone. A
> hex value would be easier to read and would allow to design this
> module without integer or unsigned values.

On this one, and only this one, I disagree.

> That clk_out is missing in reset path leads to one cycle latency of
> rst to clk_out, that is most likely not intended here. But you could
> only guess if that has impact on system or is even necessary.


I also don't like naming synchronous reset 'rst'. I'd rather prefere
'srst" or 'sreset'.

> If there is an abvious error in cycle lenght (be it start value or
> feedback function), you can see this in simulation. I assume if you
> use lfsr, you know that you should double check this, if you are not
> really sure what you are doing.
>
> bye Thomas

Just about everything he wrote on the second page makes no sense.