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

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 153975

Article: 153975
Subject: Re: accumulator (again)
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Fri, 6 Jul 2012 09:43:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Thu, 05 Jul 2012 11:04:36 -0700, jmariano wrote:

> Hi Rick, tanks for your help.
> 
>> I'm not real clear on your description of your design, but if you are
>> really generating clocks from the 50 MHz, I recommend that inside the
>> FPGA you instead use a single clock and generate clock enables for the
>> various functions.
> 
> Yes, I generate a 5 MHz clock inside the module from the main 50 MHz
> clock by simple division by 10 because I need a 5 MHz adc clock. I can't
> use clock enable because the AD9058 adc does not have a enable input,
> just clock.

That's OK.

But you need to register the AD9058 outputs, inside the FPGA, to your 
internal 50MHz clock. I would also register the S input and the U,V 
outputs from the switch. (In fact I would make the switch a synch process 
with only "clk" in its sensitivity list - it will effectively register 
the switch outputs for you)

All these can be combined into a single synchronous process.

	-- assuming u,v,r,i,adcnn are all signed!
	process(clk)
	begin
           if rising_edge(clk) then
		-- First pipe stage... synchronise the inputs
		if adc_enable then	-- 10 MHz, when ADC is stable
		    adc0_int 	<= adc0;	
		    ...
	        end if;
		-- Second pipe stage... add the (synchronised inputs)
		u 		<= adc0_int - adc90_int;	
		v 		<= ...
		-- I assume "s" has to be synchronised to "adcnn" 
		-- so pipeline it to the same depth (also syncs it)
		s_int 	<= s;
		s_int2 	<= s_int;
		-- Third pipe stage ... the switch
		case s_int2 is when "00" =>
			r <=  u;
			i <=  v;
		    when "01" =>
		...
		end case;
		-- etc
            end if;
	end process;

Addition at 50MHz in a Spartan-3 should be no problem. 

As your sample rate is 1/10 of the clock rate, I would expect you can 
afford a few cycles for internal processing. (If this is not the case you 
need to think carefully about how you pipeline the design)

>> I don't see anything in your original post about simulation.  
> Sorry about that, I did, in fact, simulate each module and the top
> entity. The behavior simulation gives the expected results, the post and
> place simulation gives same errors that I could not understand, 

Excellent. 
Before changing the design, I would sim with low level zero-crossing 
signals, and see which inputs (s, ADCs) and internal signals (U,V, R,I) 
are unstable whenever the large unexpected outputs are occurring.

Then what you need to do to fix will be clear.

You can also install multiple versions in the testbench, asserting their 
outputs are the same, and reporting any difference.

- Brian 


Article: 153976
Subject: Re: Generate a pulse with a definite width
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Fri, 6 Jul 2012 08:00:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 6, 5:01=A0pm, Thomas Heller <thel...@ctypes.org> wrote:
> Am 05.07.2012 17:37, schrieb Kolja Sulimma:
>
>
>
> >> I'm wondering if it wouldn't be faster to compare on zero, load with 1=
00,
> >> and count down.
>
> > Don't compare at all.
> > Use a signed count value with one extra bit, start at N-2, count down,
> > and stop if highest bit is set (or reload in your case).
>
> In principle, this should not make a difference. =A0The counter must
> compare the lower bits anyway to decide whether to toggle the higher
> bits.

