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 107400

Article: 107400
Subject: Re: placing addiional caps across existing caps to reduce noise
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Mon, 28 Aug 2006 07:57:02 +0000 (UTC)
Links: << >>  << T >>  << A >>
Austin Lesea <austin@xilinx.com> wrote:


> To the subject at hand:  placing additional caps across existing caps 
> does not reduce the noise (unless the dominant cause is lack of adequate 
> capacitance).

> The reason why the noise is bad is that the L (as in Ldi/dt) is most 
...

On that subject:
The webpages for Spartan 5 talk about "Virtex-5 sparse chevron packaging
effectively positions bypass capacitors on-substrate"

I didn't find any further information about these capacitors.
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 107401
Subject: Re: placing addiional caps across existing caps to reduce noise
From: "Antti" <Antti.Lukats@xilant.com>
Date: 28 Aug 2006 00:58:58 -0700
Links: << >>  << T >>  << A >>
Uwe Bonnes schrieb:

> Austin Lesea <austin@xilinx.com> wrote:
>
>
> > To the subject at hand:  placing additional caps across existing caps
> > does not reduce the noise (unless the dominant cause is lack of adequate
> > capacitance).
>
> > The reason why the noise is bad is that the L (as in Ldi/dt) is most
> ...
>
> On that subject:
> The webpages for Spartan 5 talk about "Virtex-5 sparse chevron packaging
> effectively positions bypass capacitors on-substrate"
>
> I didn't find any further information about these capacitors.
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Spartan-5 ? is Spartan-4 going to be skipped?

Antti


Article: 107402
Subject: Re: FPGA -> SATA?
From: fpga_toys@yahoo.com
Date: 28 Aug 2006 01:05:39 -0700
Links: << >>  << T >>  << A >>

Antti wrote:
> in any case - I can not and do not want to belive that Xilinx designed
> boards with features knowing not to work (at the time of the board
> design).

I can, and do. I'm currently pissed about Austin's lost, totally
insult, and the overt attempt to cover up the fact that they shipped
FPGA's thru the XC2V and Pro series that trip over power problems for
valid customer designs. That it's probably finally fixed in the XC4V
and later parts is great ... ridiculing me as clueless when I bring up
the point as a warning to someone getting ready to push a board to it's
limits, is unethical to me.

if they are willing to do this for FPGA chips, I have no trouble
believing they would do it for board level products.

Every time I have raised this issue for a year, Austin and Peter have
let loose a scorched earth attack to suppress it, with full Xilinx
managment support.

Any customer design MUST be able to run with worst case data patterns
without causing device upsets, or it WILL/MAY be unstable in the field
under worst case voltage/temp/data patterns.

I have spent far too many years constructing systems level diagnostics
to debug this very problem in poor engineers designs that went into
production. Either they leave the production floor stalled with failing
product, or fail randomly in the field.

To have a chip, which by DESIGN, has an unspecificed instability that
is data/operation sensitive with power problems is HORRIBLE.  Sure some
designs, even a lot of designs, may work just fine. But what about the
poor engineer that has chased these gremlins for months, without
resolution ... or worse yet ... lost his job, or company because of it.

Without clear, well defined Icc limits for a chip, and good software to
accurately predict it with safe margins, it's impossible to design
known stable large systems with Xilinx FPGA's. That has to include peak
dynamic currents flowing a clock edge ... not rough averages over
several clocks.  Measuring "average systems" isn't enough, because it
doesn't include worst case data patterns, which may not always be that
easy to predict given that this software is free to combine and invert
data internally to pack LUTs.


Article: 107403
Subject: Re: Spartan 3 and 5V input
From: Kolja Sulimma <news@sulimma.de>
Date: Mon, 28 Aug 2006 10:07:33 +0200
Links: << >>  << T >>  << A >>
Nevo schrieb:

> Hm; I think I'm going to answer my own question here by pointing myself to 
> XAPP429 and a whole host of archived messages in comp.arch.fpga. 
Right. Like this one:
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/95ab9417252a5a71/f88bfdaf324cb93e?lnk=st&q=5v+spartan-3&rnum=1#f88bfdaf324cb93e
(First google groups hit for "5v spartan-3")

So just use a series resistor.

Kolja Sulimma

Article: 107404
Subject: Re: placing addiional caps across existing caps to reduce noise
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Mon, 28 Aug 2006 08:10:57 +0000 (UTC)
Links: << >>  << T >>  << A >>
Antti <Antti.Lukats@xilant.com> wrote:

> Spartan-5 ? is Spartan-4 going to be skipped?

Ouch!

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 107405
Subject: Spartan-4 ?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 28 Aug 2006 01:43:16 -0700
Links: << >>  << T >>  << A >>
New low cost families other than from Xilinx are known to be coming
this autumn (Cyclone-3, MAX3, LatticeXP2) but there is no advance info
an Spartan-4 yet, is there a hope at all that there will be modern low
cost family from Xilinx too?

Spartan-3 is 'not for new designs' as there is no price roadmap for it,
Spartan-3E only has small members, eg not replacement for S3

so we have vacuum in the place of Spartan-4 !

I wonder if that vacuum will be filled with Cyclone-3 or is Spartan-4
coming this autumn?

Antti


Article: 107406
Subject: Re: placing addiional caps across existing caps to reduce noise
From: Kolja Sulimma <news@sulimma.de>
Date: Mon, 28 Aug 2006 10:51:35 +0200
Links: << >>  << T >>  << A >>
Austin Lesea schrieb:

> You may have moved the resonant frequency (more often not), but often
> people make the mistake of assuming that a 0.1uF requires a 0.01uF and a
> 0.001uF in parallel.  You can see that if the series L is dominant, you
> haven't even moved the frequency by more than a few percent by the small
> amount of additional capacitance.

