Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 154525

Article: 154525
Subject: Re: Set-up and hold times and metastability
From: rickman <gnuarm@gmail.com>
Date: Fri, 23 Nov 2012 16:43:01 -0500
Links: << >>  << T >>  << A >>
On 11/22/2012 11:59 PM, Jon Elson wrote:
> James823 wrote:
>
>> Hi,
>>
>> I've been looking at synchronising data across clock domains, and have
>> managed to confuse myself.
>> Can someone confirm (or correct me) that the following is true.
>>
>> Metastability may occur if the input D changes value during the set-up and
>> hold times, however the enable can be completely asynchronous without ever
>> causing a problem?
>>
>> If not, then even something as simple as testing a switch is pressed would
>> cause problems right?
> Metastability on modern CMOS processes is a pretty rare event.  Supposedly,
> Xilinx has found that the window for metastability on their FFs is
> no more than a couple of ps wide!  So, unless you have extremely fast
> data rates or a timing that puts the transition right over the window,
> it could take years for you to get one true metastable event.

I don't have the stats memorized, but I don't think this is an accurate 
description.  If you design is truly async then the rate is such that 
with a number of units in the field you will likely see failures long 
before the warranty period is up... lol  But by providing even as little 
as two nanoseconds of settling time the probability is hugely reduced so 
that it would then be years if not centuries between failures for 
thousands of units.

But this is also related to the significance of a failure.  If it is a 
router handling Internet traffic in a user's home, I think a failure 
once a month per unit will never be noticed.  If it is a more critical 
application a failure once a decade across the product line might be a 
problem.


> The real logic hazard is for a signal that changes near the clock
> edge to propagate through the chip in such a way that the transition
> arrives before the clock at some FFs, and after the clock at some
> others, either due to routing or combinatorial delays.  A simple
> state machine can be sent to never-never land when this occurs.
> By properly synchronizing when crossing clock boundaries, you
> allow the tools to be sure that no signal can change state too
> close to the setup time and cause such a hazard.

Static timing analysis is typically used to eliminate such timing 
problems.  That is FPGA 101 type stuff.  Timing tools can't help you 
with clock crossings, but they are easy to do if you pay attention and 
don't miss any... that is the domain of project management.


> Many people claim such problems were metastability, when they were
> more prosaic logic hazards.

Yes, the two are sometimes confused.

Rick

Article: 154526
Subject: Re: Set-up and hold times and metastability
From: Mike Perkins <spam@spam.com>
Date: Fri, 23 Nov 2012 21:57:52 +0000
Links: << >>  << T >>  << A >>
On 23/11/2012 21:31, rickman wrote:
> On 11/22/2012 1:40 PM, Mike Perkins wrote:
>> On 22/11/2012 17:33, rickman wrote:
>>> On 11/22/2012 9:35 AM, Mike Perkins wrote:
>>>>
>>>> Simplest is to use a fast clock, where the clock rate is many
>>>> times the data rate. The original data clock can be sampled to
>>>> determine when it transitions and the data read when it should
>>>> be stable, if necessary using suitably delayed data using
>>>> parallel latches.
>>>
>>> What??? How do you "sample" the input without dealing with
>>> metastability in those samples?
>>
>> By taking a latched clock being high say for 2 High-Speed clocks
>> before accepting it as a real clock-high.
>
> You aren't seeing the picture.  This doesn't solve metastability in
> any meaningful way.  The edge detection logic can still be "glitched"
> by metastability and disrupt the rest of the circuit.

I didn't explain myself very well.

The technique I was eluding to (badly) regards noisy and slow inputs
(such as from a PS2 mouse) is to have a counter; to count up when the
input is high, and to count down when the input is low.  The output
would only be changed to a "1" if the counter was at maximum and changed
to a "0" if the counter was at minimum.

> Easier is just to run the slow clock input through two FFs with no
> logic between them and getting a metastability minimized signal.
> Then you can use it as you wish.

I agree and I said earlier the same about being latched through two FFs.