Exactly. And if you are smart you define the counter in a way that the
same adder can be used for both instead of using two adders.
(The solution described by my parent poster compares =3D=3D0 and <0 in the
same clock cycle. This needs two adders of N bits or registering of a
temporary result.
My proposal uses only one adder of N+1 bits.

Kolja
www.cronologic.de

Article: 153977
Subject: XC9500XL keeper ?
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 06 Jul 2012 18:12:23 -0500
Links: << >>  << T >>  << A >>
I just migrated a project from the XCV9500 to the XC9500XL, and am having
some problems with keepers on the used inputs.  Looking at Xilinx' docs
on the 9500XL series, it looks like the keeper may be left on ALL
the inputs, not just UNUSED pins.  You seem to have a choice between
a keeper and a pulldown (GND) option.  Is there a way to turn off the
keeper on selected inputs?  (Seems like the answer is no, but just
checking.)  I have a reset pushbutton with a debounce RC and a
crystal oscillator that need to be tweaked to work OK with the keeper
in the circuit.  I'm using web pack 10.1 in Linux, if that makes a
difference.

Thanks for any suggestions!

Jon

Article: 153978
Subject: Re: XC9500XL keeper ?
From: Gabor <gabor@alacron.com>
Date: Fri, 6 Jul 2012 18:23:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, July 6, 2012 7:12:23 PM UTC-4, Jon Elson wrote:
> I just migrated a project from the XCV9500 to the XC9500XL, and am having
> some problems with keepers on the used inputs.  Looking at Xilinx' docs
> on the 9500XL series, it looks like the keeper may be left on ALL
> the inputs, not just UNUSED pins.  You seem to have a choice between
> a keeper and a pulldown (GND) option.  Is there a way to turn off the
> keeper on selected inputs?  (Seems like the answer is no, but just
> checking.)  I have a reset pushbutton with a debounce RC and a
> crystal oscillator that need to be tweaked to work OK with the keeper
> in the circuit.  I'm using web pack 10.1 in Linux, if that makes a
> difference.
> 
> Thanks for any suggestions!
> 
> Jon

It was my understanding that the Keeper vs Pulldown is a global
option, but between that and tristate can be selected pin by pin.
Used input pins normally have to have a keeper or pulldown constraint
in the .ucf file.  With neither constraint the input should be high
impedance.  You will get an error if you try to have keeper and
pulldown in the same project, but you should be able to have
keepers on just selected inputs.  If you need to make individual
settings to unused pins, you need to add the pins to the design.

-- Gabor

Article: 153979
Subject: Re: accumulator (again)
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Fri, 06 Jul 2012 21:00:22 -0500
Links: << >>  << T >>  << A >>
In article <nZ-dnch1rrNvHG_SnZ2dnUVZ_qSdnZ2d@web-ster.com>,
 Tim Wescott <tim@seemywebsite.please> writes:

>Paranoid logic designers will have a string of two or three registers to 
>avoid metastability, but I've been told that's not necessary.  (I'm not 
>much of a logic designer).

Ahh, but are they paranoid enough?

The key is settling time.

In the old days of TTL chips, a pair of FFs (with no logic in between)
got you settling time of as much logic as the worst case delay for
the rest of the system.  In practice, that was enough.

With FPGAs, routhing is important.  A pair of FFs close together
is probably good enough.  If you put them on opposite sides of a big
chip, the routing delays may match the long path of the logic delays
and eat up all of your slack time.

Have any FPGA vendors published recent metastability info?
(Many thanks to Peter Alfke for all his good work in this area.)

I'm not a silicon wizard.  Is it reasonable to simulate this stuff?
I'd like to know worst case rather than typicals.  It should be possible
to do something like verify simulations with lab typicals and then
use simulations to find the numbers for the nasty corners.

-- 
These are my opinions.  I hate spam.


Article: 153980
Subject: Re: XC9500XL keeper ?
From: Jon Elson <elson@pico-systems.com>
Date: Fri, 06 Jul 2012 23:56:21 -0500
Links: << >>  << T >>  << A >>
Gabor wrote:


> 
> It was my understanding that the Keeper vs Pulldown is a global
> option, but between that and tristate can be selected pin by pin.
> Used input pins normally have to have a keeper or pulldown constraint
> in the .ucf file.  With neither constraint the input should be high
> impedance.  You will get an error if you try to have keeper and
> pulldown in the same project, but you should be able to have
> keepers on just selected inputs.  If you need to make individual
> settings to unused pins, you need to add the pins to the design.
Well, that's the quirk!  As far as I can tell, it has a keeper on
all USED inputs, and I am not specifying that - I think.
Digital inputs are not bothered by the keeper, but it is interfering
with the input pin of the clock oscillator and the reset RC
circuit.  I seem to have the impedances of these circuits pulled down
low enough now that it is working, but I worry I may have reduced
the margin on those circuits.  What I'd like would be a "no-keeper"
option in the UCF file, but I don't see any such thing.

Thanks,

Jon

Article: 153981
Subject: Re: XC9500XL keeper ?
From: Michael Karas <mkaras@carousel-design.com>
Date: Sat, 7 Jul 2012 04:25:51 -0700
Links: << >>  << T >>  << A >>
[This followup was posted to comp.arch.fpga and a copy was sent to the 
cited author.]

In article <dN2dnSI6rMgiXGrSnZ2dnUVZ_jednZ2d@giganews.com>, elson@pico-
systems.com says...
> 
> Gabor wrote:
> 
> 
> > 
> > It was my understanding that the Keeper vs Pulldown is a global
> > option, but between that and tristate can be selected pin by pin.
> > Used input pins normally have to have a keeper or pulldown constraint
> > in the .ucf file.  With neither constraint the input should be high
> > impedance.  You will get an error if you try to have keeper and
> > pulldown in the same project, but you should be able to have
> > keepers on just selected inputs.  If you need to make individual
> > settings to unused pins, you need to add the pins to the design.
> Well, that's the quirk!  As far as I can tell, it has a keeper on
> all USED inputs, and I am not specifying that - I think.
> Digital inputs are not bothered by the keeper, but it is interfering
> with the input pin of the clock oscillator and the reset RC
> circuit.  I seem to have the impedances of these circuits pulled down
> low enough now that it is working, but I worry I may have reduced
> the margin on those circuits.  What I'd like would be a "no-keeper"
> option in the UCF file, but I don't see any such thing.
> 
> Thanks,
> 
> Jon

Maybe the message here is reset supervisor chip and oscillator.

-- 

Michael Karas
Carousel Design Solutions
http://www.carousel-design.com

Article: 153982
Subject: Re: XC9500XL keeper ?
From: "jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Sun, 08 Jul 2012 09:49:16 -0500
Links: << >>  << T >>  << A >>

>
>Maybe the message here is reset supervisor chip and oscillator.
>

I Agree. 

You really have to be careful when your digital IC vendor tells you that
the pads have "pullups and pulldowns". They don't, they have current
sources and current sinks. 

The PC board guys love to have them because they think that they don't have
to put real ones on the PCA but if you look at the current spec they  are
usually speced to +100 -50 %.  If you try to put any sort of analog
filtering on the pad then this range will make it hard to add any
hi-impedance circuitry.

If you can't disable them then you must us an external buffer

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

Article: 153983
Subject: Re: accumulator (again)
From: rickman <gnuarm@gmail.com>
Date: Sun, 8 Jul 2012 15:38:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 6, 10:00 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> In article <nZ-dnch1rrNvHG_SnZ2dnUVZ_qSdn...@web-ster.com>,
>  Tim Wescott <t...@seemywebsite.please> writes:
>
> >Paranoid logic designers will have a string of two or three registers to
> >avoid metastability, but I've been told that's not necessary.  (I'm not
> >much of a logic designer).
>
> Ahh, but are they paranoid enough?
>
> The key is settling time.
>
> In the old days of TTL chips, a pair of FFs (with no logic in between)
> got you settling time of as much logic as the worst case delay for
> the rest of the system.  In practice, that was enough.
>
> With FPGAs, routhing is important.  A pair of FFs close together
> is probably good enough.  If you put them on opposite sides of a big
> chip, the routing delays may match the long path of the logic delays
> and eat up all of your slack time.
>
> Have any FPGA vendors published recent metastability info?
> (Many thanks to Peter Alfke for all his good work in this area.)
>
> I'm not a silicon wizard.  Is it reasonable to simulate this stuff?
> I'd like to know worst case rather than typicals.  It should be possible
> to do something like verify simulations with lab typicals and then
> use simulations to find the numbers for the nasty corners.

I'm not sure what you would want to simulate.  Metastability is
probabilistic.  There is For a given length of settling time there is
some probability of it happening.  Increasing the settling time
reduces the probability but it will never be zero meaning there is no
max length of time it takes for the output of a metastable ff to
settle.

Is that what you are asking?

Rick

Article: 153984
Subject: Re: XC9500XL keeper ?
From: rickman <gnuarm@gmail.com>
Date: Sun, 8 Jul 2012 15:42:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 8, 10:49=A0am, "jt_eaton"
<z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
> >Maybe the message here is reset supervisor chip and oscillator.
>
> I Agree.
>
> You really have to be careful when your digital IC vendor tells you that
> the pads have "pullups and pulldowns". They don't, they have current
> sources and current sinks.
>
> The PC board guys love to have them because they think that they don't ha=
ve
> to put real ones on the PCA but if you look at the current spec they =A0a=
re
> usually speced to +100 -50 %. =A0If you try to put any sort of analog
> filtering on the pad then this range will make it hard to add any
> hi-impedance circuitry.
>
> If you can't disable them then you must us an external buffer
>
> John Eaton

RC circuits on reset lines are very bad ideas anyway.  They may work
well if the circuit if off for some amount of time, but if you get a
momentary glitch they can fail to reset at all leaving the circuit in
an undefined state because the power glitch disrupted the circuitry.

Rick

Article: 153985
Subject: Re: XC9500XL keeper ?
From: "jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Sun, 08 Jul 2012 18:45:45 -0500
Links: << >>  << T >>  << A >>

>
>RC circuits on reset lines are very bad ideas anyway.  They may work
>well if the circuit if off for some amount of time, but if you get a
>momentary glitch they can fail to reset at all leaving the circuit in
>an undefined state because the power glitch disrupted the circuitry.
>
>Rick
>

With todays chips there is also the problem with separate pad and core 
voltages. The RC is on the pad supply and may create a reset that is long
gone before the core voltage can ramp up.

You have to have a voltage supervisor on ALL of the supplies.


John Eaton

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

Article: 153986
Subject: Re: The definition of comnatorial prcess?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 9 Jul 2012 05:15:14 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
(snip)

>> http://en.wikipedia.org/wiki/Flip-flop_%28electronics%29#Master.E2.80...

(snip)
> I'm  not sure what point you are trying to make.  The issue at hand is
> whether the tools should be able to infer an edge triggered ff from an
> HDL combinatorial description of the gates that make up such a
> device.  To make a gate design work correctly requires careful
> analysis of delays to preclude the two enables from overlapping.
> However if I describe two latches with a proper logical description
> why can't the tool infer a ff in an FPGA?  Logically it is correct and
> it will give the correct behavior in simiulation.  Isn't that what
> really matters, not whether the tool can design an edge sensitive ff
> from LUTs but if the description is adequate to infer a ff?

OK, I suppose I agree with that one. Though I am not so sure that
any of the tools would actually figure it out. Normally, you 
use the negedge or posedge (in verilog, or equivalent in VHDL)
that specifically asks for an edge triggered FF. 

If you do actually manage with gates and delays to make something
that is logically correct, I would be surprised if it worked at all.

As far as I know, it is usual for the tools to ignore any delay
statements. Without delays, any delay based latch or FF will fail.

-- glen

Article: 153987
Subject: Re: accumulator (again)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 9 Jul 2012 05:25:31 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:
(snip)
>> >> But it does not work in this way, it behaves in a strange manner...

>> >> Some times I get the expected results but often I get strange values
>> >> (large when they should be small, often negative instead of positive,
>> >> etc.). If I look at the binary representation of the output, it looks
>> >> like if the output din't had time to sum and propagate to the output
>> >> again. In fact, the post place and route simulation shows that when the
>> >> enb signal goes to 0, the output stays in a undetermined condition (you
>> >> know, red line with XXXX).

(snip)
> It isn't just the paranoid logic designer, it should be every 
> logic designer.  

> A single register only partially solves the problem of an 
> asynchronous input with multiple register destinations, but it 
> does not solve the very real metastability problem.  
> At least two registers should be used to ensure that the 
> metastability condition has resolved and with increasing 
> clock frequency and finer process nodes using three or more 
> stages may be necessary.

Metastability can be a problem, but often the problem is clocking
multiple FFs off the same clock edge, with different delays on 
either the clock or data. (The chance of the delays being exactly
equal is close to zero.) The two effects are different.

Note, for example, the common FIFO implementation using a
gray code counter (or binary to gray code converter). 
That avoids the clock edge problem, as either value will
work correctly. 

Metastability is a different problem, but one that also occurs
when using asynchronous input values.

-- glen

Article: 153988
Subject: Re: accumulator (again)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 9 Jul 2012 05:38:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
(snip)

>> > Paranoid logic designers will have a string of two or three registers to
>> > avoid metastability, but I've been told that's not necessary.  (I'm not
>> > much of a logic designer).

(snip)
> Hi Ed.  They way it was explained to me, I believe from Peter Alfke,
> is that what really resolves metastability is the slack time in a
> register to register path.  Over the years FPGA process has resulted
> in FFs which only need a couple of ns to resolve metastability to 1 in
> a million operation years or something like that (I don't remember the
> metric, but it was good enough for anything I do).  It doesn't matter
> that you have logic in that path, you just need those few ns in every
> part of the path.  In theory, even if you use multiple registers with
> no logic, what really matters is the slack time in the path and that
> is not guaranteed even with no logic.  So the design protocol should
> be to assure the slack time from the input register to all subsequent
> registers have sufficient slack time.

I suppose that is true, but really it shouldn't be a problem.
It is usual for many systems to clock as fast as you can,
consistent with the critical path delay. As metastability
is exponential, even a slightly shorter delay is usually enough
to make enough difference in the exponent.

That assumes that there is a FF to FF path that is faster than
the FF logic FF path. I believe that is usual for FPGAs, but
if you manage to get a critical path with only one LUT, then
I am not so sure. But that is pretty hard in most real systems.

> Do you remember how much time that needs to be?  I want to say 2 ns,
> but it might be more like 5 ns, I just can't recall.  Of course it
> depends on your clock rates, but I believe Peter picked some more
> aggressive speeds like 100 MHz for his example.

I would expect most systems to have at least a 10% margin.
That is, the clock period is at least 10% longer than the
critical path delay. Probably closer to 20%, but maybe 10%.
So, with a 10ns clock there might be only 1ns slack.
Assuming some delay, say 1ns minimum from FF to FF, that
has nine times the slack, and that is in an exponent.

-- glen

Article: 153989
Subject: Re: accumulator (again)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 9 Jul 2012 05:42:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
jmariano <jmariano65@gmail.com> wrote:

(snip)
> Thank you very much for your input and sorry for the late reply.
> It is really great to be able to get the opinion of such experts,
> specially since, at my current location and in a radius of some 200
> km, I must be the only person working with FPGA and VHDL! I'm also
> glad that the discussion as evolved to levels of complexity far beyond
> my knowledge.

> I was hoping that by now I would be able to say that the thing was
> working as expected but, unfortunately, no.

(snip)

> Here's the full story: I'm implementing a gated integrator, as a part
> of a boxcar averager.  This is the standard noise reduction technique
> used in nuclear magnetic resonance (nmr). This is research, not a
> commercial product! The module gets is data from 4 8 bits ADC's at 5
> MHz (adc0, adc90, adc180, adc270) and accumulates wile enb=1. enb is
> generated in a different module. The module does this:

(big snip)

I believe that most FPGA families have FFs with clock enable.

Be sure that you are writing your logic in such a way that
the tools figure that out. In most cases, I believe that means
not writing it as a gated clock. Write it as FF's with enable.

(I know how to write it in verilog but not VHDL.)

-- glen

Article: 153990
Subject: Re: accumulator (again)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 9 Jul 2012 06:12:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:

(snip)
> With FPGAs, routhing is important.  A pair of FFs close together
> is probably good enough.  If you put them on opposite sides of a big
> chip, the routing delays may match the long path of the logic delays
> and eat up all of your slack time.

That is a good question. I usually assume that they won't have
a long route, but that might not be a good assumption.

Some time ago, I was working on a small design in a very large FPGA.
Expanding to fill the available space, things were very far apart.
(And, as I had so much space, I put three FFs in to synchronize,
but with long enough routes even that could fail.)

> Have any FPGA vendors published recent metastability info?
> (Many thanks to Peter Alfke for all his good work in this area.)

> I'm not a silicon wizard.  Is it reasonable to simulate this stuff?
> I'd like to know worst case rather than typicals.  It should be possible
> to do something like verify simulations with lab typicals and then
> use simulations to find the numbers for the nasty corners.

As I noted previously, though, often the problem isnt' metastabilty
but multiple FFs on the same asynchronous clock. Different problem.

-- glen

Article: 153991
Subject: Re: accumulator (again)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 9 Jul 2012 06:15:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

(snip)
> I'm not sure what you would want to simulate.  Metastability is
> probabilistic.  There is For a given length of settling time there is
> some probability of it happening.  Increasing the settling time
> reduces the probability but it will never be zero meaning there is no
> max length of time it takes for the output of a metastable ff to
> settle.

A favorite statistical physics problem is calculating the
probability that all the air molecules will move to one half 
of a room. There are many other problems with a very small,
but non-zero, probability. 

-- glen

Article: 153992
Subject: Re: accumulator (again)
From: jmariano <jmariano65@gmail.com>
Date: Mon, 9 Jul 2012 08:36:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dear All,

I would like to thank you all for your contributions. I finally solved the =
problem, that was not in the code as I immediately decided since i'm not ve=
ry experienced in VHDL, but rather in my miss interpretation of the AD9058'=
s datashet. I feel very stupid!=20

It was tanks to all your comments that I decided to finally rethink the pro=
ject as a all and spotted the problem.

"God saves the internet and the good people that lives there"

jmariano

Article: 153993
Subject: Re: accumulator (again)
From: Tim Wescott <tim@seemywebsite.com>
Date: Mon, 09 Jul 2012 13:35:11 -0500
Links: << >>  << T >>  << A >>
On Sun, 08 Jul 2012 15:38:45 -0700, rickman wrote:

> On Jul 6, 10:00 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
> Murray) wrote:
>> In article <nZ-dnch1rrNvHG_SnZ2dnUVZ_qSdn...@web-ster.com>,
>>  Tim Wescott <t...@seemywebsite.please> writes:
>>
>> >Paranoid logic designers will have a string of two or three registers
>> >to avoid metastability, but I've been told that's not necessary.  (I'm
>> >not much of a logic designer).
>>
>> Ahh, but are they paranoid enough?
>>
>> The key is settling time.
>>
>> In the old days of TTL chips, a pair of FFs (with no logic in between)
>> got you settling time of as much logic as the worst case delay for the
>> rest of the system.  In practice, that was enough.
>>
>> With FPGAs, routhing is important.  A pair of FFs close together is
>> probably good enough.  If you put them on opposite sides of a big chip,
>> the routing delays may match the long path of the logic delays and eat
>> up all of your slack time.
>>
>> Have any FPGA vendors published recent metastability info? (Many thanks
>> to Peter Alfke for all his good work in this area.)
>>
>> I'm not a silicon wizard.  Is it reasonable to simulate this stuff? I'd
>> like to know worst case rather than typicals.  It should be possible to
>> do something like verify simulations with lab typicals and then use
>> simulations to find the numbers for the nasty corners.
> 
> I'm not sure what you would want to simulate.  Metastability is
> probabilistic.  There is For a given length of settling time there is
> some probability of it happening.  Increasing the settling time reduces
> the probability but it will never be zero meaning there is no max length
> of time it takes for the output of a metastable ff to settle.

