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

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 155550

Article: 155550
Subject: Re: Floorplanning Literature
From: Leo <capossio.leonardo@gmail.com>
Date: Wed, 17 Jul 2013 11:35:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, July 17, 2013 1:49:19 PM UTC-3, rickman wrote:
> On 7/17/2013 9:19 AM, Leo wrote:
>=20
> > On Sunday, July 14, 2013 3:17:42 PM UTC-3, rickman wrote:
>=20
> >> On 7/14/2013 2:04 PM, Leo wrote:
>=20
> >>
>=20
> >>> Any good floorplanning literature (papers, books, etc.) ? I'm needing=
 it for floorplanning FPGA architectures (Spartan 6), but any general text =
about the subject would be cool. I already read fliptronics's introduction.
>=20
> >>
>=20
> >> I don't know of any docs relevant to floorplanning other than what you
>=20
> >> might find at the Xilinx site.  Floorplanning is not easy to use
>=20
> >> effectively in my experience.  The one project where we really needed
>=20
> >> floorplanning I found it to be nearly impossible to use.  That was in =
an
>=20
> >> older Altera part using MaxPlusII.  That tool was not so easy to
>=20
> >> manipulate as the Xilinx tools I expect.
>=20
> >>
>=20
> >> Why do you need floorplanning?  What do you expect to achieve using it=
?
>=20
> >>
>=20
> >> --
>=20
> >>
>=20
> >> Rick
>=20
> >
>=20
> > I have a really tight design on resources (primarily carry logic and DS=
P, LUT and Regs are around 63%). I was expecting to up a 50Mhz design into =
a 100Mhz by overriding some of the placement done on map. The design is hea=
vily pipelined, but the external memory interfaces are among the critical p=
aths. The design needs to access one memory for reading and another one for=
 writing at the same time (on opposed banks), and then when an internal 'cy=
cle' finishes, switch the role of each memory. The main problem is that whe=
n I floorplan it to achieve better timing (placing memory accessess in the =
mid-point between opposed banks), the routing becomes heavily congested and=
 does not complete. I'm assuming that happens because there are signals run=
ning vertically when memory accesses are being done horizontally. In the en=
d I think that I will have to reduce the resource utilization to achieve ti=
ming, I mean remove a few parallel and independent pipes (with the performa=
nce hit that it means).
>=20
>=20
>=20
> I'm not totally clear on all the details which can be important as there=
=20
>=20
> are more than one way to skin a cat.  I think you are saying you have=20
>=20
> two memory interfaces which you are running in parallel.  These memory=20
>=20
> interfaces are on the left and right sides of the chip so you have the=20
>=20
> control logic in the middle.  Is there a reason why you can't put the=20
>=20
> memory interfaces on, say, the top and right to make them closer=20
>=20
> together and to potentially move the routing out of the way of the other=
=20
>=20
> logic?  Or has your PCB been laid out?
>=20
>=20
>=20
> The problem you are seeing with floorplanning is exactly the sort of=20
>=20
> thing that can happen.  While the tool may not understand your design,=20
>=20
> it understands the limitations of the chip.  With the designer this is=20
>=20
> reversed.  You are hitting a wall with the chip resources.
>=20
>=20
>=20
> So maybe don't floorplan for this problem.  Can you add more pipeline=20
>=20
> stages?  It is not unreasonable to add pipeline registers to break up=20
>=20
> the routing delays.  No logic, just an extra FF in the paths that are=20
>=20
> giving the most trouble.
>=20
>=20
>=20
> Or maybe not floorplan the entire block of logic in one spot.  Would it=
=20
>=20
> make sense to spread it out horizontally a bit which might leave some=20
>=20
> space for the vertical signals to weave through?
>=20
>=20
>=20
> But then 100 MHz is not all that fast.  Have you looked at the details=20
>=20
> of the slow paths?  Do you understand where the tool is having trouble=20
>=20
> meeting the timing goals?
>=20
>=20
>=20
> --=20
>=20
>=20
>=20
> Rick

Yes, I have memory interfaces in the left and right banks, but also one in =
the top bank (PCB is done). The third memory interface is NOT needed, so I =
can exchange banks at will. With the top and right memory banks and no floo=
rplanning at all, ISE succeeds in implementing it at 50Mhz, but not more. T=
he critical path is between the memory banks, since the access is in the mi=
d-point of both (the tool did this automatically), the complete delay to ei=
ther bank is close to 20ns. A level of pipeline will surely help, and it is=
 in the works. I was trying to use left and right memories to ease the timi=