>>> Another way to deal with the problem is to minimize and
>>> encapsulate it. This means using a single clock for the entire
>>> FPGA design other than the I/O interfaces where you sync the
>>> signals as soon as possible.
>>
>> Entirely agree, but that's not always possible.
>
> When is this not possible?  The only limitation would be that the
> "master" clock to rule them all has to be the fastest by enough
> margin to accommodate the jitter in the two clocks.  This prevents
> ever missing a transition.

I was thinking of a modem example I came across where there were two
clocks at near FPGA max speed; where each interface could wander in
frequency either way.  Given it was dealing with packets of data, it was
much easier to a Block RAM FIFO to cross clock domains.


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

Article: 154527
Subject: Re: Set-up and hold times and metastability
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 23 Nov 2012 22:07:30 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> On 11/22/2012 1:40 PM, Mike Perkins wrote:

(snip)
>> By taking a latched clock being high say for 2 High-Speed clocks before
>> accepting it as a real clock-high.
 
> You aren't seeing the picture.  This doesn't solve metastability in any 
> meaningful way.  The edge detection logic can still be "glitched" by 
> metastability and disrupt the rest of the circuit.
 
> Easier is just to run the slow clock input through two FFs with no logic 
> between them and getting a metastability minimized signal.  Then you can 
> use it as you wish.

Well, how do you check if a signal was high for two clock cycles?
Seem to me that you delay it through two FF's and AND them together.

That could ignore real signals that are high for a short enough time,
but there really shouldn't be any of those. Doesn't seem a bad thing
to do in many cases. 

Metastability resolves exponentially. It is pretty much only a problem
when the signal goes into logic with a propagation delay a large
fraction, maybe 80% or 90% of a clock cycle. In that case, the extra FF
multiplies the resolution time by a factor of 5 or 10, which decreases
the probability of a problem by a power of 5 to 10. 

If it could happen one in 1e9 clock cycles without the extra FF, then
it will then be one in 1e45 to 1e90 clock cycles. 

A am pretty sure no circuit has ever survives 1e90 clock cycles. 

-- glen

Article: 154528
Subject: Re: Set-up and hold times and metastability
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 23 Nov 2012 22:38:03 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> On 11/22/2012 11:59 PM, Jon Elson wrote:

(snip)

>> Metastability on modern CMOS processes is a pretty rare event.  Supposedly,
>> Xilinx has found that the window for metastability on their FFs is
>> no more than a couple of ps wide!  So, unless you have extremely fast
>> data rates or a timing that puts the transition right over the window,
>> it could take years for you to get one true metastable event.

For an asynchronous system, you usually assume that the probability
is uniform in time. So a 1GHz clock, with a pulse every ns, will
hit your 1ps window on in every 1000 times, about every microsecond.
 
> I don't have the stats memorized, but I don't think this is an accurate 
> description.  If you design is truly async then the rate is such that 
> with a number of units in the field you will likely see failures long 
> before the warranty period is up... lol  But by providing even as little 
> as two nanoseconds of settling time the probability is hugely reduced so 
> that it would then be years if not centuries between failures for 
> thousands of units.

Well, an important thing left out is the resolution time. You need two
numbers, the window size (or probability) of going into a metastable
state, and the time constant (it goes into an exponent) on how long
you stay in that state. Even if the window is 1ps, if it resolves in
100ps you aren't likely to see it. (You really can't set the clock
period less than 90% of the actual delay, though most of that should
be included in the specifications.) 
 
> But this is also related to the significance of a failure.  If it is a 
> router handling Internet traffic in a user's home, I think a failure 
> once a month per unit will never be noticed.  If it is a more critical 
> application a failure once a decade across the product line might be a 
> problem.

Yes. But once it gets into the lifetime of the universe range,
it is usually good enough. 
 
>> The real logic hazard is for a signal that changes near the clock
>> edge to propagate through the chip in such a way that the transition
>> arrives before the clock at some FFs, and after the clock at some
>> others, either due to routing or combinatorial delays.  A simple
>> state machine can be sent to never-never land when this occurs.
>> By properly synchronizing when crossing clock boundaries, you
>> allow the tools to be sure that no signal can change state too
>> close to the setup time and cause such a hazard.
 