The drivers of metastability are probabilistic, yes.  But given enough 
information you could certainly simulate the positive feedback loop that 
is a flip-flop.  

I suspect that unless the ball that is the flip-flop state is poised 
right on the top of the mountain between the Valley of Zero and the 
Valley of One, that the problem is mostly deterministic.  It's only when 
the after-strobe balance is perfect and the gain is so low that the FF 
voltage is affected more by noise than by actual circuit forces that the 
problem would remain probabilistic _after_ the strobe happened.

"Enough information", in this case, would involve a whole lot of deep 
knowledge of the inner workings of the FPGA, and the simulation would be 
an analog circuits problem.  So I suspect that you couldn't do it for any 
specific part unless you worked at the company in question.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Article: 153994
Subject: RE: now what is this? iMPACT:2356 - Platform Cable USB firmware must be updated.
From: mehtavishal <mehta.vishal.360@gmail.com>
Date: Mon, 09 Jul 2012 14:09:19 -0500
Links: << >>  << T >>  << A >>
its been about 40 min and it is not even 1 % how did you solve your problem???

--http://compgroups.net/comp.arch.fpga/now-what-is-this-impact-2356-platform-cable-us/266024



Article: 153995
Subject: Re: The definition of comnatorial prcess?
From: rickman <gnuarm@gmail.com>
Date: Mon, 9 Jul 2012 17:04:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 9, 1:15=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip)
>
> >>http://en.wikipedia.org/wiki/Flip-flop_%28electronics%29#Master.E2.80..=
.
>
> (snip)
>
> > I'm =A0not sure what point you are trying to make. =A0The issue at hand=
 is