Larger caps can contribute a significant portion to the L. In that case
the second capacitor helps because you reduce part of the L by adding a
smaller L in parallel to a portion of the big L.
The inductance for an SMT capacitor is in the range of 50pH to 3000pH.
This is about the same range as vias of various sizes.

Kolja Sulimma

Article: 107407
Subject: Re: Xilinx IPIF DMA done interrupt ?
From: "Martijn" <M.G.v.d.Horst@gmail.com>
Date: 28 Aug 2006 01:55:10 -0700
Links: << >>  << T >>  << A >>
Doh!

I have found the problem. Before each DMA transfer I performed a
totally unnecessary reset on the DMA controllers, which puts the DMA
IER registers back to 0 and thus disables the DMA interrupts.

Do I feel stupid.

Martijn


Article: 107408
Subject: Re: Spartan-4 ?
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Mon, 28 Aug 2006 09:01:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
Antti <Antti.Lukats@xilant.com> wrote:
> New low cost families other than from Xilinx are known to be coming
> this autumn (Cyclone-3, MAX3, LatticeXP2) but there is no advance info
> an Spartan-4 yet, is there a hope at all that there will be modern low
> cost family from Xilinx too?

> Spartan-3 is 'not for new designs' as there is no price roadmap for it,
> Spartan-3E only has small members, eg not replacement for S3

> so we have vacuum in the place of Spartan-4 !

> I wonder if that vacuum will be filled with Cyclone-3 or is Spartan-4
> coming this autumn?

Related to this subject:

Did anybody see a XC3S500E-PQ208 out in the wild?

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 107409
Subject: Re: Spartan-4 ?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 28 Aug 2006 02:05:58 -0700
Links: << >>  << T >>  << A >>
Uwe Bonnes schrieb:

> Antti <Antti.Lukats@xilant.com> wrote:
> > New low cost families other than from Xilinx are known to be coming
> > this autumn (Cyclone-3, MAX3, LatticeXP2) but there is no advance info
> > an Spartan-4 yet, is there a hope at all that there will be modern low
> > cost family from Xilinx too?
>
> > Spartan-3 is 'not for new designs' as there is no price roadmap for it,
> > Spartan-3E only has small members, eg not replacement for S3
>
> > so we have vacuum in the place of Spartan-4 !
>
> > I wonder if that vacuum will be filled with Cyclone-3 or is Spartan-4
> > coming this autumn?
>
> Related to this subject:
>
> Did anybody see a XC3S500E-PQ208 out in the wild?
>
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Sure! I have a board with that chip on. It was the first S3e board
being shipped at all ASFAIK (looong time before s3esk !), its the s3e
usb module from cesys GmbH

Antti


Article: 107410
Subject: synchronisation on rising and falling edges
From: Andreas <"kunz2.10.Hinz"@spamgourmet.com>
Date: Mon, 28 Aug 2006 11:15:04 +0200
Links: << >>  << T >>  << A >>
Hello,

I have a little problem and I need some help.

I program a controller for a DDR-SDRAM on a FPGA-Board (Virtex 4, Xilinx).

For the synchronisation signal I need a process that is case sensitiv on 
both edges.

But the following commands are not synthesizeable:

" if DQS'event then..."

	or

" if (DQS'event and DQS = '1') and (DQS'event and DQS = '0') then..."

THx for any help...

Article: 107411
Subject: Re: Spartan-4 ?
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Mon, 28 Aug 2006 11:15:41 +0200
Links: << >>  << T >>  << A >>
Antti schrieb:
> New low cost families other than from Xilinx are known to be coming
> this autumn (Cyclone-3, MAX3, LatticeXP2) but there is no advance info
> an Spartan-4 yet, is there a hope at all that there will be modern low
> cost family from Xilinx too?
> 
> Spartan-3 is 'not for new designs' as there is no price roadmap for it,
> Spartan-3E only has small members, eg not replacement for S3
> 
> so we have vacuum in the place of Spartan-4 !

Is this paranoia or what?
Or am I getting old, damm I just turned 30 ;-)
Even if Spartan-3 is not TOTALLY brand new, I guess its fine for a few 
more years to come.
What do you want, guys? A new FPGA family every 6 month, similar to new 
high power graphic adapters for PCs?
Isnt this wheel of "inovation" spinning a little bit too fast?
How about fixing silicone AND software and getting a good stable ISE 
platform?

Just my old two cents
Falk

Article: 107412
Subject: Re: synchronisation on rising and falling edges
From: "Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com>
Date: 28 Aug 2006 02:19:43 -0700
Links: << >>  << T >>  << A >>


> I have a little problem and I need some help.
>
> I program a controller for a DDR-SDRAM on a FPGA-Board (Virtex 4, Xilinx).
>
> For the synchronisation signal I need a process that is case sensitiv on
> both edges.
>
> But the following commands are not synthesizeable:
>
> " if DQS'event then..."

You need to instanciate the DDR IOB flip flop by hand, you can't infer
them from
VHDL. Look at the templates in ISE for examples.

And btw, are you gonna drive directly the IOB FF clk input from the DQS
signals ???


> " if (DQS'event and DQS = '1') and (DQS'event and DQS = '0') then..."

Hum ... the logic reduction of the condition you put is "if false then"
...


     Sylvain


Article: 107413
Subject: Re: Spartan-4 ?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 28 Aug 2006 02:27:05 -0700
Links: << >>  << T >>  << A >>
Falk Brunner schrieb:

> Antti schrieb:
> > New low cost families other than from Xilinx are known to be coming
> > this autumn (Cyclone-3, MAX3, LatticeXP2) but there is no advance info
> > an Spartan-4 yet, is there a hope at all that there will be modern low
> > cost family from Xilinx too?
> >
> > Spartan-3 is 'not for new designs' as there is no price roadmap for it,
> > Spartan-3E only has small members, eg not replacement for S3
> >
> > so we have vacuum in the place of Spartan-4 !
>
> Is this paranoia or what?
> Or am I getting old, damm I just turned 30 ;-)
> Even if Spartan-3 is not TOTALLY brand new, I guess its fine for a few
> more years to come.
> What do you want, guys? A new FPGA family every 6 month, similar to new
> high power graphic adapters for PCs?
> Isnt this wheel of "inovation" spinning a little bit too fast?
> How about fixing silicone AND software and getting a good stable ISE
> platform?
>
> Just my old two cents
> Falk