> Static timing analysis is typically used to eliminate such timing 
> problems.  That is FPGA 101 type stuff.  Timing tools can't help you 
> with clock crossings, but they are easy to do if you pay attention and 
> don't miss any... that is the domain of project management.

Well, you have to have at least on FF on an asynchronous input.

Metastability says you should have two.

That still leaves the problem of multiple inputs. For FIFO's, the
solution is to use gray code. You get either the previous or new value
of the count, never any other values. 
 
>> Many people claim such problems were metastability, when they were
>> more prosaic logic hazards.
 
> Yes, the two are sometimes confused.

Yes, both the single and multiple input case show up in actual
designs.

-- glen

Article: 154529
Subject: Re: Set-up and hold times and metastability
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 23 Nov 2012 22:48:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
Mike Perkins <spam@spam.com> wrote:
> On 23/11/2012 21:31, rickman wrote:
>> On 11/22/2012 1:40 PM, Mike Perkins wrote:

>>> By taking a latched clock being high say for 2 High-Speed clocks
>>> before accepting it as a real clock-high.

>> You aren't seeing the picture.  This doesn't solve metastability in
>> any meaningful way.  The edge detection logic can still be "glitched"
>> by metastability and disrupt the rest of the circuit.
 
> I didn't explain myself very well.
 
> The technique I was eluding to (badly) regards noisy and slow inputs
> (such as from a PS2 mouse) is to have a counter; to count up when the
> input is high, and to count down when the input is low.  The output
> would only be changed to a "1" if the counter was at maximum and changed
> to a "0" if the counter was at minimum.

OK, this is for decoding the output of a quadrature encoder.

Even if you know the maximum rate, in the mouse case, how fast
the mouse could move, if it is sitting right on the edge the
outputs can change very often, or even stay between "0" and "1".

The fast clock method works well in that case. Properly designed,
only one input can be in a bad state at once, and the output can
switch between those values (+1 and -1).

-- glen

Article: 154530
Subject: Re: Set-up and hold times and metastability
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 23 Nov 2012 23:09:00 +0000 (UTC)
Links: << >>  << T >>  << A >>
James823 <3681@embeddedrelated> wrote:
 
> I've been looking at synchronising data across clock domains, and have
> managed to confuse myself.
> Can someone confirm (or correct me) that the following is true.
 
> Metastability may occur if the input D changes value during the set-up and
> hold times, however the enable can be completely asynchronous without ever
> causing a problem?

The article http://www.technion.ac.il/~sbeer/publications/p3.pdf
seems to have some pretty good data (actual numbers) on 
metastability.

-- glen

Article: 154531
Subject: Re: Set-up and hold times and metastability
From: "James823" <3681@embeddedrelated>
Date: Fri, 23 Nov 2012 21:49:00 -0600
Links: << >>  << T >>  << A >>
>James823 <3681@embeddedrelated> wrote:
> 
>> I've been looking at synchronising data across clock domains, and have
>> managed to confuse myself.
>> Can someone confirm (or correct me) that the following is true.
> 
>> Metastability may occur if the input D changes value during the set-up
and
>> hold times, however the enable can be completely asynchronous without
ever
>> causing a problem?
>
>The article http://www.technion.ac.il/~sbeer/publications/p3.pdf
>seems to have some pretty good data (actual numbers) on 
>metastability.
>
>-- glen
>

Ahh you read my mind - I was just about to ask!
Thanks, I'll give it a read.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154532
Subject: Re: Set-up and hold times and metastability
From: "kaz" <3619@embeddedrelated>
Date: Sat, 24 Nov 2012 01:27:31 -0600
Links: << >>  << T >>  << A >>
>>James823 <3681@embeddedrelated> wrote:
>> 
>>> I've been looking at synchronising data across clock domains, and have
>>> managed to confuse myself.
>>> Can someone confirm (or correct me) that the following is true.
>> 
>>> Metastability may occur if the input D changes value during the set-up
>and
>>> hold times, however the enable can be completely asynchronous without
>ever
>>> causing a problem?

When it comes to enable (or reset), devices differ in the way they
implement 
it.

enable or reset may be available as ports on flips(designed at silicon
level)
or they may be applied through logic on the D port. In this second case
enable
or reset are directly involved in D value.