> > whether the tools should be able to infer an edge triggered ff from an
> > HDL combinatorial description of the gates that make up such a
> > device. =A0To make a gate design work correctly requires careful
> > analysis of delays to preclude the two enables from overlapping.
> > However if I describe two latches with a proper logical description
> > why can't the tool infer a ff in an FPGA? =A0Logically it is correct an=
d
> > it will give the correct behavior in simiulation. =A0Isn't that what
> > really matters, not whether the tool can design an edge sensitive ff
> > from LUTs but if the description is adequate to infer a ff?
>
> OK, I suppose I agree with that one. Though I am not so sure that
> any of the tools would actually figure it out. Normally, you
> use the negedge or posedge (in verilog, or equivalent in VHDL)
> that specifically asks for an edge triggered FF.
>
> If you do actually manage with gates and delays to make something
> that is logically correct, I would be surprised if it worked at all.
>
> As far as I know, it is usual for the tools to ignore any delay
> statements. Without delays, any delay based latch or FF will fail.
>
> -- glen

I agree 100% that would be hard to create a edge sensitive ff from
logic in an FPGA or elsewhere unless you have a way to assure non-
overlapping clocks.  I don't think delay statements (even if they were
not ignored by synthesis), would be enough to fully specify a
correctly working ff.  I think a logic description without delay
statements would produce a ff that works in simulation.  The problem
is that an implementation would have unknown delays but more
specifically the skew of the clock signals would need to be
controlled.  In fact, skew would likely need to be added to make the
two enables (master and slave) each less than 50% duty cycle.  It
would be hard to do that with delay statements.  But with no delay a
logic simulation would work because of the delta delays I think.