ng without pipeline, but this evidently complicated the routing. So, a comp=
romise must be made. I think that's all for this project. Thanks for your o=
pinion.

Article: 155551
Subject: Metastability mitigation and I/O registers
From: "RCIngham" <2161@embeddedrelated>
Date: Thu, 18 Jul 2013 04:13:39 -0500
Links: << >>  << T >>  << A >>
This is a design targetted at a Microsemi ProASIC3 device, but I expect
that the answer should be technology-independent.

I have to input a bunch of discrete signals to send over a telemetry link.
Therefore I will be doing the usual 2-register metastability mitigation.
Should I pack the first register into the I/O cell, as per usual
bus-related practice, or would it be better not to do that (timing is
completely asynchronous) in the hope that the pair of registers will be
placed closely together and hence improve the overall metastability MTBF?

I haven't found anything on this in the Actel/Microsemi web-site or on
C.A.F., but maybe my google-fu is lacking today.

Thanks in anticipation,
Robert
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155552
Subject: Re: Xilinx "Ultrascale" announcement leaves out low-cost devices
From: Anssi Saari <as@sci.fi>
Date: Thu, 18 Jul 2013 14:44:37 +0300
Links: << >>  << T >>  << A >>
Sean Durkin <news_dec12@tuxroot.de> writes:

> When Lattice dropped the ECP4 before it even started, they told us
> they now plan to concentrate on low to medium density FPGAs, low power
> and smaller packages, since that is what X and A don't cover with
> their lineup and they don't stand a chance with the bigger
> parts. Seems to me that Xilinx is handing over that market share to
> them now.

Well, a couple of years ago I listened to a keynote speech by Mentor
Graphics's CEO. It was about profits in the chip business, FPGAs make
the most money because they are expensive and leverage new process nodes
early. I have to assume these are the big FPGAs, not the small
ones... So Xilinx is going where the money is.

BTW, apparently Altera is coming up with small FPGAs along the lines of
Lattice's MachXO2 line. It's funny how the XO2-1200 seems like a MaxII
EPM1270 with 10 more LEs, a PLL and some RAM...

Article: 155553
Subject: Metastability mitigation and I/O registers
From: Chris <catalsma@gmail.com>
Date: Thu, 18 Jul 2013 05:14:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
It shouldn't matter where you put the register, once it is in your clock domain the p&r tools should either ensure timing is met from reg to reg or flag it with a timing error if things are constrained correctly.  I would pack the reg at the io buffer.

Article: 155554
Subject: Re: Metastability mitigation and I/O registers
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 18 Jul 2013 10:15:58 -0400
Links: << >>  << T >>  << A >>
RCIngham wrote:
> This is a design targetted at a Microsemi ProASIC3 device, but I expect
> that the answer should be technology-independent.
> 
> I have to input a bunch of discrete signals to send over a telemetry link.
> Therefore I will be doing the usual 2-register metastability mitigation.
> Should I pack the first register into the I/O cell, as per usual
> bus-related practice, or would it be better not to do that (timing is
> completely asynchronous) in the hope that the pair of registers will be
> placed closely together and hence improve the overall metastability MTBF?
> 
> I haven't found anything on this in the Actel/Microsemi web-site or on
> C.A.F., but maybe my google-fu is lacking today.
> 
> Thanks in anticipation,
> Robert
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

The only reason why it would make a difference is if the IOB flops
either had much poorer metastability performance (larger metastable
window and/or longer metastable event time), or if you cannot get
a short enough path to the next fabric flop from the IOB flop
to leave enough slack for a metastable event.  To some extent
this depends on your clock frequency, since it's generally easier
to get more slack for metastability to resolve when you have
a longer clock period.

I think only MicroSemi could answer the question about the
metastability performance difference between an IOB flop
and an internal flop.  Presumably you can get all the path
timing details you need from the tools.

-- 
Gabor