In the case enable or reset are ports then it is matter of silicon design
but
I know altera defines timing violation in terms of D or enable or reset 
release.

I usually visualise the flip as if it is in "sleep mode" when under reset
or
not enabled. Once it wakes up it should do so away from timing
window even if D is stable (but has changed value compared to current Q) 
It is all eventually an issue of sampling a stable input or sampling by a 
stable device.

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

Article: 154533
Subject: Re: Set-up and hold times and metastability
From: Jon Elson <elson@pico-systems.com>
Date: Sat, 24 Nov 2012 23:59:32 -0600
Links: << >>  << T >>  << A >>
rickman wrote:


> I don't have the stats memorized, but I don't think this is an accurate
> description.  If you design is truly async then the rate is such that
> with a number of units in the field you will likely see failures long
> before the warranty period is up... lol  But by providing even as little
> as two nanoseconds of settling time the probability is hugely reduced so
> that it would then be years if not centuries between failures for
> thousands of units.
> 
Yes, I certainly don't recommend NOT using the classic dual-rank
FF to synchronize across clock boundaries.  I'd want to be
conservative.
> But this is also related to the significance of a failure.  If it is a
> router handling Internet traffic in a user's home, I think a failure
> once a month per unit will never be noticed.  If it is a more critical
> application a failure once a decade across the product line might be a
> problem.
Well, especially in TCP traffic, as long as the failure doesn't
lock up the router, it would be a pretty benign failure.
> 
>> The real logic hazard is for a signal that changes near the clock
>> edge to propagate through the chip in such a way that the transition
>> arrives before the clock at some FFs, and after the clock at some
>> others, either due to routing or combinatorial delays.  A simple
>> state machine can be sent to never-never land when this occurs.
>> By properly synchronizing when crossing clock boundaries, you
>> allow the tools to be sure that no signal can change state too
>> close to the setup time and cause such a hazard.
> 
> Static timing analysis is typically used to eliminate such timing
> problems.  That is FPGA 101 type stuff.  Timing tools can't help you
> with clock crossings, but they are easy to do if you pay attention and
> don't miss any... that is the domain of project management.

Static timing finds real violations in propagation delay, but
totally misses non-synchronized signals coming from off-chip.
A static analysis says everything is fine, meaning that all signals
generated WITHIN that clock domain meet the setup/hold requirements.
And, I challenge you to find ANY logic designer who hasn't, at
one time, missed putting a proper synchronizer on a signals that
crossed a clock boundary.  I sure know I have done it, and have
been on projects where others have done it.
> 
>> Many people claim such problems were metastability, when they were
>> more prosaic logic hazards.
> 
> Yes, the two are sometimes confused.

And, that was really the big point I was trying to make, that what
the OP was asking about was most likely NOT a real metastability
problem, but a need to synchronize all inputs that cross a clock
boundary.

Jon

Article: 154534
Subject: Re: Set-up and hold times and metastability
From: "kaz" <3619@embeddedrelated>
Date: Sun, 25 Nov 2012 04:09:12 -0600
Links: << >>  << T >>  << A >>

>Static timing finds real violations in propagation delay, but
>totally misses non-synchronized signals coming from off-chip.
>A static analysis says everything is fine, meaning that all signals
>generated WITHIN that clock domain meet the setup/hold requirements.
>And, I challenge you to find ANY logic designer who hasn't, at
>one time, missed putting a proper synchronizer on a signals that
>crossed a clock boundary.  I sure know I have done it, and have
>been on projects where others have done it.
>> 

True, static timing analysis can only check paths between two registers and

will ignore the first set of fpga input registers (unless it has info on
external device output timing), any asynchronous input coming offchip and 
external device input registers(unless it has info on external device input

timing). But it (or at least TimeQuest) default checks clock domain
transfers 
unless the path is set false.

Whether metastability occurs or not, it remains a fact that timing
violations
certainly cause immediate failures (may be corrected by freezing) and these

may be due to logic errors at sampling.

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

Article: 154535
Subject: VHDL expert puzzle
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Sun, 25 Nov 2012 20:11:43 +0100
Links: << >>  << T >>  << A >>
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=2551&doc_id=254705&

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