I have no idea if a properly constructed logic description would infer
an edge triggered ff in an FPGA or not.  I guess that might just be a
bit too much to expect from the tools.

Rick

Article: 153996
Subject: Re: accumulator (again)
From: rickman <gnuarm@gmail.com>
Date: Mon, 9 Jul 2012 17:14:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 9, 1:38=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip)
>
> >> > Paranoid logic designers will have a string of two or three register=
s to
> >> > avoid metastability, but I've been told that's not necessary. =A0(I'=
m not
> >> > much of a logic designer).
>
> (snip)
>
> > Hi Ed. =A0They way it was explained to me, I believe from Peter Alfke,
> > is that what really resolves metastability is the slack time in a
> > register to register path. =A0Over the years FPGA process has resulted
> > in FFs which only need a couple of ns to resolve metastability to 1 in
> > a million operation years or something like that (I don't remember the
> > metric, but it was good enough for anything I do). =A0It doesn't matter
> > that you have logic in that path, you just need those few ns in every
> > part of the path. =A0In theory, even if you use multiple registers with
> > no logic, what really matters is the slack time in the path and that
> > is not guaranteed even with no logic. =A0So the design protocol should
> > be to assure the slack time from the input register to all subsequent
> > registers have sufficient slack time.
>
> I suppose that is true, but really it shouldn't be a problem.
> It is usual for many systems to clock as fast as you can,
> consistent with the critical path delay. As metastability
> is exponential, even a slightly shorter delay is usually enough
> to make enough difference in the exponent.
>
> That assumes that there is a FF to FF path that is faster than
> the FF logic FF path. I believe that is usual for FPGAs, but
> if you manage to get a critical path with only one LUT, then
> I am not so sure. But that is pretty hard in most real systems.
>
> > Do you remember how much time that needs to be? =A0I want to say 2 ns,
> > but it might be more like 5 ns, I just can't recall. =A0Of course it
> > depends on your clock rates, but I believe Peter picked some more
> > aggressive speeds like 100 MHz for his example.
>
> I would expect most systems to have at least a 10% margin.
> That is, the clock period is at least 10% longer than the
> critical path delay. Probably closer to 20%, but maybe 10%.
> So, with a 10ns clock there might be only 1ns slack.
> Assuming some delay, say 1ns minimum from FF to FF, that
> has nine times the slack, and that is in an exponent.
>
> -- glen