Falk, your turn is OK. I have turned over 40, I think :)

if you asked for price forecast for Spartan-3 more than a year ago then
Xilinx response would have been that there is no price roadmap and that
S3e should be considered instead. But S3e only covers the smallest
members of the S3.

regarding the fix of the silicon AND software, sure I wish that too!
but I am not even hoping for the software to be fixed anymore. and I
expect the silicon to have minor errata as well. The thing is that if
S3 is out, and selling then whatever fixes it may need they will be
applied in next family. S3e did it partially but as it is not
replacement for S3, then in may eyes the modern Xilinx low cost family
just isnt here yet.

The s3e advantages over S3 may look like 'small things' but they are of
sufficient significance in many designs. So I think it would be a real
good thing if Xilinx low cost family would be out, with all the
features present in S3e and with array size and package option coverage
as wide as of S3. I assume that should be Spartan-4 unless Xilinx is
getting out from 'low cost FPGA' business.

Antti


Article: 107414
Subject: Re: Spartan-4 ?
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Mon, 28 Aug 2006 09:39:10 +0000 (UTC)
Links: << >>  << T >>  << A >>
Antti <Antti.Lukats@xilant.com> wrote:
...
> >
> > Related to this subject:
> >
> > Did anybody see a XC3S500E-PQ208 out in the wild?
> >

> Sure! I have a board with that chip on. It was the first S3e board
> being shipped at all ASFAIK (looong time before s3esk !), its the s3e
> usb module from cesys GmbH

Neither the "Xilinx" Online store nor digikey list that part...
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 107415
Subject: Re: Spartan-4 ?
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Mon, 28 Aug 2006 11:46:51 +0200
Links: << >>  << T >>  << A >>
Antti schrieb:

> Falk, your turn is OK. I have turned over 40, I think :)
> 
> if you asked for price forecast for Spartan-3 more than a year ago then
> Xilinx response would have been that there is no price roadmap and that

Do you REALLY expect a VALID forecast of prices in world/business, that 
changes THAT fast? Or should I say, a world that is that hectic.
Or is it just fast-paced?

> S3e should be considered instead. But S3e only covers the smallest
> members of the S3.

> regarding the fix of the silicon AND software, sure I wish that too!
> but I am not even hoping for the software to be fixed anymore. and I
> expect the silicon to have minor errata as well. The thing is that if

The minor eerata of silicone are one thing, but the software is IMHO the 
biggest problem. Thousands of features are getting added, and not just 
added, they get added in a hurry. The result is well known.
After all this amount to the question, do we want a Ferrari (new 
devices) that is damm fast but also damm often in the workshop, or would 
we rather prefer a settled Audi, not quite as fast and fancy, but damm 
reliable? I would go for the second option without a second of hesitation!

> S3 is out, and selling then whatever fixes it may need they will be
> applied in next family. S3e did it partially but as it is not
> replacement for S3, then in may eyes the modern Xilinx low cost family
> just isnt here yet.

There will never be a low cost family that satifies the customers. They 
ALWAYS cry for lower prices. "Geiz ist geil" as it is said here.

> The s3e advantages over S3 may look like 'small things' but they are of
> sufficient significance in many designs. So I think it would be a real
> good thing if Xilinx low cost family would be out, with all the
> features present in S3e and with array size and package option coverage
> as wide as of S3. I assume that should be Spartan-4 unless Xilinx is

Sounds like a wishlist for Santa Clause ;-)
You always want lower prices, more features etc.
A neverending story . . ..  ;-)

> getting out from 'low cost FPGA' business.

I dont think so.

MfG
Falk

Article: 107416
Subject: Re: Spartan-4 ?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Mon, 28 Aug 2006 21:55:16 +1200
Links: << >>  << T >>  << A >>
Antti wrote:
> New low cost families other than from Xilinx are known to be coming
> this autumn (Cyclone-3, MAX3, LatticeXP2) but there is no advance info
> an Spartan-4 yet, is there a hope at all that there will be modern low
> cost family from Xilinx too?
> 
> Spartan-3 is 'not for new designs' as there is no price roadmap for it,
> Spartan-3E only has small members, eg not replacement for S3
> 
> so we have vacuum in the place of Spartan-4 !
> 
> I wonder if that vacuum will be filled with Cyclone-3 or is Spartan-4
> coming this autumn?

Any info out yet on what MAX3 looks like ?
Does it improve Static Icc, and lack of memory of MAX II, for example ?
Smallest devices / largest devices  ?

-jg


Article: 107417
Subject: Re: Style of coding complex logic (particularly state machines)
From: "KJ" <kkjennings@sbcglobal.net>
Date: Mon, 28 Aug 2006 11:08:53 GMT
Links: << >>  << T >>  << A >>