Article: 154536
Subject: Re: VHDL expert puzzle
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Sun, 25 Nov 2012 20:49:51 +0100
Links: << >>  << T >>  << A >>
Le 25/11/2012 20:11, Jan Decaluwe a écrit :
> 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=2551&doc_id=254705&
>
The feedback term is 0 when the LFSR is all 0s so it won't count because 
it resets to all 0s.

Nicolas

Article: 154537
Subject: Re: VHDL expert puzzle
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Sun, 25 Nov 2012 20:50:43 +0100
Links: << >>  << T >>  << A >>
Le 25/11/2012 20:49, Nicolas Matringe a écrit :
> Le 25/11/2012 20:11, Jan Decaluwe a écrit :
>> 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=2551&doc_id=254705&
>>
>>
> The feedback term is 0 when the LFSR is all 0s so it won't count because
> it resets to all 0s.

Or maybe not... What's that 'xnor' operator ? I've never used it before.

Nicolas


Article: 154538
Subject: Re: VHDL expert puzzle
From: Alan Fitch <apf@invalid.invalid>
Date: Sun, 25 Nov 2012 19:56:44 +0000
Links: << >>  << T >>  << A >>
On 25/11/12 19:49, Nicolas Matringe wrote:
> Le 25/11/2012 20:11, Jan Decaluwe a écrit :
>> 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=2551&doc_id=254705&
>>
> The feedback term is 0 when the LFSR is all 0s so it won't count because 
> it resets to all 0s.
> 
> Nicolas
> 
I don't think so - with XOR gates you mustn't use all zeros, but he's
used XNOR, so you mustn't use all '1's.

regards
Alan

-- 
Alan Fitch

Article: 154539
Subject: Re: VHDL expert puzzle
From: Alan Fitch <apf@invalid.invalid>
Date: Sun, 25 Nov 2012 20:02:30 +0000
Links: << >>  << T >>  << A >>
On 25/11/12 19:11, Jan Decaluwe 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=2551&doc_id=254705&
> 

I guess it also depends what he means by flaw. The only signal required
in the sensitivity list is clk; and if he'd made LFSR type unsigned, he
wouldn't have needed the type conversions.

But I guess that doesn't affect functionality (which I assume is what is
meant by a flaw). Perhaps I should read the second page of the post...

Of course it may just be that the feedback taps on the LFSR are wrong
for a maximal length sequence, but I can't be bothered to look that up :-)

Alan

-- 
Alan Fitch

Article: 154540
Subject: Re: VHDL expert puzzle
From: "kaz" <3619@embeddedrelated>
Date: Sun, 25 Nov 2012 14:10:59 -0600
Links: << >>  << T >>  << A >>
Haven't looked well but about the only unusual thing is the sensitivity
list and the the author's explanation which is wrong. D0 is synchronised
because it is dependent on lfsr bits. The author should say that he needed
one clock latency functionally on D0 instead.

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

Article: 154541
Subject: Re: VHDL expert puzzle
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Sun, 25 Nov 2012 21:13:29 +0100
Links: << >>  << T >>  << A >>
On 11/25/2012 09:02 PM, Alan Fitch wrote:
> On 25/11/12 19:11, Jan Decaluwe 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=2551&doc_id=254705&
>>
>
> I guess it also depends what he means by flaw. The only signal required
> in the sensitivity list is clk; and if he'd made LFSR type unsigned, he
> wouldn't have needed the type conversions.
>
> But I guess that doesn't affect functionality (which I assume is what is
> meant by a flaw).

Correct. The superfluous signals in the sensitivity list are
messy, but they don't affect behavior.

> Perhaps I should read the second page of the post...

I think you may find it interesting.

> Of course it may just be that the feedback taps on the LFSR are wrong
> for a maximal length sequence, but I can't be bothered to look that up :-)

Of course not. Again, he claims that an experienced designer
would see it immediately.

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