Article: 155555
Subject: Xilinx ISE GUI vs tcl script problem
From: "nmatringe@gmail.com" <nmatringe@gmail.com>
Date: Thu, 18 Jul 2013 07:21:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello
I've used tcl scripts for quite a long time now and been very happy until yesterday when suddenly the script interpreter started picking the wrong top level unit.
So I have a perfectly compiling design in the GUI, I generate a tcl script and when I run it (xtclsh myscript.tcl) it stops with an error message, and when I look at the log I can see it has used "blkmem.xco" as top level unit.
Does anyone know what's going on in there ?

Thanks
Nicolas

Article: 155556
Subject: Re: Metastability mitigation and I/O registers
From: Chris <catalsma@gmail.com>
Date: Thu, 18 Jul 2013 08:28:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
The data sheet for the proasic shows 260 to 350 ps of setup time for the io buffer register depending on device speed grade while the versatile (internal ff) setup is 430 to 570 ps depending on the speed grade.  

Again the tools will warn you if you are not meeting the setup time into the second flop.

I would use the io buff reg.

Article: 155557
Subject: Re: Metastability mitigation and I/O registers
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 18 Jul 2013 12:00:34 -0400
Links: << >>  << T >>  << A >>
Chris wrote:
> The data sheet for the proasic shows 260 to 350 ps of setup time for the io buffer register depending on device speed grade while the versatile (internal ff) setup is 430 to 570 ps depending on the speed grade.  
> 
> Again the tools will warn you if you are not meeting the setup time into the second flop.
> 
> I would use the io buff reg.

I think you're missing two points about metastability here.

1) The input setup and hold times only define the window where the
input data transition is not guaranteed to show up on the output
at the associated clock edge.  The actual window where an input
data transition results in output metastabiliy is usually much
smaller than this, perhaps on the order of 1 to 10 ps.  The
fact that the two flop types have similar setup and hold timing
does not necessarily mean that they are designed the same or
that they have similar metastability characteristics.

2) The tools only guarantee that you meet setup at the second
flop when there is no metastability at the first one.  If you
want to allow extra settling time to cover most metastable
events, then you need to ensure there is additional slack
in this path.  I know you can do this with Xilinx tools, but
I'm not familiar with the Libero tools.  In any case, if
metastability is really a concern, it would be good to know
how much slack you need to cover say 99.9% of metastable
events on the input flop so you can apply adequate constraint
to the path between flops.

-- 
Gabor

Article: 155558
Subject: Re: Metastability mitigation and I/O registers
From: Chris <catalsma@gmail.com>
Date: Thu, 18 Jul 2013 09:20:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
Gabor-  yep for the first point, I was assuming that the io buffer had bett=
er performance based on the setup only but you are more correct in that it =
may not have better performance from a meta stability standpoint.... Althou=
gh I would still assume it if there is no other data from actel.  I didn't =
see anything else in my one minute search.  On the second point, I can see =
your point, if you do hit a meta stable event on the first flop you need so=
mething to ensure that either the reg delay or path timing would keep you f=
rom propagating thru to the next flop and I am not sure the tools would tel=
l you this.  This is the case whether or not you use an io buffer or intern=
al ff.  I still hold by my suggestion that with the info I saw I would pack=
 the buffer with a reg.

Article: 155559
Subject: Re: Xilinx "Ultrascale" announcement leaves out low-cost devices
From: rickman <gnuarm@gmail.com>
Date: Thu, 18 Jul 2013 13:52:16 -0400
Links: << >>  << T >>  << A >>
On 7/18/2013 7:44 AM, Anssi Saari wrote:
> Sean Durkin<news_dec12@tuxroot.de>  writes:
>
>> When Lattice dropped the ECP4 before it even started, they told us
>> they now plan to concentrate on low to medium density FPGAs, low power
>> and smaller packages, since that is what X and A don't cover with
>> their lineup and they don't stand a chance with the bigger
>> parts. Seems to me that Xilinx is handing over that market share to
>> them now.
>
> Well, a couple of years ago I listened to a keynote speech by Mentor
> Graphics's CEO. It was about profits in the chip business, FPGAs make
> the most money because they are expensive and leverage new process nodes
> early. I have to assume these are the big FPGAs, not the small
> ones... So Xilinx is going where the money is.