"Eli Bendersky" <eliben@gmail.com> wrote in message 
news:1156743235.737612.294510@i42g2000cwa.googlegroups.com...
> KJ wrote:
>> I never use async resets with the exception of the flip flop that
>> receives the external reset signal that is the start of a shift chain
>> for developing my internal design reset.
>
> Don't you run into fanout problems for that single flip-flop that
> pushes the sync reset signal to all other FFs in the design, or does
> the synthesis tool take care of this ? I tend to use async resets, but
> my whole design is usually synchronized to the same clock so there are
> no reset problems.
>
The fanout of the reset signal is the same regardless of whether you use 
synchronous or asynchronous resets.  In either case, the reset signal still 
needs to be synchronized to the clock (see further down for more info) and 
in both cases the reset signal itself must meet timing constraints.  If the 
reset signal doesn't meet timing constraints due to fanout (and the 
synthesis tool didn't pick up on this and add the needed buffers 
automatically) then most fitters for FPGAs give some method for limiting 
fanout with some vendor specific attribute that can be added to the signal.
>>
>> I never have issues with some clocked signals getting cleared and
>> others not or going to unexpected states (see above paragraph).  I have
>> however fixed several designs that did use asynchronous resets
>> inappropriately both on a board and within programmable logic.
>>
>> I don't recall ever having to fix reset issues on others designs when
>> synchronous resets were used...hmm, well maybe I've just lived in a
>> narrow design world.
>
> Can you point out a few common problems with async resets ? In
> particular, what is using them "appropriately" and what isn't ?

1. Forgetting (or not realizing) that the reset signal does in fact need to 
be synchronized to the clock(s).  Whether using async or sync resets in the 
design, the timing of the trailing edge of reset must be synchronized to the 
appropriate clock.  Simply ask yourself, what happens when the reset signal 
goes away just prior to the rising edge of the clock and violates the setup 
time of a particular flip flop?  The answer is that well...you can get 
anything....and that each flip flop that gets this signal can respond 
differently.....and then what would that state do to you think your 7 state, 
one hot, state machine will be in after this clock?  Quite possibly you 
might find two hot states instead of just one.
2. Somewhat related to #1...Forgetting that your 'synchronized to the clock' 
reset signal is only synchronized within the one clock domain....and using 
it in some other clock domain which puts you right back into the situation 
of #1, that the reset signal can violate timing.  This is really a clock 
domain crossing problem and would occur whether async or sync resets were 
used though but thought I'd toss it in.  It does mean though that you need 
separate shift chains (one for each clock domain that needs a reset) but 
again, you need this regardless of if the rest of the design uses reset 
synchronously or asynchronously.
3. On a board that distributes the reset signal to whoever needs it, having 
that reset signal pick up noise that gets coupled over from some other 
signal on the board.  By using the reset signal synchronously internal to 
the device, you can minimize (and often eliminate) what otherwise would have 
been 'inadvertant' resets caused by noise coupling.  If the board design 
happens to be a single clock design, then this 'noise' would most likely be 
occurring just after the clock when all the outputs are switching, but if 
you use the reset signal in a synchronous manner then it is just like any 
other signal and doesn't need any special care when routing the board....you 
can't the same for an async reset signal on the board, routing of the 
'reset' signal can be an issue...and one that you won't be able to give any 
real good guidance about to the PCB designer that is trying to route this 
signal.
4. Overuse of just which signals really need to be 'reset'.  This is 
somewhat related to #3 and is also a function of the designer.  Some feel 
that every blasted flip flop needs to be reset...with no reason that can be 
traced back to the specification for what the board is supposed to do, it's 
just something 'they always do'.  Inside an FPGA this may not matter much 
since we're implicitly trusting the FPGA vendors to distribute a noise free 
signal that we can use for the async reset, but on a board this can lead to 
distributing 'reset' to a whole bunch of devices...which just gives that 
signal much more opportunity to pick up the noise mentioned in #3.  If 
you're lucky, the part that gets the real crappy, noisy reset signal is the 
one where you look at the function and realize that no, nothing in here 
'really' needs to get reset when the 'reset' signal comes in.  At worst 
though, you see that yes the reset is needed, and you may start band-aiding 
stuff on to the board to get rid of the noise or filter it digitally inside 
the device if you can, etc.  Bottom line though is that if more (some?) 
thought had been put in up front, the reset signal wouldn't have been 
distributed with such wild abandon in the first place.
5. There was also a post either here or in comp.lang.vhdl in the past couple 
months that talked about how using the generally listed template can result 
in gated clocks getting synthesized when you have some signals that you want 
reset, and other signals that you don't.  Being in the same process and all, 
the original poster found that gated clocks were being synthesized in order 
to implement this logic.  The correct form of the template (that rarely gets 
used by anyone posting to either this group or the vhdl group) is of the 
form
process(clk, reset)
begin
    if rising_edge(clk) then
        s1 <= Something;
        s2 <= Something else;
    end if;
    if (reset = '1') then
        s1 <= '0';
        -- s2 does not need to be reset,
   end if;
end process;

Again, the scenario here is that you have
- More than one signal being assigned in this process
- At least one of those signals is not supposed to change as a result of 
reset (either this is by intent, or by unintentionally forgetting to put the 
reset equation)

Depending on the synthesis tool, this could result in a gated clock getting 
generated as the clock to signal 's2' in the above example.

KJ 



Article: 107418
Subject: Re: high level languages for synthesis
From: "KJ" <kkjennings@sbcglobal.net>
Date: Mon, 28 Aug 2006 11:19:29 GMT
Links: << >>  << T >>  << A >>

<fpga_toys@yahoo.com> wrote in message 
news:1156625298.673980.153570@i42g2000cwa.googlegroups.com...
>
> KJ wrote:
>> 'Works as designed' is a given (except for the occasional bugs that pop 
>> up
>> in the compiler/synthesis tool itself).  'Works as intended' is another
>> thing entirely where the right language (whatever that may be) and a 
>> skilled
>> user/designer are probably the biggest aids in minimizing the gap between
>> 'as designed' and 'as intended'.
>>
>> I know, I'm just stating the obvious here ;)
>
> yes, and it can not be said enough times. The turning point is a
> complexity * (probability of mistake) product which predicts the likely
> hood of making errors.
>
> When you build circits a bit at a time, then a 2M bit device will have
> a development error rate of 2M times the probablity of a bit programmer
> error. If those 2M bits are better described as 50 lines of HLL, the
> error rate is a different product based on 50 times the probablility of
> an HLL coding error. This second probablility can be relatively low, or
> in some cases very high too (such as a C programmer writing their first
> complex Lisp). In addition, debug time is directly proportional to
> expression size ... looking for a needle in a haystack problem, vs
> sorting thru 50 pins.
>
> HLL's tend to leverage smaller well defined complexity, to produce
> lower over all system probablility of error.
>
I agree that every line of code is a probability for design error, but in my 
opinion, the various languages being bandied about for doing hardware design 
can me equally used to create either succint code that describes the 
functionality concisely or misused to describe the functionality 'bit at a 
time' as you say (I'm interpreting that to mean....bloated....lots of code 
that could've been written more concisely).