Article: 154542
Subject: Re: VHDL expert puzzle
From: Alan Fitch <apf@invalid.invalid>
Date: Sun, 25 Nov 2012 20:22:03 +0000
Links: << >>  << T >>  << A >>
On 25/11/12 20:13, Jan Decaluwe wrote:
> On 11/25/2012 09:02 PM, Alan Fitch wrote:
>> On 25/11/12 19:11, Jan Decaluwe 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=2551&doc_id=254705&
>>>
>>
>> I guess it also depends what he means by flaw. The only signal required
>> in the sensitivity list is clk; and if he'd made LFSR type unsigned, he
>> wouldn't have needed the type conversions.
>>
>> But I guess that doesn't affect functionality (which I assume is what is
>> meant by a flaw).
> 
> Correct. The superfluous signals in the sensitivity list are
> messy, but they don't affect behavior.
> 
>> Perhaps I should read the second page of the post...
> 
> I think you may find it interesting.
>
OK I cracked and read it.

I don't really understand what's going on, I would have to simulate it
(though of course you've already done that Jan!).

I agree there's something fishy about adding output delays. What
difference would that make in this case?



>> Of course it may just be that the feedback taps on the LFSR are wrong
>> for a maximal length sequence, but I can't be bothered to look that up :-)
> 

By moving the assignment to d0 into the process, he has implied another
flip-flop, which makes me think that my guess that the feedback taps are
wrong is correct - though there's no way an experienced designer could
spot that (unless they'd memorized that table in XAPP 210 - I've
memorized the app note number, but not the table :-) ).

> Of course not. Again, he claims that an experienced designer
> would see it immediately.

Mysteriouser and mysteriouser...

Alan
> 
> Jan
> 


-- 
Alan Fitch

Article: 154543
Subject: Re: VHDL expert puzzle
From: rickman <gnuarm@gmail.com>
Date: Sun, 25 Nov 2012 15:27:02 -0500
Links: << >>  << T >>  << A >>
On 11/25/2012 2:11 PM, Jan Decaluwe 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=2551&doc_id=254705&
>

I see two things I would flag.  One is the fact that they include 
extraneous signal names in the sensitivity list.  This can cause a 
simulation to run slowly, but I've never seen a synthesizer to create 
different logic because of it.

The other is the omission of a reset assignment for the signal clk_out 
which is registered.  This means the reset will simply disable the 
clk_out FF from changing state when rst is asserted, but otherwise the 
circuit will function normally.

I don't see an error that will stop the design from working.

The use of XNOR gates in the feedback means the all 1s state will latch 
up while the use of XOR gates in the feedback means the all 0s state 
will latch up.  The XNOR is just an XOR with the output inverted which 
is the same as either one of the inputs inverted or all three inverted. 
  Thinking of it as all three inverted clearly shows the symmetry of the 
latch up states.

Rick

Article: 154544
Subject: Re: VHDL expert puzzle
From: rickman <gnuarm@gmail.com>
Date: Sun, 25 Nov 2012 15:53:17 -0500
Links: << >>  << T >>  << A >>
On 11/25/2012 3:27 PM, rickman wrote:
> On 11/25/2012 2:11 PM, Jan Decaluwe 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=2551&doc_id=254705&
>>
>>
>
> I see two things I would flag. One is the fact that they include
> extraneous signal names in the sensitivity list. This can cause a
> simulation to run slowly, but I've never seen a synthesizer to create
> different logic because of it.
>
> The other is the omission of a reset assignment for the signal clk_out
> which is registered. This means the reset will simply disable the
> clk_out FF from changing state when rst is asserted, but otherwise the
> circuit will function normally.
>
> I don't see an error that will stop the design from working.
>
> The use of XNOR gates in the feedback means the all 1s state will latch
> up while the use of XOR gates in the feedback means the all 0s state
> will latch up. The XNOR is just an XOR with the output inverted which is
> the same as either one of the inputs inverted or all three inverted.
> Thinking of it as all three inverted clearly shows the symmetry of the
> latch up states.
>
> Rick

Looking at Page 2 of the article I don't see what he is going on about. 
  I don't think he knows either...  The first response in his blog is 
trying to grapple with what seems to be an error in his analysis and his 
response is...

"Oh i dunno, its far too early in the morning ;-)

anyway the point is it didn't work and now it does Hurrah!!, and hitting 
things with hammers when they don't work, although satisfying, does get 
expensive."

