VHDL expert puzzle

On Nov 28, 5:50=A0pm, Michael S <already5cho...@yahoo.com> wrote:
> 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.

Oh, another style flow is xnor.
The only valid use of xnor is when you want to obfuscate your
intentions.

On 28 Nov., 10:17, "kaz" <3619@embeddedrelated> 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.

In DSP I guess you have in general only one clk and all modules
synchonous.

Consider a larger design using IP (and maybe several clock with some
relation).
the following construct might be hidden within some IP most likley
over hierarchy boundaries and more difficult to detect.

Clk1 <= Clk when Selected else Other_Clk';
[..]
Clk2 <= Clk1 when Enabled else '0';
[..]
process (Clk)
  if rising_edge(Clk) then
     A <= B;
[..]
process (Clk2)
  if rising_edge(Clk2)
     B<= A;

Clk2 changes 2 delta after Clk, therefore in simulation registers A
and B won't exchange their value every clock cycle, instead  both
registers will have same content after rising edge while the code is
written in a correct way. Have fun debugging why simulation is not
working as expected in such a case.

With the same mechanism you could create examples where simulation
without delay is correct, but HW after Synthesis wrong in which case a
delay would have helped you detecting it faster in waveform.

bye Thomas

Actually your example does not quite demonstrate the point you were making.=
  In your example, you have actual function (the muxing and enabling) betwe=
en the clocks so you're describing a gated clock system.  That system, if b=
uilt, could very well behave exactly as you have described but not be what =
the designer intended simply because the designer did not account for the c=
lock skew.  The simulation without the added delay very well may describe t=
he actual hardware.  In this case, adding the delay 'to fix the simulation'=
 would be sweeping the design error under the rug until it eventually is un=
covered in real hardware.

To demonstrate your point though you simply need to generate the new clock =
as this:

clk1 <=3D clk;

Then clock things with 'clk' and 'clk1' and watch them not work.  In this i=
nstance the 'clk1 <=3D clk;' assignment would not be implemented in any har=
dware but the simulator would be off by a delta cycle.

Kevin Jennings

On Wed, 28 Nov 2012 17:43:38 -0800, KJ wrote:

> clk1 <= clk;
> 
> Then clock things with 'clk' and 'clk1' and watch them not work.  In
> this instance the 'clk1 <= clk;' assignment would not be implemented in
> any hardware but the simulator would be off by a delta cycle.
> 
> Kevin Jennings

Even funnier when the clock assignment is helpfully implemented for you, 
in a vendor's memory module...

- Brian

On Wed, 28 Nov 2012 13:20:14 +0000, Brian Drummond wrote:

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


I've had to put (simulation-only) delays on internal signals.

There was one version of Xilinx's block ram in their Verilog unisim 
library that was broken.  IIRC, the bug had something to do with a delay 
on the clock inside the unisim model.

Synthesis was fine, but it didn't give the right result in simulation 
until I modified my source code to add a delay on the signals feeding the 
ram.

I think it might have been the version of unisim that came with ISE 10.1.


Regards,
Allan

On 11/28/2012 10:50 AM, Michael S wrote:
> On Nov 27, 5:10 pm, Thomas Stanka<usenet_nospam_va...@stanka-web.de>
> wrote:
>> 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.

I had a bit of confusion on this one myself.  Not that he was using an 
integer per-se, but that he didn't explain in a comment why this value 
was important or how it was derived.  I had to consider that this value 
was ill-conceived and didn't want to bother with looking up the LFSR and 
calculating where this value would appear in the sequence, etc.  It 
would have been useful if he had added a comment saying the length of 
the loop is xxx clocks or yyy time.


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

I think for FPGAs it is very common to specify an async reset to assign 
the configuration value of each FF, so I have come to expect async 
resets.  But if they use a sync reset, it doesn't bother me.  I don't 
expect that aspect of the reset to be part of the name.  I think resets 
are complex enough that they should be designed and documented at the 
system level.


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

Yes, I'm not sure what he was thinking.  It is a bit funny how he 
responds to this in the blog.  He starts out discussing it a little 
defensively and after three or four rounds of increasing defensiveness 
on his side he says something like, "Just forget about it".  I expect it 
was a bit embarrassing to make a mistake so publicly.  I'm sure we have 
all made similar mistakes, the kind where we slap the side of our head 
and say, "what was I thinking?"  But to do it publicly is a different 
matter.

I think the "Just forget about it" comment was on the second page of 
comments and there were six when I read it.  So I guess he is getting 
beat up pretty badly.  I feel for him.

Rick

On 11/28/2012 10:55 AM, Michael S wrote:
>
> Oh, another style flow is xnor.
> The only valid use of xnor is when you want to obfuscate your
> intentions.

I don't understand.  What would you use in place of xnor?  In LFSRs 
there are two ways of coding them.  Using the XOR function creates two 
loops, one being the all zeros state.  Using the XNOR function creates 
two loops, one being the all ones state.  What is wrong with using the 
XNOR function to describe a LFSR with the all ones state as the excluded 
state?

Rick

"rickman" <gnuarm@gmail.com> wrote in message 
news:k97ral$oin$1@dont-email.me...
> On 11/28/2012 10:55 AM, Michael S wrote:
>>
>> Oh, another style flow is xnor.
>> The only valid use of xnor is when you want to obfuscate your
>> intentions.
>
> I don't understand.  What would you use in place of xnor?  In LFSRs there 
> are two ways of coding them.  Using the XOR function creates two loops, 
> one being the all zeros state.  Using the XNOR function creates two loops, 
> one being the all ones state.  What is wrong with using the XNOR function 
> to describe a LFSR with the all ones state as the excluded state?

I think the problem is not the LFSR, but that the XNOR operation can be 
non-intuitive.

For example:   a XNOR b XNOR c  is equivalent to a XOR b XOR c
Since there is an even number of inversions, the inversions cancel out.
In the given example, there is an odd number of XNORs, so it works as 
written.

My preferred style would be.    d <= NOT (a XOR b XOR c);

- Kerry

On Nov 29, 4:50=A0pm, "Kerry Imming" <kcimm...@pobox.com> wrote:
>
> I think the problem is not the LFSR, but that the XNOR operation can be
> non-intuitive.
>
> For example: =A0 a XNOR b XNOR c =A0is equivalent to a XOR b XOR c
> Since there is an even number of inversions, the inversions cancel out.
> In the given example, there is an odd number of XNORs, so it works as
> written.
>
> My preferred style would be. =A0 =A0d <=3D NOT (a XOR b XOR c);
>
> - Kerry

Yes, that's exactly what I meant to say.

On 11/29/2012 03:22 PM, rickman wrote:

> I think the "Just forget about it" comment was on the second page of
> comments and there were six when I read it.  So I guess he is getting
> beat up pretty badly.  I feel for him.

I wouldn't worry too much :-) Let me summarize.

Let's be clear about how bad this really is. He describes
the simulation with delays, and draws all kinds of
nonsensical conclusions from it. However, by simulating
his code, everybody can verify that it simply doesn't behave
in the way he describes. He makes his points while
misrepresenting his own (public!) code.

For days, I have been trying to point out that there is
something fundamentally wrong here :-) No reaction from
the community on APP on this particular point. In
the end, the OP came back and stated (screamed) that
he "just does not care whether his code works or not".
Those who do "are missing the point". (I think he means
that he should be praised for using the word "testbench").

Guess what: again no reaction to this date on APP.
The only behavior that has been criticized is my
own, for calling this article "sloppy". (I confess.)

In short, he is getting away with this.

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