Whether you get the concise code or the bloated code for a particular 
hardware design I've found is simply a function of
- The skill level of the person with the hardware design language that they 
are using.
- The skill level of the person in hardware design.

I could be wrong, but I haven't seen anything to indicate that the actual 
language used itself is an important factor.

KJ 



Article: 107419
Subject: Re: Arbiter design problem?
From: "arant" <arant.agrawal@gmail.com>
Date: 28 Aug 2006 05:46:59 -0700
Links: << >>  << T >>  << A >>
[1] Is Arbiter pure comb logic?

Definitely not except for the case when a registered reqest signal is
given by the resourse requesting entity.

>> If yes, shall its comb logic delay be constrained to within one clock cycle?

In case the request signals are registered (in the requesting entity )
before usage in the Arbiter the above statement could hold true . The
protocol may be that the requesting entity holds its request line high
untill the grant signal is received by it.

Usually the arbiter implementation is using an fsm opeating on the bus
clock and reset signal (eg an AHB arbiter which operates on HCLK and
Hresetn)

>>[2] Shall one request and one grant both hold only one clock cycle?

Request needs to be registered either in the requesting entity or the
arbiter fsm untill it is processed (ie held valid untill the previous
resource assignment is completed). The grant may be of one cycle
duration informing the requesting of the resource allocation.

An exception may be in the case of DMA when a burst of transfers is
required between it and a requesting peripheral/memory.

[2] Shall one request and one grant both hold only one clock cycle?
bazarnik@hotmail.com wrote:
> Thanks for interestign link.
>
> > [1] Is Arbiter pure comb logic? If yes, shall its comb logic delay be
> > constrained to within one clock cycle?
>
> In general no. Only trivial static priority arbiter can be a simple
> combinational logic. In practice the aribters need to store
> a prior state (or states) information to modify the priority
> and this requires sequential logic/memory etc.
>
> The priority is made dynamic to achieve some particular goals:
> for example to prevent starvation of low priority requesters while
> still give low latency to high priority ones.
> It all very much depends on application.
> Network devices hve really elaborate arbiter algorithms.
>
> > [2] Shall one request and one grant both hold only one clock cycle?
>
> Obviously request will be active for several clock cycles.
> This is beacuse some waiting time for acknowledge is necessary.
> (If not then why would we need arbiter?)
>
> Acknowledge is one clock cycle but this is because there is
> no beneft in making it any longer.
> One cycle acknowledge is "atomic"
>
> BTW Paper specifies many more advanced schemes where
> acknowledge is delayed and a pointers are used in requester
> to figure out how many requests have been acknowledged.
>
> Cheers,
> Przemek
>
>
> Davy wrote:
> > Hi all,
> >
> > I have two problem when reading the paper from
> > [url]http://www.siliconlogic.com/pdf/Arbiters_MattWeber_SLE.pdf [/url]
> >
> > [1] Is Arbiter pure comb logic? If yes, shall its comb logic delay be
> > constrained to within one clock cycle?
> > [2] Shall one request and one grant both hold only one clock cycle?
> > 
> > Best regards, 
> > Davy


Article: 107420
Subject: Re: Style of coding complex logic (particularly state machines)
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 28 Aug 2006 05:53:02 -0700
Links: << >>  << T >>  << A >>

KJ wrote:
> I never use async resets with the exception of the flip flop that
> receives the external reset signal that is the start of a shift chain
> for developing my internal design reset.
>
I overstated somewhat.  There are times when external interfaces
require asynch reset behaviour.  Generally though the behaviour that is
required is for the outputs to 'shut off', 'tri-state' or something of
that flavor.  In those situations, you are of course are then required
to async reset those outputs....but that in no way implies that that
the async reset needs to go anywhere else (like into the state machines
that have the logic that drives those outputs).

So use those async reset flip flops where it is actually required per
specification and nowhere else is probably closer to the truth about my
actual usage.

KJ


Article: 107421
Subject: Re: What is the truth about the Virtex5 ?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Mon, 28 Aug 2006 14:05:21 +0100
Links: << >>  << T >>  << A >>
On Sun, 27 Aug 2006 09:04:53 -0700, Austin Lesea <austin@xilinx.com>
wrote:

>Brian,
>
>Peter is still tilting at that windmill (the on line store).
>
>I am cheering him on.
>
>Perhaps Peter can tell us how the on line store is progressing when he 
>bets back from Europe.

Thanks.

- Brian

Article: 107422
Subject: Re: Style of coding complex logic (particularly state machines)
From: "rickman" <gnuarm@gmail.com>
Date: 28 Aug 2006 06:11:39 -0700
Links: << >>  << T >>  << A >>
KJ wrote:
> "Eli Bendersky" <eliben@gmail.com> wrote in message
> news:1156743235.737612.294510@i42g2000cwa.googlegroups.com...
> > KJ wrote:
> >> I never use async resets with the exception of the flip flop that
> >> receives the external reset signal that is the start of a shift chain
> >> for developing my internal design reset.
> >
> > Don't you run into fanout problems for that single flip-flop that
> > pushes the sync reset signal to all other FFs in the design, or does
> > the synthesis tool take care of this ? I tend to use async resets, but
> > my whole design is usually synchronized to the same clock so there are
> > no reset problems.
> >
> The fanout of the reset signal is the same regardless of whether you use
> synchronous or asynchronous resets.  In either case, the reset signal still
> needs to be synchronized to the clock (see further down for more info) and
> in both cases the reset signal itself must meet timing constraints.  If the
> reset signal doesn't meet timing constraints due to fanout (and the
> synthesis tool didn't pick up on this and add the needed buffers
> automatically) then most fitters for FPGAs give some method for limiting
> fanout with some vendor specific attribute that can be added to the signal.