I'm not going to read 6 pages of reverse sequence blog to try to 
understand the gist of this conversation, but clearly the original 
article is just a big goof on the author's part.

I hope no newbies read it and get very confused by all the nonsense.

One blog comment is rather pertinent.  Hamster said, "I'm quite sure 
that a good test bench will be far more complex than the unit under 
test, and far harder to write."  This has been my experience and I think 
this point should be emphasized with engineers time and time again! 
Writing code is easy.  Writing verified code, not so much.

Rick

Article: 154545
Subject: Re: VHDL expert puzzle
From: "kaz" <3619@embeddedrelated>
Date: Sun, 25 Nov 2012 14:54:58 -0600
Links: << >>  << T >>  << A >>
The big flaw is the combinatorial feedback of bit 0. since d0 <=
xnor...bit0 
and bit0 is assigned do.

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

Article: 154546
Subject: Re: VHDL expert puzzle
From: "kaz" <3619@embeddedrelated>
Date: Sun, 25 Nov 2012 15:09:21 -0600
Links: << >>  << T >>  << A >>
>The big flaw is the combinatorial feedback of bit 0. since d0 <=
>xnor...bit0 
>and bit0 is assigned do.
>
>Kaz	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>

sorry correcting myself: there is one register between bit0 and d0.
I believe the author has wrong observation.
if simulation worked it should work in hardware.
The fact that it didn't then it worked by moving d0 to clocked process is
fishy.

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

Article: 154547
Subject: Re: VHDL expert puzzle
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Mon, 26 Nov 2012 00:31:58 +0100
Links: << >>  << T >>  << A >>
On 11/25/2012 08:11 PM, Jan Decaluwe 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=2551&doc_id=254705&
>

I thank each one of you very much for the comments.

It's good to talk to people who care about these matters
and know what they are talking about. On APP, there was
almost no progress during 5 (five!) days.

Even better, one of the comments inspired me to construct
an hypothesis of what went wrong here. Alan Fitch wondered
why lfsr was not an unsigned to make the comparison nicer.

Suppose that in his original code (not the one he posted)
the comparison would be with a bitstring of the wrong
size. That would always fail and explain the behavior
that he describes.

He may have misunderstood the fix when making changes
to the code. Where he then gets his strange explanations
is anybody's guess.

Thanks,

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

Article: 154548
Subject: Re: VHDL expert puzzle
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Mon, 26 Nov 2012 18:36:44 +0100
Links: << >>  << T >>  << A >>
Le 25/11/2012 21:53, rickman a écrit :

> One blog comment is rather pertinent.  Hamster said, "I'm quite sure
> that a good test bench will be far more complex than the unit under
> test, and far harder to write."  This has been my experience and I think
> this point should be emphasized with engineers time and time again!
> Writing code is easy.  Writing verified code, not so much.

Rule of thumb I once heard is to put twice as much engineers in 
verification as there are in design.
Funnily, the company I worked for at the time did exactly the reverse. 
And surprisingly they were kicked out of the project (and I resigned)

Nicolas


Article: 154549
Subject: Re: VHDL expert puzzle
From: rickman <gnuarm@gmail.com>
Date: Mon, 26 Nov 2012 13:14:46 -0500
Links: << >>  << T >>  << A >>
On 11/25/2012 6:31 PM, Jan Decaluwe wrote:
> On 11/25/2012 08:11 PM, Jan Decaluwe 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=2551&doc_id=254705&
>>
>>
>
> I thank each one of you very much for the comments.
>
> It's good to talk to people who care about these matters
> and know what they are talking about. On APP, there was
> almost no progress during 5 (five!) days.
>
> Even better, one of the comments inspired me to construct
> an hypothesis of what went wrong here. Alan Fitch wondered
> why lfsr was not an unsigned to make the comparison nicer.
>
> Suppose that in his original code (not the one he posted)
> the comparison would be with a bitstring of the wrong
> size. That would always fail and explain the behavior
> that he describes.
>
> He may have misunderstood the fix when making changes
> to the code. Where he then gets his strange explanations
> is anybody's guess.

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

Rick



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search