You keep talking about the critical path delay as if the metastable
input is driving the critical path.  There is only one critical path
in a design normally.  All other paths are faster.  Are you assuming
that all paths have the same amount of delay?

Regardless, all I am saying is that you don't need to use a path that
has no logic to obtain *enough* slack to give enough settling time to
the metastable input.  But in all cases you need to verify this.  As
mentioned in another post, Peter Alfke's numbers show that you only
need about 2 ns to get 100 million years MTBF.  Of course whether this
is good enough depends on just how reliable your systems have to be
and how many there are.  It is 100 million years for one unit, but for
10 million units it will only be 10 years MTBF for the group.

Rick

Article: 153997
Subject: Re: accumulator (again)
From: rickman <gnuarm@gmail.com>
Date: Mon, 9 Jul 2012 17:16:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 9, 11:36=A0am, jmariano <jmarian...@gmail.com> wrote:
> Dear All,
>
> I would like to thank you all for your contributions. I finally solved th=
e problem, that was not in the code as I immediately decided since i'm not =
very experienced in VHDL, but rather in my miss interpretation of the AD905=
8's datashet. I feel very stupid!
>
> It was tanks to all your comments that I decided to finally rethink the p=
roject as a all and spotted the problem.
>
> "God saves the internet and the good people that lives there"
>
> jmariano