The fanout of an async reset in an FPGA is not an issue because the
signal is a dedicated net.  The timing is an issue as all the FFs have
to be released in a way that does not allow counters and state machines
to run part of their FFs before the others.  But this can be handled by
ways other than controlling the release of the reset.  Typically these
circuits only require local synchronization which can be handled easily
by the normal enable in the circuit.  For example most state machines
do nothing until an input arrives.  So synchronization of the release
of the reset is not important if the inputs are not asserted.  Of
course this is design dependant and you must be careful to analyze your
design in regards to the release of the reset.


> 1. Forgetting (or not realizing) that the reset signal does in fact need to
> be synchronized to the clock(s).  Whether using async or sync resets in the
> design, the timing of the trailing edge of reset must be synchronized to the
> appropriate clock.  Simply ask yourself, what happens when the reset signal
> goes away just prior to the rising edge of the clock and violates the setup
> time of a particular flip flop?  The answer is that well...you can get
> anything....and that each flip flop that gets this signal can respond
> differently.....and then what would that state do to you think your 7 state,
> one hot, state machine will be in after this clock?  Quite possibly you
> might find two hot states instead of just one.

That is what I addressed above.  Whether the circuit will malfunction
depends on the circuit as well as the inputs preset.  It is often not
hard to assure that one or the other prevents the circuit from changing
any state while the reset is released.

Since the dedicated global reset can not be synchronized to a clock of
even moderately high speed, you can provide local synchronous resets to
any logic that actually must be brought out of reset cleanly.  I
typically use thee FFs in a chain that are reset to zero and require
three clock cycles to clock a one through to the last FF.


> 4. Overuse of just which signals really need to be 'reset'.  This is
> somewhat related to #3 and is also a function of the designer.  Some feel
> that every blasted flip flop needs to be reset...with no reason that can be
> traced back to the specification for what the board is supposed to do, it's
> just something 'they always do'.  Inside an FPGA this may not matter much
> since we're implicitly trusting the FPGA vendors to distribute a noise free
> signal that we can use for the async reset, but on a board this can lead to
> distributing 'reset' to a whole bunch of devices...which just gives that
> signal much more opportunity to pick up the noise mentioned in #3.  If
> you're lucky, the part that gets the real crappy, noisy reset signal is the
> one where you look at the function and realize that no, nothing in here
> 'really' needs to get reset when the 'reset' signal comes in.  At worst
> though, you see that yes the reset is needed, and you may start band-aiding
> stuff on to the board to get rid of the noise or filter it digitally inside
> the device if you can, etc.  Bottom line though is that if more (some?)
> thought had been put in up front, the reset signal wouldn't have been
> distributed with such wild abandon in the first place.

This is not a problem when you use the dedicated reset net.  Even
though there are FFs that do not need a reset, it does not hurt to put
the entire device in a known state every time.  It is not hard to miss
a FF that needs to be reset otherwise.

Personally I think the noise issue is a red herring.  If you have noise
problems on the board, changing your reset to sync will not help in
general.  You would be much better off designing a board so it does not
have noise problems.


Article: 107423
Subject: Re: high level languages for synthesis
From: "Robin Bruce" <robin.bruce@gmail.com>
Date: 28 Aug 2006 07:01:38 -0700
Links: << >>  << T >>  << A >>
There seems to be little attempt here to categorise the tools
themselves. Are we talking solely about cycle-accurate HLLs or not? The
differences between a tool like Handel-C and a tool like Impulse-C are
enormous. I would argue that the non-cycle-accurate high-level
languages are more distinct from their cycle-accurate cousins than
either of them are from HDLs.

The cycle-accurate languages seem to suit a spiral methodology that
begins with high levels of abstraction. Functional models precede a
hardware-software partition and the fine details are filled in
gradually, with functional testing at every stage. At the end of the
design process you are almost as close to the hardware as you would
have been if you designed in VHDL in the first place, still having to
understand what's happening on every  clock cycle. Handel-C and
System-C fit into this category. The advantage to these languages is
that you are working at the system level from the outset. It's not so
straightforward to use a spiral design methodology using VHDL, which is
much better suited to building and testing all your components fully
before you bring them together. That's a nasty time to find that there
are problems with the system-level design, as the components themselves
may need re-designed. These languages make sense for large projects
where timescales are tight, budgets are large and you want to mitigate
the risks of design respins. See Jonathan Feifarak's paper at last
year's MAPLD conference for an example:

http://klabs.org/mapld05/papers/

Non cycle-accurate languages are targeted at an entirely different
crowd, and are more suited for general-purpose reconfigurable
computing. Example of these languages are Impulse-C, SRC's Carte
Programming Environment, Mitrionics' MitrionC, and Nallatech's DIME-C.
They get their performance speed-ups from a mixture of spatial and
temporal parallelism.