I have to wonder how long the high end of the market can remain a cash 
cow.  We see the processing ability of PCs exceeding the needs of PC 
users.  The result is a change in the market to smaller platforms with 
more convenience and much lower processing demands than what is offered 
in PCs.  I am expecting something similar in the FPGA market.  How many 
designs will there be for the ever larger FPGAs which don't actually run 
noticeably faster?

There will always be a need for cutting edge designs that have to get to 
the market quickly, but I expect there will be more profit in the mass 
quantity market as FPGAs start to take over from custom chip designs. 
The cost of silicon may be less when you design an ASIC, but if you can 
get to market 6 months or a year sooner for only $2 more per chip, I 
expect that is a *huge* advantage.  The FPGA makers have to be serious 
about addressing the market though.  You can't just toss any old FPGA 
out there and expect it to get design wins in quantity million sockets.

-- 

Rick

Article: 155560
Subject: Re: Metastability mitigation and I/O registers
From: jonesandy@comcast.net
Date: Thu, 18 Jul 2013 10:52:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Robert,

Use a DDR input register. The PA3E DDR Input register's falling edge sample=
 is re-registered in the IOB on the rising edge of the IOB clock, so it is =
already a two-stage synchronizer/meta-rejector, albeit at twice the clock f=
requency. The DDR input register has a dedicated connection(and delay) betw=
een the two registers, so the delay is immune to P&R.

If your clock rate is near the high end of the range for an IOB register, I=
 would recommend a standard IOB register for the synchronizer and a fabric =
register for the meta-rejector, with a timing constraint on the path to ens=
ure sufficient margin for metastable events.

Andy


Article: 155561
Subject: Re: Metastability mitigation and I/O registers
From: rickman <gnuarm@gmail.com>
Date: Thu, 18 Jul 2013 14:05:46 -0400
Links: << >>  << T >>  << A >>
On 7/18/2013 5:13 AM, RCIngham wrote:
> This is a design targetted at a Microsemi ProASIC3 device, but I expect
> that the answer should be technology-independent.
>
> I have to input a bunch of discrete signals to send over a telemetry link.
> Therefore I will be doing the usual 2-register metastability mitigation.
> Should I pack the first register into the I/O cell, as per usual
> bus-related practice, or would it be better not to do that (timing is
> completely asynchronous) in the hope that the pair of registers will be
> placed closely together and hence improve the overall metastability MTBF?
>
> I haven't found anything on this in the Actel/Microsemi web-site or on
> C.A.F., but maybe my google-fu is lacking today.

Are you doing any logic at all on these data signals?  If not, I can't 
imagine there wouldn't be enough delay to provide metastability 
protection.  If you aren't doing any logic on these signal chains, why 
would it matter if one of the bits goes meta stable?

Think of it like quantum mechanics.  The sample that was taken at the 
time of a transition doesn't really "know" if it is a one or a zero.  It 
only then matters when you "look" at it with logic.  If you are just 
sending the bit somewhere else I can't see how the fact that it is not 
resolved by the next clock edge can have an impact on anything.  It just 
makes the next stage metastable and you have a second shot at resolving 
it.

How fast is your clock and your input transition rate?  That will help 
determine how much slack you need to resolve the metastability to a 
vanishing small probability.  I believe you should be able to spec the 
slack time in the path you are talking about.  Then you don't care where 
the FFs are, just that the routing meets your timing requirement.

-- 

Rick

Article: 155562
Subject: Re: Metastability mitigation and I/O registers
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 18 Jul 2013 18:30:27 +0000 (UTC)
Links: << >>  << T >>  << A >>
GaborSzakacs <gabor@alacron.com> wrote:

(snip)
> I think you're missing two points about metastability here.
 
> 1) The input setup and hold times only define the window where the
> input data transition is not guaranteed to show up on the output
> at the associated clock edge.  The actual window where an input
> data transition results in output metastabiliy is usually much
> smaller than this, perhaps on the order of 1 to 10 ps.  The
> fact that the two flop types have similar setup and hold timing
> does not necessarily mean that they are designed the same or
> that they have similar metastability characteristics.

This should be true, but not usually a problem.
 
> 2) The tools only guarantee that you meet setup at the second
> flop when there is no metastability at the first one.  If you
> want to allow extra settling time to cover most metastable
> events, then you need to ensure there is additional slack
> in this path.  I know you can do this with Xilinx tools, but
> I'm not familiar with the Libero tools.  In any case, if
> metastability is really a concern, it would be good to know
> how much slack you need to cover say 99.9% of metastable
> events on the input flop so you can apply adequate constraint
> to the path between flops.

