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
Eric Montreal wrote: > AFAIK, Muzaffer Kal is right. > > The latest T13 document he references clarify the data rates / throughput > http://www.t13.org/project/d1410r1a.pdf > > Look page numbered 400 (414 in acrobat reader) third paragraph, > and you'll find the exact transfert speed for all modes. > > If you made a UDMA interface that runs a 16.67 Mhz, thus transferring > 16.67 * 2[transfers per clock] * 2[bytes per transfert], then it's UDMA > mode 4 (AKA UDMA66) and not UDMA33. > > If you plan to build a UDMA controller with a 33 Mhz clock, you're > ahead of times and already building a UDMA133 interface. > IOW, you will simply overclock your drive, and, as usual, that's pretty > sure to work in the lab / fail in the field. > > The fastest established standard, UDMA100, uses a 25 Mhz clock > to attain 25*2*2=100 MBytes per second. > > Double check the timing in table 57 ( page numbered 361 (375 in acrobat reader)) > > "T2cyctyp" for UDMA mode 2 (AKA UDMA33) is 120 ns (8.33 Mhz) . > > "T2cyctyp" for UDMA mode 4 is 60 ns (16.67 Mhz) while Tcyc applies to either > half clock period and is specified to allow for unequal High / Low clock times. > Tcyc is *not* the clock cycle time. > > Hope this helps. > > Eric. > > ------------------------------------- > > I stand corrected. I was designing for mode 2 i.e UDMA33. But its such a long time ago that I thought I'd designed the i/f around a 16.67 MHz clock & not an 8.33MHz one! In fact, dependent on the speed the logic's clocked at, it will already handle a 16.67MHz clock. This is great since I have to do practically no work to get the client's requested UDMA66, I don't see any great problem with UDMA100, and for once I can get ahead of the game and invent UDMA133 [mode 6 ?]. Once again apologies to all.Article: 29676
"S. Ramirez" wrote: > >Ray, > Sorry for not responding to you sooner. I see that some others have > responded. I was out in my garage doing a fiberglass layup, and once I > start it, I cannot walk away until it is finished! > I'm not sure if we are talking about the same thing, so let me > elaborate. > The first flip flop, FF1, I am sure that everyone agrees it will meta > when used as a synchronizing flip flop. There is a certain probability, p1, > for a particular FF1 to meta if the input signal changes within the > setup/hold time violation window. There is another probability, p2, of the > time that FF1 spends in meta. As that time increases, p2 decreases. These > two probabilities multiply and give the final probability in a simplisitic > form. If meta exists when FF2 samples FF1's output, then it will also have > a probability of meta. Usually the clock cycle time of the two flip flops > is much greater than the time for p2 to be significant, because this cycle > time is usually dealing with prop delays that affect register to register > performance. But as well know, a long cycle time does not guarantee that > FF2 will not see meta. > I claim that one can make the state machine flip flops the FF2s. As > long as they don't see meta at their setup-hold time window, they will > perform as intended. With the probability of meta being in the range of > years, decades, centuries, this is accepted as practice. If one inserts FF2 > between FF1 and the state machine flip flops, then FF2 becomes subject to > that meta. It will in turn meta in a hundred years and introduce its own > small probability (p1*p2) of affecting the state machine's flip flops. In > other words, inserting FF2 only decreases the probability of causing a > problem at the state machine, because the probabilities multiply > (p1*p2*p1*p2). But I claim that multiple flip flops in a state machine can > serve as FF2s and work correctly as long as one knows that they will meta > some time in the distant future (p1*p2). Introducing FF2 between FF1 and > the state machine has the disadvantage of adding another cycle of delay > along with decreasing the probability of the flip flops acting as flop > flops. > Usually in a state machine, there are multiple flip flops that will get > affected by this low probability of meta. There are different ways of > designing state machines, but I really don't know how to design a state > machine where only one flip flop will be affected, or at least I don't > design state machines that way. I usually use one-hot encoding, but this > doesn't guarantee that only one flip flop will be affected. Along with the > state encoding bits, there are state output bits that are a function of the > present state and the inputs, meta included. My state output bits are not > the state encoding bits, so there are multiple flip flops there seeing the > low probability of meta. > I have seen others use FF1 and FF2, but I always questioned why they > used it. We never really came into an agreement that either I was wrong or > they were wrong. If I am wrong, then I am capable of learning things. But > my theories come from two major defense contractors that did some work in > this area and standardized their design methodologies using the state > machine flip flops as FF2s. Their design handbook included what I said > above as well as other procedures. An example of one of these procedures > is if one is building a nuclear device that is controlled by an electronic > circuit, then everything needs to be synchronous, with the exception of a > very few and heavily studied signals. On the other hand, if you are Saddam > Hussein working on an asynchronous nuclear device and the U.N. inspectors > are scheduled to see you in a week, and you don't have time to convert it to > a synchronous design, then you take your chances, run BIST and test it now! > Simon Ramirez, Consultant > Synchronous Design, Inc. > Oviedo, FL USA I agree basically with Simon. What we have for an FF whose input has change has violated the su/hld spec is a probability distribution p(t) which give the probability that the output will be in a legal state at time t after the clock edge. So the calculation is: find the value of t, call it Tok for which this probablility is within you acceptable limits. If Tok + routing time + next FF setup time is < the clock period then Simon's argument holds. If not then you need another FF. The worst case is where the device is sufficiently slow that even with a 0 routing time this sum cannot be met. You are then really into stats and need a chain of FFs. If Tcyc is the clock period you then need N FFs so that p(Tcyc)**N < your acceptable failure level. Now the problem becomes one of practicalities: what is p(t) ? Very few manufacturers give it - not even Xilinx for the Virtex & Virtex-E. Given this lack of information I use a rule of thumb culled from the ASIC world. De-rate the Tco of the domain crossing FFs by some multiple, say 6, of the unrouted delay. Then set up constraints like this: TIMESPEC TSSync = FROM FFS(FF1) TO FFS(*) TCyc - 5*Tco; If it won't route to this with FF1 fanning out to many FFs then its time for a double level synchoniser. If anybody can suggest a better practical rule I'd really love to hear it.Article: 29677
Peter Alfke wrote: > > My detailed answers are below. > But first I want to agree with Jim, that there is a difference between the time > delay until the flip-flop has stabilized, and the exact moment when it makes a > change. > The second flip-flop will only go metastable if the first flip-flop's delay plus > routing exactly ( down to the picosecond !) hits the second flip-flops > funny-bone metastability point. > Otherwise the second flip-flop will reflect the right or wrong info coming from > the first. > In other words: You might transfer wrong data, but it is borderline impossible > to transfer the act of going metastable. <snip interesting stuff on Metastable Devices > > When I measured it with random input times ( incoherent clock and data ) I > counted the times metastability exceeded a certain value. I think you can > calculate the width of the input window from that. It is extremely narrow. > Perhaps even femtoseconds. let me know once you figured it out. I'm in a hurry > right know. The 'incoherent' clock/data approach I always feel uneasy about - just HOW inchoerent are they, and in the real world they may not be. Plus, the 'hit rate' decreases with improving process, as you have observed. I have thought of a way to both measure this, and stimulate metastable outputs more directly, and in a directly measurable way ( Physical ) Technique : Construct a coarse delay line in Logic Construct a fine delay, by a sliding physical contact on a stripline, ideally slid under vernier control. From my memory of cables of ~200m/us that maps down to 200mm/ns, or ~5pS/mm, so you can probably control / reproduce to around 50 femtoseconds, with a low cost test bench. This will give a quick method to track both the window, and how it varies with Temperature, and maybe even give enough control to see if you can hit the jackpot of 2nd 'flip-flops funny-bone metastability point.' Perhaps the next generation of FPGA Eval PCBS could have a clock-vernier delay strip-line along one edge :-) -jgArticle: 29678
"Timothy R. Sloper" <trs@mpinet.net> wrote in message
news:3lxo6.44388$nL5.2679174@news3.aus1.giganews.com...
> I'm an FAE for a distributor of Actel. As Philip stated the devices are
OTP.
> There are no inherent problems with the SX/SXA families but if you want to
> be successful on the first pass (this applies to any vendor/technology)
> budget time for proper simulation.
>
> Tim
Tim,
Simulation with OTP devices is even more important than with SRAM
based, reprogrammable devices. This is especially true of higher density
OTP devices involving BGAs, where success on the first pass is paramount.
To get more IO density, BGAs are required, and this is an anathema to OTP
devices, at least in the "first time around" type of design. I remember
socketing Actel FPGAs many years back, but this is next to impossible with
BGAs and sockets. Reliability decreases as interconnections increase, and
this means you may be chasing interconnection problems instead of
functiional problems. I'll be glad when Actel gets the Gatefield line
working.
Good luck to you in your FAE role.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL 32765
Article: 29679I'm not as concerned with the second flop going metastable, as I am with making sure multiple FF's in the state machine see the same value. If the first FF went metastable and takes some time to recover, you can end up with a situation where, depending on relative prop delays, the FF's in the state machine see different levels even though neither goes metastable. Again this depends heavily on your clock period. My contention is that with a single FF feeding a state machine, you are likely to be using a global period constraint, so the routing delay plus the requisite LUT delay ahead of the state machine FFs could be using up most or all of your available clock cycle leaving very little time for metastability recovery. Unless you are floorplanning your sync FF **AND** the part of the state machine affected by the signal or you provide a timing constraint for the synchronized signal path that leaves a large enough margin, you can get yourself into trouble easily. Rick Filipkiewicz wrote: > > "S. Ramirez" wrote: > > > >Ray, > > Sorry for not responding to you sooner. I see that some others have > > responded. I was out in my garage doing a fiberglass layup, and once I > > start it, I cannot walk away until it is finished! > > I'm not sure if we are talking about the same thing, so let me > > elaborate. > > The first flip flop, FF1, I am sure that everyone agrees it will meta > > when used as a synchronizing flip flop. There is a certain probability, p1, > > for a particular FF1 to meta if the input signal changes within the > > setup/hold time violation window. There is another probability, p2, of the > > time that FF1 spends in meta. As that time increases, p2 decreases. These > > two probabilities multiply and give the final probability in a simplisitic > > form. If meta exists when FF2 samples FF1's output, then it will also have > > a probability of meta. Usually the clock cycle time of the two flip flops > > is much greater than the time for p2 to be significant, because this cycle > > time is usually dealing with prop delays that affect register to register > > performance. But as well know, a long cycle time does not guarantee that > > FF2 will not see meta. > > I claim that one can make the state machine flip flops the FF2s. As > > long as they don't see meta at their setup-hold time window, they will > > perform as intended. With the probability of meta being in the range of > > years, decades, centuries, this is accepted as practice. If one inserts FF2 > > between FF1 and the state machine flip flops, then FF2 becomes subject to > > that meta. It will in turn meta in a hundred years and introduce its own > > small probability (p1*p2) of affecting the state machine's flip flops. In > > other words, inserting FF2 only decreases the probability of causing a > > problem at the state machine, because the probabilities multiply > > (p1*p2*p1*p2). But I claim that multiple flip flops in a state machine can > > serve as FF2s and work correctly as long as one knows that they will meta > > some time in the distant future (p1*p2). Introducing FF2 between FF1 and > > the state machine has the disadvantage of adding another cycle of delay > > along with decreasing the probability of the flip flops acting as flop > > flops. > > Usually in a state machine, there are multiple flip flops that will get > > affected by this low probability of meta. There are different ways of > > designing state machines, but I really don't know how to design a state > > machine where only one flip flop will be affected, or at least I don't > > design state machines that way. I usually use one-hot encoding, but this > > doesn't guarantee that only one flip flop will be affected. Along with the > > state encoding bits, there are state output bits that are a function of the > > present state and the inputs, meta included. My state output bits are not > > the state encoding bits, so there are multiple flip flops there seeing the > > low probability of meta. > > I have seen others use FF1 and FF2, but I always questioned why they > > used it. We never really came into an agreement that either I was wrong or > > they were wrong. If I am wrong, then I am capable of learning things. But > > my theories come from two major defense contractors that did some work in > > this area and standardized their design methodologies using the state > > machine flip flops as FF2s. Their design handbook included what I said > > above as well as other procedures. An example of one of these procedures > > is if one is building a nuclear device that is controlled by an electronic > > circuit, then everything needs to be synchronous, with the exception of a > > very few and heavily studied signals. On the other hand, if you are Saddam > > Hussein working on an asynchronous nuclear device and the U.N. inspectors > > are scheduled to see you in a week, and you don't have time to convert it to > > a synchronous design, then you take your chances, run BIST and test it now! > > Simon Ramirez, Consultant > > Synchronous Design, Inc. > > Oviedo, FL USA > > I agree basically with Simon. What we have for an FF whose input has change has > violated the su/hld spec is a probability distribution p(t) which give the > probability that the output will be in a legal state at time t after the clock > edge. So the calculation is: find the value of t, call it Tok for which this > probablility is within you acceptable limits. If Tok + routing time + next FF > setup time is < the clock period then Simon's argument holds. If not then you > need another FF. The worst case is where the device is sufficiently slow that > even with a 0 routing time this sum cannot be met. You are then really into > stats and need a chain of FFs. If Tcyc is the clock period you then need N FFs > so that p(Tcyc)**N < your acceptable failure level. > > Now the problem becomes one of practicalities: what is p(t) ? Very few > manufacturers give it - not even Xilinx for the Virtex & Virtex-E. Given this > lack of information I use a rule of thumb culled from the ASIC world. De-rate > the Tco of the domain crossing FFs by some multiple, say 6, of the unrouted > delay. Then set up constraints like this: > > TIMESPEC TSSync = FROM FFS(FF1) TO FFS(*) TCyc - 5*Tco; > > If it won't route to this with FF1 fanning out to many FFs then its time for a > double level synchoniser. > > If anybody can suggest a better practical rule I'd really love to hear it. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 29680
Jim Granville wrote: > The 'incoherent' clock/data approach I always feel uneasy about > - just HOW inchoerent are they, and in the real world they may not be. > Plus, the 'hit rate' decreases with improving process, as you have > observed. > > I have thought of a way to both measure this, and stimulate metastable > outputs > more directly, and in a directly measurable way ( Physical ) > > Technique : > Construct a coarse delay line in Logic > Construct a fine delay, by a sliding physical contact on a stripline, > ideally slid under vernier control. > > Been there, done that 20 years ago at AMD! > We bought a thing called a trombone, which was just that, an adjustable delay line. > Never got any meaningful results. And that was with bipolar circuits, notorious for > their bad metastability behavior. > So, I am a burnt child. > If others want to try, be my guest, and, please, keep me informed. > I'll stick with two external crystal oscillators with uncorrelated frequencies, > then use the fine phase adjustment in Virtex-II ( 50 ps granularity) to search for > different MTBFs. > > Peter AlfkeArticle: 29681
Rick Filipkiewicz wrote: > > > I agree basically with Simon. What we have for an FF whose input has change has > violated the su/hld spec is a probability distribution p(t) which give the > probability that the output will be in a legal state at time t after the clock > edge. I have a problem with this "legal state" expression. Aside from the crazy oscillations in bipolar circuits, the output is always at a legal state. Even at an acceptable state, since by definition either a 0 or a 1 is equally acceptable when you are right at the edge. The bad thing with a metastable flip-flop is not its logic state, but the fact that it will ( might ) change this state at a time that you have no control over, strictly statistically determined. That's what you have to fight: timing, not right or wrong levels. There is no right or wrong... Peter AlfkeArticle: 29682
It should be possible to tickle the metastability point with a PLL setup too. I had a convenient board a while ago so I tried it. It didn't work. The PLL I had shifted too fast. It bounced from one stable case to the other. Rock solid. I was using one of the standard all-included clock buffer PLL chips. The chip I had was designed to track spread-spectrum clocks so it wasn't what I wanted. (That's a hack for EMI.) It might be possible to make the right setup with a chip that needs external filter components. -- These are my opinions, not necessarily my employeers. I hate spam.Article: 29683
This is really tricky stuff. That's why I like the randomized approach. It gave very repeatable results years ago. Let's see what Virtex-II gives me later this month. We now have an evaluation board ready with Virtex-II ( the littlest XC2V40 ) Building hundreds of boards to give to our FAEs... Peter Alfke, Xilinx Applications ( will be in Europe, this coming week only ) ================ Hal Murray wrote: > It should be possible to tickle the metastability point with a > PLL setup too. > > I had a convenient board a while ago so I tried it. It didn't > work. The PLL I had shifted too fast. It bounced from one > stable case to the other. Rock solid. > > I was using one of the standard all-included clock buffer PLL > chips. The chip I had was designed to track spread-spectrum > clocks so it wasn't what I wanted. (That's a hack for EMI.) > > It might be possible to make the right setup with a chip that > needs external filter components. > > -- > These are my opinions, not necessarily my employeers. I hate spam.Article: 29684
Joel, I am very sorry about your mishap, and I have inserted my comments in the appropriate places in your story. The gist is: Virtex parts do check for CRC errors, but not for formatting errors. And you sent a legitimately CRC-protected file, just the wrong format... Horrendous amount of internal contention. Joel Kolstad wrote: > We have some PCI cards at work that we recently upgraded -- for both price > and performance reasons -- to use Xilinx XCV600E parts instead of the XCV400 > parts that the old board used. We've found out the hard way that Very Bad > Things happen if you attempt to load the old bitstream for the XCV400 onto > the XCV600E board. In particular: > > -- <snip> > > Now what I want to know is... I had always thought that there was some CRC > checking in the FPGA bitstream files, and that you could pretty much feed > the FPGA random gibberish and be very unlikely to actually get the thing to > accept the bitstream Correct. If there were a CRC error, the part would recognize this. But there was no CRC error... > and go through power-on initialization. No, no. power-on initialization is done much earlier, right after you applied Vcc. This has nothing to do with CCLK. The parts use their own internal oscillator for that purpose. > In fact, we're > manually bit-banging the CClk line on the FPGA (we're using serial slave > mode), so there aren't even enough clock pulses provided to the 600E to make > it think it should even _consider_ going through power-on initiailization, see above. It has done this sucessfully long before. > > since the 600E requires about two hundred thousand extra bits (and CClks) > than what the 400 file would provide it with (we stop generating CClk when > we're out of configuration data bits). > > With our current setup it's difficult to probe around on the board and try > to figure out exactly _when_ the overcurrent condition starts. Loading the > 400 file takes a couple of seconds, and the 145W PC will power down within a > couple of seconds after that. My suspicion is that the overcurrent > condition has already started long before we're gotten anywhere near to > finishing the transmission of the 400's bitstream. Yes. The internal logic becomes active as you feed in the data. ( I may stand corrected here. I carry too much XC4000 bagage in my head, and I am at home, no access to other experts. But Austin can jump in, while I am gone for the coming week. Seminars in Europe) > > So... does anybody have any experience with this? The possibility that > feeding a 600E a 400 bitstream causes it to draw massive currents seems > awfully remote to me. No, it's ugly, but not surprising. The part considers this a garbage bitstream , but with legitimate CRC. I know this is not ideal, but that's the way it is. > The LT1575/dual FET power supply can put out 2A all > day long (this was its design goal -- we're dissipating 1.5V*2A=3W or > 1.5W/FET in this case), I would wager it can put out 4A for many minutes, > and to physically blow up both FETs I would have to think that it's passing > at least 10A for a little while. Strange, very strange. Not so strange. Consider the very large number of internal nodes, let's say over 50,000. Let's assume that, through nonsense configuration, 10% are driven by contending levels on both sides of the wire. And let's assume a realistic 5 mA per contention: 5000 times 5 mA = 25 A ! This distributed nature of the current also shows why the Virtex part ( most likely ?) survived. The current is more or less evenly spread over the whole die, which is more than a square centimeter in area. I am not making excuses, just describe the phenomenon, which is quite rational, albeit not desirable. Ask Austin whether Virtex-II is protected against this kind of mishap. Peter Alfke, Xilinx Applications (Friday-night emergency services)Article: 29685
I' like to use a CPLD/FPGA (Xilinx) to receive data from the parallel port (EPP-mode) of my PC. Is it a good style to react direct on the edges of the port signals (e. g. adress/data strobes) or would it be better to use a fast PLD-Clock to sample the port and then to evaluate the signals in a clocked logic? MarcArticle: 29686
Marc Reinert <whothehelllikesspam?rei??ne??rt@tu??-h?ar??bu??rg.de> wrote: > I' like to use a CPLD/FPGA (Xilinx) to receive data from the parallel > port (EPP-mode) of my PC. It has been done before. It can fit in a CPLD if your CPLD isn't going to do too much. I think you'll chew about 5-7 FFs for your state machines and 4-8 FFs for synchronizing(mealy, synchronizing, etc). > Is it a good style to react direct on the edges of the port signals (e. > g. adress/data strobes) or would it be better to use a fast PLD-Clock to > sample the port and then to evaluate the signals in a clocked logic? I just started a nice long thread on exactly this subject. I think the unanimous opinion is to use *two* D-flip-flops hooked in series. For the EPP interface, since you have two strobes, you will have two sets of these dual flip-flops to synchronize with. Use a system clock to synchronize your incoming nAddressActive and nAddress Strobe through the dual flip-flops(one set of FFs per strobe); it helps a lot to use this same clock for your statemachine, so do that if possible. My design had one statemachine (with two states I think) to recognize the four-phase portion of the EPP interface, and then other statemachines to act on the data. Good luck! VR. (the above e-mail address is invalid).Article: 29687
Hi friends, Is it possible to convert a guide file (with a .ncd extension, used by the place and route tool) to be converted to another device of the same family ? Warm regards ramaArticle: 29688
Muzaffer Kal wrote: > > On 04 Mar 2001 00:25:08 +0100, Magnus Homann > <d0asta@mis.dtek.chalmers.se> wrote: > > >Ray Andraka <ray@andraka.com> writes: > > > >[Simons wisdom deleted] > > > >> Simon failed to point out that using the state machine as the second > >> flip flop should only be done if the possibly metastable signal > >> affects only one flip-flop in the state machine. If if affects more > >> than one flip-flop, there is a potential for a metastable event to > >> be detected as different levels by the multiple flip-flops that > >> depend on its condition. Simon, I'm sure this was your intention, I > >> just wanted to make sure your short response didn't mislead anyone. > > > >Really? Hmm, the idea is that FF1 would settle within the cycle > >time. Now, if it doesn't, does it really matter if one or several of > >the statemachines FFs wil go into metastability? > > > >The idea is that the cycle time will be enough for all metastability > >to vanish. If it hasn't, is there anything you can do to save your FSM > >from running amok? > > > >Your advice might be god, but probably mostly due to the fact that having > >only one FF after FF1 usaully reduces the routing delay, and > >hence increases the available settling time (iff you have the same > >cycle time in both cases). > > > >Comments invited. > > > >Homann > > I think that "two FFs" was just a rule of thumb which ensured a > certain MTBF under certain conditions (which are probably not valid in > < .25u processes anymore). You can further reduce the probability of > metastability by adding more FFs. The metastability never vanishes > completely. There is always a non-zero probability that the metastable > event will pass through all the FFs. It can be made arbitrarily small > though. That's where the MTBF comes from. > > Muzaffer Homann and Muzaffer, The factor that settles metastability is not FFs, but rather time. The need for the second FF is a function of the speed of the clock. As Homann says, using the second FF separates the metastability settling time from the time used for routing and logic prop delay. So you get the entire clock cycle for settling. If your clock is slow enough, you can put the logic after the first FF and not worry about it. The slack time in the clock cycle will allow a metastable state to settle. The need to add a second FF comes only with faster clocks. If the clock speed is trully fast, then you may need to add a third FF just to get the extra settling time of a second clock cycle. But everything I have read about the current process technology (mainly Xilinx) indicates that using two FFs (one clock cycle) works well up to a couple of hundred MHz. But once you get past a hundred MHz, you might want to get the data on your part and do the calculations yourself. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 29689
Austin Lesea wrote: > > Rick, > > The kick is not intended to be in parallel. There is no reason that this can not be used > with a switcher, in fact, that is even better from an efficiency point of view: the micro > power comparator/reference (is in the tiny package I gave dimensions for) would be used to > hold off the switcher for the 2.5 Vdc until the cap ahead of it was charged up. Most > switchers can be set to integrate the current limiting so they can supply a transient of > many times what they can supply continuously. > > The LDO is bigger than what I said, but I was assuming it was already there. > > You make an excellent point about the smaller packages: they can't dissipate much power at > all without glowing in the dark. I know people want to use them, but cs144, fg256 style > packages are not really good at getting rid of the heat. One should always run thru the > power estimator excrcise -- especially in these thermally challenged packages! > > Austin Thanks Austin, this makes it much clearer. Holding the regulator in standby mode and using a large input capacitor is only useful if the power source to the regulator is not capable of supplying the full current you need at startup. In my application, I expect that the power source to the board will have ample umpf (that's a technical term I learned in school :). The limiting factor is the on-board regulator that provides power to all of the FPGAs. I have a very limited amount of space on the board for this regulator. I also feel that I need to limit the current to a safe level to prevent the regulator from overheating in case of a failure on the board. So providing 2.5 Amps of surge capacity is not easy to do without compromising one of these requirements. I am using a integrated controller for the regulator. It has an external series sense resistor to limit current. With a value of 0.030 ohms, it will require a large cap to hold off the current limit while the FPGAs are starting up. This again uses more space. I will have to take a look at the regulator data sheet to see what can be done. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 29690
Austin Lesea wrote: > > Rick, > > I think you may have misunderstood my comment. The original thinking was 'Virtex thinking' > for larger parts -- which breaks down completely for smaller parts! I agree with you. > > 1 watt for 4 2S15's split between all of the IO's at 3.3 Vdc, and the cores at 2.5 Vdc is a > real challenge, I admit. If in the steady state, 1 watt is plenty to operate the four > parts, that leaves us with the startup issue. > > I admit that for -40C, worst case is 2 amperes (right now, as we don't have enough 2S15 > silicon to characterize the -40C number, so we have to go with what we know from larger > parts -- it could be less). The thought of having to supply 8 amperes to start them up at > 2.5 Vdc is a little (lot) daunting. > > Is there any way to use a larger part, rather than four separate smaller parts? I suppose > that isn't a very smart question, as you probably already optimized your system > architecture, but I have to ask. Actually, I am glad you asked. Because this is a question you can answer for me. My design uses the FPGAs as configurable interfaces for IO modules. My system design allows for runtime identification of the modules and configuration of the FPGAs to match. This works a little like Plug and Play (PnP). I would love to put all of these designs into a single part to save board space, chip cost, power and save on procurement and assembly cost. But to make my system work, I will need supported, partial reconfiguration. I would need to load a portion of the chip with a main (static) function, and four modules to match the IO connected to the board. I know that JBITs exists and that it can help me with the task. But I have not heard anyone say that it is really the solution to this problem. How close is Xilinx to providing true partial reconfiguration as part of the main development software? > Ultimately, one could design an 8 amp peak switcher than would deliver the 8 amps for at > least 1 ms to get them all started. If you could tolerate a 500 mV dip in the 3.3 volts > running the DC to DC switcher, the input capacitor has to be I*dt/dv, or 8 * .001/.5 = 4,000 > uF. That isn't all that obscene, as 4,700 uF at 6.3 wv is still a pretty small component. > I would go with 10,000uF as at -40 C the capacitor (if it is the proper one engineered for > -55C in the data sheet) will have 40% of its room temperature value. Do not use a standard > -40C capacitor, as they have 0 capacitance at -40C (really, I measure them all of the time > to prove this to the disbelievers!). > > The capacitor specifications refer to damage, not operation, and since they are electrolytes > (i.e. there is water in there), it just makes sense that at really low temperatures they are > not a capacitor any more. > > I am not recommending staging, or sequencing, but rather hitting them all at the same time. > Any attempt to mess with the program pin is doomed to failure in Virtex and Spartan II. As > I have said, the chip doesn't even know its name yet at 0.7 to 1 V where the pop is needed. > Any attempt to slow down the ramp is doomed to fail as well. The 4K parts had decreasing > current with increasing ramp, and some dependency of current on the pins, but not > Virtex/Spartan II. > > Ultimately, there may be a better way to solve the problem, as you state, as there are > always alternatives. > > By the way, the board is almost built. > > Austin -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 29691
Eric Smith wrote: > > I'm trying to use WebPACK ISE to build a microprocessor core model > using an XC2S200. I can't get the data path to compile; the synthesizer > exits with the message: > > Done: failed with exit code: 0002. Just a guess, 'cause I'm not sure...but does the Webpack stuff support that particular part? -aArticle: 29692
On 03 Mar 2001 15:44:07 -0800, Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote: >Peter Alfke <palfke@earthlink.net> writes: >> The gist is: >> Virtex parts do check for CRC errors, but not for formatting errors. And you >> sent a legitimately CRC-protected file, just the wrong format... Horrendous >> amount of internal contention. >[...] >> Correct. If there were a CRC error, the part would recognize this. But there >> was no CRC error... > >Is there some reason why the part doesn't ALSO recognize that the bitstream >is too short? I wouldn't think it would expect the CRC until it had filled >all of the RAM cells. > Anything to do with partial reconfiguration maybe? Like, is it possible to generate a _valid_ short bitstream to reprogram part of the device but leaving the remainder unchanged? - BrianArticle: 29693
Peter Alfke schrieb: > > Jim Granville wrote: > > > The 'incoherent' clock/data approach I always feel uneasy about > > - just HOW inchoerent are they, and in the real world they may not be. > > Plus, the 'hit rate' decreases with improving process, as you have > > observed. > > > > I have thought of a way to both measure this, and stimulate metastable > > outputs > > more directly, and in a directly measurable way ( Physical ) > > > > Technique : > > Construct a coarse delay line in Logic > > Construct a fine delay, by a sliding physical contact on a stripline, > > ideally slid under vernier control. Sounds a little bit ancient ;-)) Why not using a PLL and doing a phase modulation?? This would give VERY reliable and repeatable results. And its free of mechanical wearout. -- MFG FalkArticle: 29694
I wrote: > I'm trying to use WebPACK ISE to build a microprocessor core model > using an XC2S200. I can't get the data path to compile; the synthesizer > exits with the message: > > Done: failed with exit code: 0002. Andy Peters <"apeters <"@> noao [.] edu> writes: > Just a guess, 'cause I'm not sure...but does the Webpack stuff support > that particular part? Yes. That's the only part I have an eval board for, so it's the only part I've targetted. The simple LED-flasher design worked fine.Article: 29695
On Mon, 05 Mar 2001 17:31:38 +0000, Brian Drummond <brian@shapes.demon.co.uk> wrote: >On 03 Mar 2001 15:44:07 -0800, Eric Smith ><eric-no-spam-for-me@brouhaha.com> wrote: > >>Peter Alfke <palfke@earthlink.net> writes: >>> The gist is: >>> Virtex parts do check for CRC errors, but not for formatting errors. And you >>> sent a legitimately CRC-protected file, just the wrong format... Horrendous >>> amount of internal contention. >>[...] >>> Correct. If there were a CRC error, the part would recognize this. But there >>> was no CRC error... >> >>Is there some reason why the part doesn't ALSO recognize that the bitstream >>is too short? I wouldn't think it would expect the CRC until it had filled >>all of the RAM cells. >> >Anything to do with partial reconfiguration maybe? >Like, is it possible to generate a _valid_ short bitstream to reprogram >part of the device but leaving the remainder unchanged? Perhaps you've just stepped on another reason the tools don't support partial reconfiguration? Two _valid_ short bitstreams may create many drivers on the same wire. ---- KeithArticle: 29696
I wrote: > Is there some reason why the part doesn't ALSO recognize that the bitstream > is too short? I wouldn't think it would expect the CRC until it had filled > all of the RAM cells. Brian Drummond <brian@shapes.demon.co.uk> writes: > Anything to do with partial reconfiguration maybe? > Like, is it possible to generate a _valid_ short bitstream to reprogram > part of the device but leaving the remainder unchanged? Having looked over the XAPP 176 appnote on configuration and readback of the Spartan II over the weekend, I now have a better appreciation for how the config process works. I think your hypothesis is correct. I guess the thing that still surprises me is that each size of FPGA needs a different frame size in the bitstream (table 4 on page 15, XC2S200 not specified), so the parts should have been able to detect the wrong frame size, even if they can't detect the wrong total image size.Article: 29697
In article <NLto6.31387$68.5690704@typhoon.tampabay.rr.com>, sramirez@deletethis.cfl.rr.com (S. Ramirez) wrote: > "Embedded Head" <chilln@gte.net> wrote in message > news:OKco6.3179$sC4.237266@paloalto-snr1.gtei.net... > > Mixed Signal Engineer > > Will work as a member of our Test Engineering team to design, test and > > troubleshoot our next generation of test equipment. We are a rapidly > > expanding, progressive company with excellent benefits and friendly > > atmosphere. > > Qualifications > > BSEE (required) > > 2+ years experience in C/C++ and VHDL or FPGA (required) > > 2+ years experience with analog hardware (required) > > Schematic design software experience (required) > > DSP experience preferred > > Send or Fax resume to: > > "Mixed Signal Engineer Web" > > 3629 Vista Mercado > > Camarillo, CA 93012 > > FAX: (805) 383-1838 > > EMAIL: humanresources@a-m-c.com > > > > Your BULLET_P.gif is quite enlightening. That's why they don't want no smart-arse consultants :-))) Now, back to learning the company song... -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 29698
In case Austin doesn't want to jump in here, I can say with complete positivity that Virtex-II is protected against this kind of mishap. Virtex-II has an extra configuration register called the ID register. Each device in the family has a different ID, and before any "real" configuration data is loaded, this ID register is loaded, and checked against an internal constant. If it passes, you know for certain you're loading the right kind of bitstream into the right part. If it fails, INIT will go low and configuration will stop. Mike Xilinx ApplicationsArticle: 29699
Can anyone please post a VHDL implementation of a ROM-based FSM implementation,or point me to links on the web where I might get some help. I Have the Block Diagram, but I am having trouble realizing that in VHDL. Thanks in Advance ----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web ----- http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups NewsOne.Net prohibits users from posting spam. If this or other posts made through NewsOne.Net violate posting guidelines, email abuse@newsone.net
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