These languages are aimed at users that are not necessarily familiar
with FPGA development, or even low-level programming. High-Performance
Computing users are those who have most to gain from general-purpose
reconfigurable computing. Paradoxically these users, who have the
greatest need of high performance, are often not the power users one
would expect due to the fact they are also application-domain
specialists. They may be used to writing C, but as an alternative to
FORTRAN and not as an alternative to assembly language. To expect such
people to be able to take quickly to VHDL is misunderstand who these
users are. These people do not want to design PCI cores, but instead
want to compare genetic sequences, implement CFD simulations and
implement a wide variety of other scientific algorithms. These
algorithms exist in C and FORTRAN presently and people are now looking
to porting them to FPGAs. The tools do not make it possible to simply
compile pre-existing C applications and receive 500X speed-up, but they
instead offer an environment in which all the nasty complexities of
FPGA design are abstracted. Users can adapt the algorithms to best suit
the hardware compiler. No clock periods, no PCI cores to design, no
memory controllers to worry about, no pins to worry about. The tool
only makes sense as part of an integrated platform that makes all of
this possible. Many of these tools are now beginning to lean towards a
library-based development process, where the most frequently used
functions are implemented, ideally as pipelined cores, in a traditional
HDL process and then integrated into the tool.

This kind of development also has a place within High-Performance
Embedded Computing. Your application may interface to sensors and
actuators etc..., but in the world of the billion-plus transistor FPGA
some seriously complicated algorithms can be implemented. At this stage
it makes sense to develop the external interfaces in a traditional HDL
manner, but develop the main algorithm in a high-level language. This
allows for a lot more experimentation with the main algorithm. You
don't give up half as much performance as you think you might in doing
things this way and you could react to market opportunities a lot more
quickly. Once you've settled on the structure of your algorithm, you
have the option of recreating this architecture in HDL for a
performance increase. You could either do this before you release the
first version of your design to users, or you could get there first
with the HLL version then follow it up later with the optimised
version.

A final point is that we really need to nail down this fallacy that an
FPGA-targeting C-syntax HLL is somehow inherently sequential. It's not.
The compiler determines that. FPGAs are best for algorithms where there
are large data sets. They offer the best performance when the
algorithms (or their main computational loops) are pipelinable. For
loops should be pipelined as a matter of course wherever possible.
Below is a quick example of what I mean. It's a DIME-C design that
implements the probality density function. The array sizes are 8192
here, as I've implemented the memory in BRAM, though I could have had
these arrays packed into SRAMs, so they could be a lot bigger. The
entire for loop is pipelined, so the whole thing will take N + latency
cycles to execute. In this case latency is about 85 cycles. I would
expect a clock rate of 120-150MHz on V4 for this, but I haven't
actually built this.

It took me 15 minutes to do this, and I'm a real slowcoach. I wonder
how long it would take me to do with VHDL...

/* Project to implement probability density function
   on V4 device
   Robin Bruce
   28/08/06 */

#include "math.h"
#define SIZE 8192
#define PI 3.1415926535897
#define ROOT_2PI 2.506628274

void probability_density(float x[SIZE], float mu[SIZE], float
sigma[SIZE],
                         float phi[SIZE], int N)
{

  int i = 0;
  float sigma_sqr = 0.0;
  float dif_x_mu_sqr = 0.0;
  float dif_x_mu = 0.0;
  float sigma_local = 0.0;
  float x_local = 0.0;
  float mu_local = 0.0;

  for(i=0; i<N; i++){

    sigma_local = sigma[i];
    mu_local = mu[i];
    x_local = x[i];

    sigma_sqr = sigma_local * sigma_local;

    dif_x_mu = x_local - mu_local;
    dif_x_mu_sqr = dif_x_mu * dif_x_mu;

    phi[i] = (1.0 / (sigma_local * ROOT_2PI)) * expf(-( dif_x_mu_sqr /
(2 * sigma_sqr) ));

  }

}



KJ wrote:
> <fpga_toys@yahoo.com> wrote in message
> news:1156625298.673980.153570@i42g2000cwa.googlegroups.com...
> >
> > KJ wrote:
> >> 'Works as designed' is a given (except for the occasional bugs that pop
> >> up
> >> in the compiler/synthesis tool itself).  'Works as intended' is another
> >> thing entirely where the right language (whatever that may be) and a
> >> skilled
> >> user/designer are probably the biggest aids in minimizing the gap between
> >> 'as designed' and 'as intended'.
> >>
> >> I know, I'm just stating the obvious here ;)
> >
> > yes, and it can not be said enough times. The turning point is a
> > complexity * (probability of mistake) product which predicts the likely
> > hood of making errors.
> >
> > When you build circits a bit at a time, then a 2M bit device will have
> > a development error rate of 2M times the probablity of a bit programmer
> > error. If those 2M bits are better described as 50 lines of HLL, the
> > error rate is a different product based on 50 times the probablility of
> > an HLL coding error. This second probablility can be relatively low, or
> > in some cases very high too (such as a C programmer writing their first
> > complex Lisp). In addition, debug time is directly proportional to
> > expression size ... looking for a needle in a haystack problem, vs
> > sorting thru 50 pins.
> >
> > HLL's tend to leverage smaller well defined complexity, to produce
> > lower over all system probablility of error.
> >
> I agree that every line of code is a probability for design error, but in my
> opinion, the various languages being bandied about for doing hardware design
> can me equally used to create either succint code that describes the
> functionality concisely or misused to describe the functionality 'bit at a
> time' as you say (I'm interpreting that to mean....bloated....lots of code
> that could've been written more concisely).
>
> Whether you get the concise code or the bloated code for a particular
> hardware design I've found is simply a function of
> - The skill level of the person with the hardware design language that they
> are using.
> - The skill level of the person in hardware design.
>
> I could be wrong, but I haven't seen anything to indicate that the actual
> language used itself is an important factor.
> 
> KJ