The reason for the double FF's is that if the first goes 
metastable, you have almost the whole clock period for it
to settle before the clock edge on the second one.

In a normal system, you might have 80% or 90% of the clock
period in logic delay between two FFs. If one went metastable,
in addition to the logic delay, it could miss setup for the next.
As settling is exponential, with minimal delay you have from
five to ten times as long, which usually gets you pretty far
out on the time scale. 

As far as I know, you can't design a system such that the
minimal logic path is still too long, but if you did a third
FF should be enough. Well, I suppose if the tools put a really
long routing delay in there it could do it. 

I have never done a design where the most logic between FFs was
less than two CLBs. If you manage that, I might believe it.

It is usual for FPGAs to have zero hold time. That is, the output
of one can't change too fast for the input of another on the
same clock. (Mostly that is because of the minimum amount of
logic and routing between them.) Metastability only happens
after the clock edge, not before. 

Just to be sure, since I am not sure the OP mentioned it, the
question is really about metastability, and not clocking of
a multiple bit register, such that some bits go on one clock
edge, and some on the next. That also occurs when crossing clock
domains, causes systems to fail, but is not related to metastability.

-- glen


Article: 155563
Subject: Re: Metastability mitigation and I/O registers
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 18 Jul 2013 14:59:41 -0400
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
> 
> Just to be sure, since I am not sure the OP mentioned it, the
> question is really about metastability, and not clocking of
> a multiple bit register, such that some bits go on one clock
> edge, and some on the next. That also occurs when crossing clock
> domains, causes systems to fail, but is not related to metastability.
> 
> -- glen
> 