Don't think of it as a stupid mistake, think of it as a "good
catch"!

Rick

Article: 153998
Subject: Re: accumulator (again)
From: rickman <gnuarm@gmail.com>
Date: Mon, 9 Jul 2012 17:20:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 9, 2:35=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Sun, 08 Jul 2012 15:38:45 -0700, rickman wrote:
> > On Jul 6, 10:00 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
> > Murray) wrote:
> >> In article <nZ-dnch1rrNvHG_SnZ2dnUVZ_qSdn...@web-ster.com>,
> >> =A0Tim Wescott <t...@seemywebsite.please> writes:
>
> >> >Paranoid logic designers will have a string of two or three registers
> >> >to avoid metastability, but I've been told that's not necessary. =A0(=
I'm
> >> >not much of a logic designer).
>
> >> Ahh, but are they paranoid enough?
>
> >> The key is settling time.
>
> >> In the old days of TTL chips, a pair of FFs (with no logic in between)
> >> got you settling time of as much logic as the worst case delay for the
> >> rest of the system. =A0In practice, that was enough.
>
> >> With FPGAs, routhing is important. =A0A pair of FFs close together is
> >> probably good enough. =A0If you put them on opposite sides of a big ch=
ip,
> >> the routing delays may match the long path of the logic delays and eat
> >> up all of your slack time.
>
> >> Have any FPGA vendors published recent metastability info? (Many thank=
s
> >> to Peter Alfke for all his good work in this area.)
>
> >> I'm not a silicon wizard. =A0Is it reasonable to simulate this stuff? =
I'd
> >> like to know worst case rather than typicals. =A0It should be possible=
 to
