Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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? AnttiArticle: 107402
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
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 SulimmaArticle: 107404
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
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? AnttiArticle: 107406
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 SulimmaArticle: 107407
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. MartijnArticle: 107408
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
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 AnttiArticle: 107410
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
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 FalkArticle: 107412
> 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: 107413Falk 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. AnttiArticle: 107414
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
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 FalkArticle: 107416
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 ? -jgArticle: 107417
"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<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. KJArticle: 107419
[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, > > DavyArticle: 107420
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. KJArticle: 107421
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. - BrianArticle: 107422
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
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: 107424rickman 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:
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