That's a good point, and you can often get by with a single flip-flop
to register the input, followed by a timing constraint on paths from
this flop's output that gives some extra margin for metastability
to resolve.  This is especially easy if you have a slow system clock,
where it also helps to reduce latency.  I rarely think about
metastability in my designs because it happens so infrequently,
and I usually assume people concerned about it have some requirement
for very high system reliability (my designs mostly deal with video,
where a bad pixel here or there isn't noticeable).  Often, especially
beginners immediately suspect metastability when they have problems
with asynchronous inputs, while in almost all cases the failures
are due to registering the same asynchronous input with more than
one flop causing race conditions, and often causing FSM failure.

-- 
Gabor

Article: 155564
Subject: Re: Metastability mitigation and I/O registers
From: Gabor <gabor@szakacs.org>
Date: Fri, 19 Jul 2013 23:33:19 -0400
Links: << >>  << T >>  << A >>
On 7/18/2013 2:05 PM, rickman wrote:
>
> Are you doing any logic at all on these data signals?  If not, I can't
> imagine there wouldn't be enough delay to provide metastability
> protection.  If you aren't doing any logic on these signal chains, why
> would it matter if one of the bits goes meta stable?
>
> Think of it like quantum mechanics.  The sample that was taken at the
> time of a transition doesn't really "know" if it is a one or a zero.  It
> only then matters when you "look" at it with logic.  If you are just
> sending the bit somewhere else I can't see how the fact that it is not
> resolved by the next clock edge can have an impact on anything.  It just
> makes the next stage metastable and you have a second shot at resolving it.
>

The point is that after the sampling flop you want to treat this
signal as synchronous.  Now suppose the output of the sampling
flop goes metastable for longer than the slack time on its output
path.  This is where you can no longer treat this as a synchronous
signal.  If it goes to more than one downstream flop, then you
have the possibility that one will sample the transition on
this clock edge and the other won't sample the transition until
the next clock.  This is how FSM's go "zero-hot."  Adding a second
flop with no logic between reduces the chance of this happening
downstream of the second flop by many orders of magnitude.  This is
because now the metastability event from the first flop would need
to resolve just at the metastability window of the second flop
in order to cause any further issue downstream.  As I said before
this window can be extremely small, much smaller than the setup/
hold window.

> How fast is your clock and your input transition rate?  That will help
> determine how much slack you need to resolve the metastability to a
> vanishing small probability.  I believe you should be able to spec the
> slack time in the path you are talking about.  Then you don't care where
> the FFs are, just that the routing meets your timing requirement.
>

"Vanishingly small" may mean one thing to one person and another thing
to others.  If for example you can say that 1 ns of slack gets you
to an event rate of 1 per month, is that "vanishingly small" or do
you want to add that second flop and get to something like one
event per millennium?  I rarely use a two-stage synchronizer, but
then again nobody's life depends on the operation of my logic
designs.

-- 
Gabor

Article: 155565
Subject: Re: Metastability mitigation and I/O registers
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 20 Jul 2013 04:23:49 +0000 (UTC)
Links: << >>  << T >>  << A >>
Gabor <gabor@szakacs.org> wrote:

(snip on metastability)
 
> The point is that after the sampling flop you want to treat this
> signal as synchronous.  Now suppose the output of the sampling
> flop goes metastable for longer than the slack time on its output
> path.  This is where you can no longer treat this as a synchronous
> signal.  If it goes to more than one downstream flop, then you
> have the possibility that one will sample the transition on
> this clock edge and the other won't sample the transition until
> the next clock.  

Yes, but note that problem is still there even without
metastability. If the transition is close to the clock, and
the delay to the different FFs is (even slightly) different,
they can clock the input on different clock edges.

FIFOs use gray code to resolve that problem.

> This is how FSM's go "zero-hot."  Adding a second
> flop with no logic between reduces the chance of this happening
> downstream of the second flop by many orders of magnitude.  This is
> because now the metastability event from the first flop would need
> to resolve just at the metastability window of the second flop
> in order to cause any further issue downstream.  As I said before
> this window can be extremely small, much smaller than the setup/
> hold window.

If the critical path delay is 80% of the clock period, the 
system can fail if the metastabilty time is 20% of the clock
period. 
 
>> How fast is your clock and your input transition rate?  That will help
>> determine how much slack you need to resolve the metastability to a
>> vanishing small probability.  I believe you should be able to spec the
>> slack time in the path you are talking about.  Then you don't care where
>> the FFs are, just that the routing meets your timing requirement.
 
> "Vanishingly small" may mean one thing to one person and another thing
> to others.  If for example you can say that 1 ns of slack gets you
> to an event rate of 1 per month, is that "vanishingly small" or do
> you want to add that second flop and get to something like one
> event per millennium?  I rarely use a two-stage synchronizer, but
> then again nobody's life depends on the operation of my logic
> designs.

If you have a 100MHz clock, and one event per month, that is one
in 2.5e14 clock cycles. As metastability resolves exponentially,
with a full cycle in between it will fail about every 2.5e14
to the fifth power cycles, or about one in 3e55 months.
That should be long enough for just about everyone.

-- glen
 

Article: 155566
Subject: Re: Metastability mitigation and I/O registers
From: rickman <gnuarm@gmail.com>
Date: Sat, 20 Jul 2013 02:16:12 -0400
Links: << >>  << T >>  << A >>
On 7/19/2013 11:33 PM, Gabor wrote:
> On 7/18/2013 2:05 PM, rickman wrote:
>>
>> Are you doing any logic at all on these data signals? If not, I can't
>> imagine there wouldn't be enough delay to provide metastability
>> protection. If you aren't doing any logic on these signal chains, why
>> would it matter if one of the bits goes meta stable?
>>
>> Think of it like quantum mechanics. The sample that was taken at the
>> time of a transition doesn't really "know" if it is a one or a zero. It
>> only then matters when you "look" at it with logic. If you are just
>> sending the bit somewhere else I can't see how the fact that it is not
>> resolved by the next clock edge can have an impact on anything. It just
>> makes the next stage metastable and you have a second shot at
>> resolving it.
>>
>
> The point is that after the sampling flop you want to treat this
> signal as synchronous. Now suppose the output of the sampling
> flop goes metastable for longer than the slack time on its output
> path. This is where you can no longer treat this as a synchronous
> signal. If it goes to more than one downstream flop, then you
> have the possibility that one will sample the transition on
> this clock edge and the other won't sample the transition until
> the next clock. This is how FSM's go "zero-hot." Adding a second
> flop with no logic between reduces the chance of this happening
> downstream of the second flop by many orders of magnitude. This is
> because now the metastability event from the first flop would need
> to resolve just at the metastability window of the second flop
> in order to cause any further issue downstream. As I said before
> this window can be extremely small, much smaller than the setup/
> hold window.

Yes, this is all classic metastability stuff.  If this is just data and 
is not used to control any FSMs or otherwise branches out to multiple 
FFs, metastability won't matter.  That was my point about it only 
mattering when the value of the signal is "looked" at.  If this is just 
data being clocked into another FF it just doesn't matter, the next FF 
just gives you more metastability resolution time before the signal 
reaches some point in the circuit where it does matter.


>> How fast is your clock and your input transition rate? That will help
>> determine how much slack you need to resolve the metastability to a
>> vanishing small probability. I believe you should be able to spec the
>> slack time in the path you are talking about. Then you don't care where
>> the FFs are, just that the routing meets your timing requirement.
>>
>
> "Vanishingly small" may mean one thing to one person and another thing
> to others. If for example you can say that 1 ns of slack gets you
> to an event rate of 1 per month, is that "vanishingly small" or do
> you want to add that second flop and get to something like one
> event per millennium? I rarely use a two-stage synchronizer, but
> then again nobody's life depends on the operation of my logic
> designs.

I think the term vanishingly small is pretty universal.  That is why I 
didn't say "1 failure per month" or "1 failure per millennium".  As to 
what numbers are required, that is up to the designer and the 
application.  How much timing slack is required depends on the failure 
rate needed, the clock and data rates and the details of the logic 
family used.

At one point some folks at Xilinx made a pretty good case for 
standardizing on 2 ns since it gives you a 1 in a billion year failure 
rate (or something like that) with 100 MHz clocks and data.  I don't 
recall the exact numbers, but they made it clear that anything longer 
than 2 ns was gravy for most designs in FPGAs.  But more recently I have 
read here that the newer FPGA families are trending back in the other 
direction so that longer slack times may be needed for high end designs. 
  But it doesn't seem like there is a "metastability voice" at the FPGA 
companies anymore.  Do they even publish the relevant numbers for recent 
families?

-- 

Rick

Article: 155567
Subject: Verilog: "don't care" in
From: "mnentwig" <24789@embeddedrelated>
Date: Sat, 20 Jul 2013 12:17:26 -0500
Links: << >>  << T >>  << A >>
Hi,

is there any simple way to point out impossible cases in comparison
operators?
For example, I have the expression

result <= (value <= 17? ) ... : ...
I know that "value" is modulo-four, and 18, 19 are the only possible values
that give a true result. 
In a "case" statement, "//synthesis full_case" does what I want, but it
seems rather clumsy.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155568
Subject: Re: Metastability mitigation and I/O registers
From: "RCIngham" <2161@embeddedrelated>
Date: Mon, 22 Jul 2013 10:14:58 -0500
Links: << >>  << T >>  << A >>
Gentlemen all,

Thank you for an interesting discussion. Just to clarify a few points:
1. It's a ProASIC3 design, so not bleeding edge technology, but there is
enough data on the Microsemi web-site to calculate MTBFs if the inter-FF
delay is known.
2. I am assuming that each of these inputs is independent.
3. The system clock is < 10 MHz, but a "rule-of-thumb" that works for
higher frequencies would be nice.
4. The design is flight safety-critical, so I would like the MTBF relating
to metastability to be "a lot of years", but it isn't (so far) a quantified
system requirement.

While I am sorting out the "build from a script, not the GUI" process, I
think that I will add the appropriate sort of timing constraint to my trial
sand-box design, and see where it breaks for both cases. I will then report
back.

Many thanks,
Robert
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155569
Subject: Re: Verilog: "don't care" in
From: gtwrek@sonic.net (Mark Curry)
Date: Mon, 22 Jul 2013 21:00:43 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <BMKdnRsPXp67W3fMnZ2dnUVZ_radnZ2d@giganews.com>,
mnentwig <24789@embeddedrelated> wrote:
>is there any simple way to point out impossible cases in comparison
>operators?
>For example, I have the expression
>
>result <= (value <= 17? ) ... : ...
>I know that "value" is modulo-four, and 18, 19 are the only possible values
>that give a true result. 
>In a "case" statement, "//synthesis full_case" does what I want, but it
>seems rather clumsy.	   

I'd just code the easy things.  Since you know it's modulo-4 then just mask
(or ignore) the lower two-bits.  If you mean that inputs > 19 never occur, then
mask (or ignore) bits over bit 4.  

Anything else usually isn't worth the effort.  If there's any way the synthesis
tool can figure out this extra information, it'll do very good job at 
optimizing it on it's own.

My 2 cents...

--Mark



Article: 155570
Subject: Re: Xilinx "Ultrascale" announcement leaves out low-cost devices
From: jg <j.m.granville@gmail.com>
Date: Mon, 22 Jul 2013 18:29:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, July 18, 2013 11:44:37 PM UTC+12, Anssi Saari wrote:
> BTW, apparently Altera is coming up with small FPGAs along the lines of
> Lattice's MachXO2 line. It's funny how the XO2-1200 seems like a MaxII
> EPM1270 with 10 more LEs, a PLL and some RAM...


Any indications of when ?

Article: 155571
Subject: Re: Xilinx "Ultrascale" announcement leaves out low-cost devices
From: jg <j.m.granville@gmail.com>
Date: Mon, 22 Jul 2013 18:39:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, July 17, 2013 7:20:03 AM UTC+12, Gabor wrote:
> It seems that Xilinx is once again abandoning the low-cost
> high-volume market in pursuit of those lucrative high-end
> sockets.  There latest announcement shows less roadmap
> as the devices go towards the low end of the price curve:
> 
> http://www.xilinx.com/products/technology/ultrascale/

 No real surprise, the FPGA market is tough : huge R&D costs, and below average revenue growths.
 The biggest problem, is design lifetimes.

 Anytime they go into a mass-volume, early adopter design, it is only a short time before the volumes will pay for tooling a cheaper alternative.

 So they understand the best design lifetimes are in those areas where the volumes & design stability help them, and that is areas like ASIC simulation, and communications infrastructure.

 Add onto that, the Corporate mindset, whereby some companies simply cannot make $1 parts, and it is easy to see Xilinx heading like intel.

Article: 155572
Subject: Re: Xilinx ISE GUI vs tcl script problem
From: goouse99@gmail.com
Date: Mon, 22 Jul 2013 22:52:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
Am Donnerstag, 18. Juli 2013 16:21:28 UTC+2 schrieb nmat...@gmail.com:
> Hello
> 
> I've used tcl scripts for quite a long time now and been very happy until yesterday when suddenly the script interpreter started picking the wrong top level unit.
> 
> So I have a perfectly compiling design in the GUI, I generate a tcl script and when I run it (xtclsh myscript.tcl) it stops with an error message, and when I look at the log I can see it has used "blkmem.xco" as top level unit.
> 
> Does anyone know what's going on in there ?
> 
> 
Hi Nicolas,
difficult to say.
So you are using the TCL script generated by ISE-PN?
Have you chosen the version withall properties in it?
Have you called it with the correct option (e.g. rebuild_project).
What was the top level unit at the time of script generation.

Maybe you just look in the script for the line that sets the top level unit.
If it is wrong, just edit it and put in the correct design unit.

Have a nice synthesis
  Eilert 



> 
> Thanks
> 
> Nicolas


Article: 155573
Subject: Re: Verilog:
From: "mnentwig" <24789@embeddedrelated>
Date: Tue, 23 Jul 2013 06:27:31 -0500
Links: << >>  << T >>  << A >>
Hi,

thanks for the reply. 
Agree, I don't want to get stuck in micro-optimization. I was just hoping
for a simple solution like 

// synthesis assume(value < 20)

(this is FAKE. I've made it up. Don't use it)

Theoretically, the synthesis tool could figure it out, but I doubt it's
that smart.

BTW, a mistake in my post: I meant modulo-20 (not 4). The _increment_ in my
example is 4, and the only cases that trigger the condition are 

16+4
17+4
18+4
19+4
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155574
Subject: Re: Verilog:
From: jonesandy@comcast.net
Date: Tue, 23 Jul 2013 06:35:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, July 23, 2013 6:27:31 AM UTC-5, mnentwig wrote:
> Theoretically, the synthesis tool could figure it out, 
> but I doubt it's that smart. 

Synplify performs reachability analysis on counters and state machines. With that information, it will optimize comparisons to the count or state. Whether it can determine that some values are not reachable, I cannot tell from the information given. 

Andy




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

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