> >> do something like verify simulations with lab typicals and then use
> >> simulations to find the numbers for the nasty corners.
>
> > I'm not sure what you would want to simulate. =A0Metastability is
> > probabilistic. =A0There is For a given length of settling time there is
> > some probability of it happening. =A0Increasing the settling time reduc=
es
> > the probability but it will never be zero meaning there is no max lengt=
h
> > of time it takes for the output of a metastable ff to settle.
>
> The drivers of metastability are probabilistic, yes. =A0But given enough
> information you could certainly simulate the positive feedback loop that
> is a flip-flop.
>
> I suspect that unless the ball that is the flip-flop state is poised
> right on the top of the mountain between the Valley of Zero and the
> Valley of One, that the problem is mostly deterministic. =A0It's only whe=
n
> the after-strobe balance is perfect and the gain is so low that the FF
> voltage is affected more by noise than by actual circuit forces that the
> problem would remain probabilistic _after_ the strobe happened.
>
> "Enough information", in this case, would involve a whole lot of deep
> knowledge of the inner workings of the FPGA, and the simulation would be
> an analog circuits problem. =A0So I suspect that you couldn't do it for a=
ny
> specific part unless you worked at the company in question.
>
> --
> My liberal friends think I'm a conservative kook.
> My conservative friends think I'm a liberal kook.
> Why am I not happy that they have found common ground?
>
> Tim Wescott, Communications, Control, Circuits & Softwarehttp://www.wesco=
ttdesign.com

That's what probability is all about, dealing with the lack of
knowledge.  You don't know the exact voltage of the input when the
clock edge changed and you don't know how fast either signal was
changing... etc.  But you do know how often you expect all of these
events to line up to produce metastability and you know the
distribution of delay is a logarithmic taper.

I won't try to argue about how many angels can dance on the head of a
pin, but I have no information to show me that the formula that Peter
used is not accurate, even for extreme cases.

Rick

Article: 153999
Subject: Re: The definition of comnatorial prcess?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 10 Jul 2012 01:15:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)
>> OK, I suppose I agree with that one. Though I am not so sure that
>> any of the tools would actually figure it out. Normally, you
>> use the negedge or posedge (in verilog, or equivalent in VHDL)
>> that specifically asks for an edge triggered FF.

>> If you do actually manage with gates and delays to make something
>> that is logically correct, I would be surprised if it worked at all.

>> As far as I know, it is usual for the tools to ignore any delay
>> statements. Without delays, any delay based latch or FF will fail.

> I agree 100% that would be hard to create a edge sensitive ff from
> logic in an FPGA or elsewhere unless you have a way to assure non-
> overlapping clocks.  I don't think delay statements (even if they were
> not ignored by synthesis), would be enough to fully specify a
> correctly working ff.  I think a logic description without delay
> statements would produce a ff that works in simulation.  The problem
> is that an implementation would have unknown delays but more
> specifically the skew of the clock signals would need to be
> controlled.  In fact, skew would likely need to be added to make the
> two enables (master and slave) each less than 50% duty cycle.  It
> would be hard to do that with delay statements.  But with no delay a
> logic simulation would work because of the delta delays I think.

Yes. My understanding from many years ago, and likely from TTL,
is that it is (was) done using two thresholds. As the clock falls
(or rises) two things happen at two different points on the clock
transition. Since the TTL databook has schematics for many
circuits, it might even be possible to see it.

> I have no idea if a properly constructed logic description would infer
> an edge triggered ff in an FPGA or not.  I guess that might just be a
> bit too much to expect from the tools.

They are pretty good at figuring out strange logic, but yes,
I think that would be too much. 

-- glen



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

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