Article: 107424
Subject: Re: Style of coding complex logic (particularly state machines)
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 28 Aug 2006 07:02:51 -0700
Links: << >>  << T >>  << A >>
rickman wrote:
> KJ wrote:
> > "Eli Bendersky" <eliben@gmail.com> wrote in message
> > news:1156743235.737612.294510@i42g2000cwa.googlegroups.com...
> > > KJ wrote:
> > > Don't you run into fanout problems for that single flip-flop that
> > > pushes the sync reset signal to all other FFs in the design, or does
> > > the synthesis tool take care of this ? I tend to use async resets, but
> > > my whole design is usually synchronized to the same clock so there are
> > > no reset problems.
> > >
> > The fanout of the reset signal is the same regardless of whether you use
> > synchronous or asynchronous resets.  In either case, the reset signal still
> > needs to be synchronized to the clock (see further down for more info) and
> > in both cases the reset signal itself must meet timing constraints.  If the
> > reset signal doesn't meet timing constraints due to fanout (and the
> > synthesis tool didn't pick up on this and add the needed buffers
> > automatically) then most fitters for FPGAs give some method for limiting
> > fanout with some vendor specific attribute that can be added to the signal.
>
> The fanout of an async reset in an FPGA is not an issue because the
> signal is a dedicated net.
My point was that if timing is not met due to the large fanout, that
the typical fitter will allow for the fanout to be limited by the user
if necessary.  But to directly answer the original question, 'no' I
haven't had reset signal fanout as a problem but if I did I know I
could fix it by limiting the fanout on the fitter side without having
to change the source code.  But I also tend to reset only those things
that really need resetting which, by itself, cuts down on the fanout as
well.

> The timing is an issue as all the FFs have
> to be released in a way that does not allow counters and state machines
> to run part of their FFs before the others.  But this can be handled by
> ways other than controlling the release of the reset.  Typically these
> circuits only require local synchronization which can be handled easily
> by the normal enable in the circuit.  For example most state machines
> do nothing until an input arrives.  So synchronization of the release
> of the reset is not important if the inputs are not asserted.  Of
> course this is design dependant and you must be careful to analyze your
> design in regards to the release of the reset.
I agree.

> > 1. Forgetting (or not realizing) that the reset signal does in fact need to
> > be synchronized to the clock(s).  Whether using async or sync resets in the
> > design, the timing of the trailing edge of reset must be synchronized to the
> > appropriate clock.  Simply ask yourself, what happens when the reset signal
> > goes away just prior to the rising edge of the clock and violates the setup
> > time of a particular flip flop?  The answer is that well...you can get
> > anything....and that each flip flop that gets this signal can respond
> > differently.....and then what would that state do to you think your 7 state,
> > one hot, state machine will be in after this clock?  Quite possibly you
> > might find two hot states instead of just one.
>
> That is what I addressed above.  Whether the circuit will malfunction
> depends on the circuit as well as the inputs preset.  It is often not
> hard to assure that one or the other prevents the circuit from changing
> any state while the reset is released.
>
But simply synchronizing the reset in the first place will do that as
well...two different approaches to the problem, each equally valid.

> Since the dedicated global reset can not be synchronized to a clock of
> even moderately high speed, you can provide local synchronous resets to
> any logic that actually must be brought out of reset cleanly.  I
> typically use thee FFs in a chain that are reset to zero and require
> three clock cycles to clock a one through to the last FF.
Agreed, but one can also view these locally generated resets as simply
synchronized versions of the original reset.  In fact, the synthesizer
would probably do just that seeing that you have (for example) 4 places
throughout the design where you've generated a local reset which is
simply the raw reset signal brought into a flip flop chain (I think
that's what you're describing).  So it would take those four instances
and probably generate a single shift chain and local reset signal to
send to those 4 places.  So all you've really done is written the
source code for the local reset 3 more times than is needed.  Had you
taken the view that the reset input to those 4 places must be a
synchronized reset signal in the first place you probably would've
written the reset shift chain logic one time at a top level and
connected it up to those four inputs yourself and not written it on the
receiver side.

> > 4. Overuse of just which signals really need to be 'reset'.  This is
> > somewhat related to #3 and is also a function of the designer.  Some feel
> > that every blasted flip flop needs to be reset...with no reason that can be
> > traced back to the specification for what the board is supposed to do, it's
> > just something 'they always do'.  Inside an FPGA this may not matter much
> > since we're implicitly trusting the FPGA vendors to distribute a noise free
> > signal that we can use for the async reset, but on a board this can lead to
> > distributing 'reset' to a whole bunch of devices...which just gives that
> > signal much more opportunity to pick up the noise mentioned in #3.  If
> > you're lucky, the part that gets the real crappy, noisy reset signal is the
> > one where you look at the function and realize that no, nothing in here
> > 'really' needs to get reset when the 'reset' signal comes in.  At worst
> > though, you see that yes the reset is needed, and you may start band-aiding
> > stuff on to the board to get rid of the noise or filter it digitally inside
> > the device if you can, etc.  Bottom line though is that if more (some?)
> > thought had been put in up front, the reset signal wouldn't have been
> > distributed with such wild abandon in the first place.
>
> This is not a problem when you use the dedicated reset net.
I agree, but I was referring more to the reset signal distribution on a
board rather than inside an FPGA.

> Even though there are FFs that do not need a reset, it does not hurt to put
> the entire device in a known state every time.
OK, it doesn't 'hurt', but it doesn't 'help' either in the sense that
both approaches would meet the exact same requirements of the
functional specification for that part.

> It is not hard to miss a FF that needs to be reset otherwise.
Inside the FPGA it doesn't matter since if you discover something that
you now realize needs to be reset you re-route and get a new file.  Not
routing it to a part on a board and then discovering you need it is a
bit more of an issue.  Resolving that issue by routing reset to every
part and then using it asynchronously is where problems have come up
when there are a lot of parts on the board.

> Personally I think the noise issue is a red herring.
If it's a red herring than I can safely say that I have slayed several
red herrings over my career...but actually not many of late....not
since a certain couple designers moved on to to greener pastures to be
brutally honest.

> If you have noise
> problems on the board, changing your reset to sync will not help in
> general.  You would be much better off designing a board so it does not
> have noise problems.
Maybe.  But remember the scenario when you're brought in to fix a
problem with an existing board that you trace back to some issue with
reset.  In that situation, a programmable logic change is more likely
the more cost effective solution.

KJ




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