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
Are you using time constraints and checking the timing analysis? If your timing analysis is passing, then the design should work over the entire temperature range. At 50 MHz, even a full chip is not normally going to get so hot that cooling is needed to make it operate, unless your IOs are overloaded. Rainer Storn wrote: > > Hi all, > > I want to make myself knowledgeable in FPGA-Design > with Xilinx-Chips. We have found that for small designs > everything is pretty straightforward. However, for > high clock frequencies (50MHz) and more complex designs > clock delay and skew as well as the clock signal quality > which enters the chip seem to have crucial importance. > In fact even if the VHDL-code is correct, proven by > simulation, the actual implementation sometimes doesn't > work (or does so only with cooling). Can anyone name me > some good references where I can get more insight into > the pits and trapfalls of FPGA-design ? > > Regards > > Rainer -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 30001
Your friend is not a very experienced Xilinx designer. I routinely do Xilinx designs that are 80% or more utilized at clock rates that are quite a bit higher. The 40KXV parts are all capable of over 100MHz operation, but you'll have to be careful to do you design such that it doesn't have many layers of combinatorial logic between registers (ie, the signal should only pass through one or two LUTs between flip-flops). For higher clocks you may also find you need to do some floorplanning, but not for a 43 MHz clock. The XC40150XV has sufficient routing resources for most designs. By clock skew, I presume you are referring to the input delay to register. You should register incoming signals in the IOBs wherever possible for two reasons: 1) by doing so, you get the minimum delay from the pin to the first register, and 2) the external timing gets decoupled from your design's internal layout and routing solution so re-routes don't affect your system. This also helps avoid the so called pin locking problem, as the pin locations are not as critical. I don't have the data sheet in front of me at the moment, I think 2ns setup is pretty close to what you get using the IOB registers in the 4KXV. Rainer Storn wrote: > > Hi All, > > I am new to the FPGA design business so I would like > to verify an information that was given to me by a > fellow engineer. He said that once the packing > density of Xilinx FPGAs exceeds 30% I may run into > timing problems because of the delay variations that > inevitably arise due to difficult routing. In fact we experienced > these problems. It seems that certain clock skew constraints > can never be met. (2ns, 43MHz clock rate, XC40150XV). > > Is this a known problem ? Is there anything we can do > about this ? > > Regards > > Rainer -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 30002
> I want to make myself knowledgeable in FPGA-Design > with Xilinx-Chips. We have found that for small designs > everything is pretty straightforward. However, for > high clock frequencies (50MHz) and more complex designs > clock delay and skew as well as the clock signal quality > which enters the chip seem to have crucial importance. > In fact even if the VHDL-code is correct, proven by > simulation, the actual implementation sometimes doesn't > work (or does so only with cooling). Can anyone name me > some good references where I can get more insight into > the pits and trapfalls of FPGA-design ? I don't know of any book that I would consider useful for the level of design you are talking about. The Xilinx data sheets are a great place to start. Understanding the architecture of the CLBs and the chip is critical in making informed decision on how to design. Knowing the architecture will help you design to minimize logic, and take advantage of the architecture. You can not use an ASIC mentality when designing FPGAs, though the vendors like to tell you you can. I believe there are application notes for HDLs that suggest ways of using HDLs to generate the logic you want, both FPGA vendor specific, and tool vendor specific. Learn how to use TIMESPECs, which are documented in the Xilinx tool documentation, and there is also, I believe, a Xilinx tutorial on this. One thing to keep in mind for FPGAs, is to keep the logic between flops minimized to make your clock frequency. Learning how to use the tools to see how your design is being implemented and where your timing problems are, is very useful. If you are using Synplicity, it has an RTL viewer available, and this is an excellent tool. I would suggest that slogging through the problems of making your design make timing, learning how to use the tools well, and asking questions here, is probably a far better learning experience than any book can give you. There are many levels you can design to, everything from pushing the button to instantiating your gates, mapping the logic, and doing floorplanning...and it depends on what you are trying to do that dictates how many of these steps you need to take to implement your design successfully.Article: 30003
OK ... Situation is probably litle bit more clear. I need probably "matched filter". Do you know some good reference on this subject? I need the suitable starting point for my next work. Thanks, Michal "Ray Andraka" <ray@andraka.com> píse v diskusním príspevku news:3AB75FA8.E8915255@andraka.com... > DIfferent animal. That was a bit pattern correlator. He needs a matched filter > in this case. > > Kolja Sulimma wrote: > > > > Juri Kanevski wrote: > > > > > FPGA can implement the correlation with the sampling frequency ca 100 > > > MHz. > > > > There was a 16 channel correlator published years ago that achieved 250 MHz in > > XC3192A > > I admit it was a 100% FPGA-Editor design - I guess those people would have kille to > > get their > > hands on JBits - but with Virtex-E or Virtex-II higher frequency should be possible. > > > > Kolja > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.comArticle: 30004
One would think so, but it is not there. Simon Bacon wrote: > > I guess the logic should be available in a simulation library. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 30005
I do not understand well now what is your final suggestion. "matched filtering" or something else and better? Michal "Ray Andraka" <ray@andraka.com> píse v diskusním príspevku news:3AB760AC.122D2B51@andraka.com... > Yes. As well as possibly using fractionally placed parallel filters for > fractional range bin resolution. Reading more of the posts this morning it is > evident that your transmit pulse is not well controlled, which makes it much > tougher...Matched filtering isn't going to work that well. If you could nail > down either the pulse width or the rise/fall time or both you'd have better > success. > > > > Kolja Sulimma wrote: > > > > > The FPGA can handle 5-10 ns range gates fairly easily. Getting much shorter > > > than that will require more specialized tricks or some high speed external > > > logic. > > > > You mean like connecting the signal to multiple pins and then having IFFs with four > > clock > > phases? > > > > Kolja > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.comArticle: 30006
"Rick Collins" <spamgoeshere4@yahoo.com> wrote in message news:3AB708AD.31959698@yahoo.com... > Peter Alfke wrote: > > Rick Collins wrote: > > > So if the XC2V40 and XC2V1000 parts were available > > > now and I had some reason to believe that I could get them at reasonable > > > prices by the point of production (like a quote) I would love to design > > > them in. > > > > Consider them available, and - in your time frame- the XC2V3000 also. > > I will contact distribution. But I have not had much success in the past > getting any real data. Normally the best they can tell you is price and > delivery, and normally not even that on such new parts. Try NuHorizons. We placed an order for XC2V1000-4FG456CES on 3/9. Yesterday they confirmed a factory ship date of 4/13. I think we can trust that atleast XC2V40 and XC2V1000 are available as engineering samples. Regards, Erik Widding. -- Birger Engineering, Inc. -------------------------------- 781.481.9233 38 Montvale Ave #260; Stoneham, MA 02180 ------- http://www.birger.comArticle: 30007
All, As the chips scale, driving a 1" long wire became slower and slower (relative to the whole picture). Recently we removed TBUF's and replaced them with mux's in a few thousands of designs, and without replacing and rerouting, the designs were all faster. They also took up more area (the mux's). By removing TBUF's we gain that area back (TBUF's have to be huge to drive the long wires), so that now are still more area efficient, and higher speed than before. With PAR, the designs are all "better" than before. As always, removing something is always a tough decision, and we made sure we had a way of succeeding before we asked everyone to give them up forever (which may happen in the future). They were great while they lasted, Austin TBUF: RIP 200? Juri Kanevski wrote: > Neil Franklin wrote: > > > > In the earlier Xilinx chips (3000, 4000, 5200) there is always 2 > > TBUFs per CLB of 2 LUT+FF. And both TBUF lines can be read. > > > > In Virtex and Spartan-II it is down to 2 TBUFS for the 4 LUT+FF of an > > CLB, so only one slice can be routed to them, and even only 1 line for > > reading back from TBUF lines. > > > > In Virtex-II there is even only 2 TBUFs for 8 LUT+FF per CLB. Which > > makes even connecting the output of the 4-wide 2 slices of an single > > carry chain to an bus impossible. The data sheet does not give the > > amount of readbacks. > > > > From this I get the impression, that Xilinx regards TBUF buses as going > > out of fashion. After all, the TBUFs cost in chip space is next to nothing > > relative to them many PIPs (about 900 per CLB in Virtex). > > > > > > So I have a question: What is the Xilinx-suggested replacement for TBUFs? > > Is one supposed to use MUXes implemented in the CLBs? Is there an other > > trick I have not yet stumbled over? > > I think that Xilinx > found a compromise in the space functionality-cost. > For these TBUFs and tristate wires > Xilinx's devices were 2 fold more costly than Altera's ones, I suppose, > because of their heavy technology. > > And therefore the only solution is > to try to do without large multiplexors and shared busses. > The way to do without large shared busses in the chip > is the stable tendency now and in the future > because they do not support the clock frequency increase, > and afford the high switshing energy . > > A.Ser.Article: 30008
Hello - There is a fitter option labelled "User Programmable Grounds" that will help you. When selected, it ties all unused IO pins to ground internally so you don't need to terminate them externally. Regards, ArthurArticle: 30009
Austin Lesea wrote: > > All, > > As the chips scale, driving a 1" long wire became slower and slower (relative to > the whole picture). Recently we removed TBUF's and replaced them with mux's in > a few thousands of designs, and without replacing and rerouting, the designs > were all faster. They also took up more area (the mux's). By removing TBUF's > we gain that area back (TBUF's have to be huge to drive the long wires), so that > now are still more area efficient, and higher speed than before. With PAR, the > designs are all "better" than before. > > As always, removing something is always a tough decision, and we made sure we > had a way of succeeding before we asked everyone to give them up forever (which > may happen in the future). > > They were great while they lasted, > > Austin > > TBUF: RIP 200? When you say that the muxes were added, are you saying that there are "special" muxes available? Or are you referring to the LUTs in the CLBs? I guess I need to read the VII data sheet in detail and learn the architecture. It seems to be the chip to beat these days. -- 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: 30010
Peter Alfke wrote: > BTW, word is that the start-up current on Spartan-II is being improved, and the > current is now kind-of proportional to size (i.e. part number). So the small 15 and > 30 spartan-II devices have a low start-up current. This is a real make or break issue with me. What will it take to get more info on this? Do you have any idea of when this info will be available? Even if I can't get the info today, it will be useful to know when it will be available. I can put off my FPGA decision for awhile, but not without some idea of the schedule. -- 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: 30011
Seems to me that the fine-resolution clock phase shift in Virtex-II could help. You can place and move a clock edge with a resolution of 1/256 of the clock period, or 50 ps, whichever is greater. With a repetitive signal, you might use trial and error. But Ray knows so much more about radar... Peter Alfke ==================================== Ray Andraka wrote: > Yes. As well as possibly using fractionally placed parallel filters for > fractional range bin resolution. Reading more of the posts this morning it is > evident that your transmit pulse is not well controlled, which makes it much > tougher...Matched filtering isn't going to work that well. If you could nail > down either the pulse width or the rise/fall time or both you'd have better > success. > > Kolja Sulimma wrote: > > > > > The FPGA can handle 5-10 ns range gates fairly easily. Getting much shorter > > > than that will require more specialized tricks or some high speed external > > > logic. > > > > You mean like connecting the signal to multiple pins and then having IFFs with four > > clock > > phases? > > > > Kolja > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.comArticle: 30012
Hi, There is no component in the unisim library, as Ray indicated, but the back annotation tools are aware of the component and what it does. If you are really dying to know what is in there, you can manually create an NCD using fpga_editor, and then use NGD2VER or NGD2VHDL to write out a simulation model of it. Eric Ray Andraka wrote: > > One would think so, but it is not there. > > Simon Bacon wrote: > > > > I guess the logic should be available in a simulation library.Article: 30013
As I understand it, Austin is stating that the area that was saved by removing the
TBUFs is now used for extra CLBs
(or reducing the ASIC cost per CLB)
With 90% of the FPGA area beeing in the interconnect (Andre DeHons estimates) I doubt
that you gain much of a CLB
(including its interconnect) from removing a TBUF.
Someone stated in this group that the TBUFs are not really TBUFs anymore internally
but are realized in some other patented manner. Maybe thats the reason. (The TBUFs
worst case timing got MUCH faster with virtex when compared to the carry chain, for
example)
But of course, the longlines get faster when less TBUFs are connected to them
But remember: Marketing argument are often more important that technical aspects.
Because of the huge amount of area
dedicated to routing in an FPGA it is better to waste CLBs than to waste routing and
therefore poorly routable FPGAs
are much more area efficient.then highly routable designs.
But they got bad press for bad routability, and therefore greatly improve routability.
The new trade-off may be more
expensive to manufacture, but its easier to use and less people complain.
But wait: Everybody feels happier if he has a reason to complain so they discounted
the equivalent gate count metric, and now we have a reason to complain again.
CU,
Kolja
Rick Collins wrote:
> Austin Lesea wrote:
> >
> > All,
> >
> > As the chips scale, driving a 1" long wire became slower and slower (relative to
> > the whole picture). Recently we removed TBUF's and replaced them with mux's in
> > a few thousands of designs, and without replacing and rerouting, the designs
> > were all faster. They also took up more area (the mux's). By removing TBUF's
> > we gain that area back (TBUF's have to be huge to drive the long wires), so that
> > now are still more area efficient, and higher speed than before. With PAR, the
> > designs are all "better" than before.
> >
> > As always, removing something is always a tough decision, and we made sure we
> > had a way of succeeding before we asked everyone to give them up forever (which
> > may happen in the future).
> >
> > They were great while they lasted,
> >
> > Austin
> >
> > TBUF: RIP 200?
>
> When you say that the muxes were added, are you saying that there are
> "special" muxes available? Or are you referring to the LUTs in the CLBs?
>
> I guess I need to read the VII data sheet in detail and learn the
> architecture. It seems to be the chip to beat these days.
>
> --
>
> 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 FAX
Article: 30014Hi Rick, Xilinx currently has a 1024-pt 16b (16-bit precision for both I and Q) complex FFT that runs in Virtex and Virtex-E. The design occupies 1930 slices and easliy runs at 100 MHz. The transform time is 41 microseconds. This implementation was a balance between reasonable performance and area ... usual tradeoff. We are doing more FFT work. The FFTs will be ported to the Virtex-II fabric and use the embeded mutlipliers. We will do a port of the current FFTs and will also be releasing a new family of higher performance FFTs later this year. This will include some new transform lengths. When the current 1024-pt FFT is ported to Virtex-II it will occupy approximately 1100 logic slices. If you would like some more details about the FFTs please feel free to contact me best regards Chris Rick Collins wrote: > I am looking at performing real data, fixed point FFTs in an FPGA and I > would like to get some info on the processing time and logic size > required. The input data is 14 bit, 2048 points. A standard optimization > for processing real data is to fold the data into the complex input > array, so that you only process a 1024 point FFT and then unfold the > real data in an extra step. We have a DSP available which can do the > final unfolding step. > > I checked the Altera web site and found info on their megacore function. > For a 1K FFT, they use about 3000 LE's and 10 block rams (EABs). They > claim the max speed is 90 MHz for 57 uS per block. This is only 3x what > I can get from the DSP chip! > > Is the Altera megacore not highly optimized for speed? Are there other > cores available that can process the data at a higher clock rate? The > data is clocked in at 100 MHz burst rate, if it is fully pipelined and > can start another butterfly each 4 clock cycles it should be able to > process the data in 20 uS. Perhaps that is too much to expect since > there are log2(N)/2 passes. I would like to process the block in 20 uS. > At that point the processing time becomes insignificant in the overall > process. Is that too much to expect from a hardware solution without > using a thousand dollar chip? > > -- > > 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 FAX -- Dr Chris Dick Xilinx DSP Group Manager DSP Chief Architect Xilinx Inc 2100 Logic Drive San Jose CA 95124 Phone: 408.879.5377 Fax: 408.626.6440 eFax: 508.355.7668Article: 30015
Michal Kvasnicka wrote: > ... > > Radar pulse can be approximated by trapezoidal (symmetric or asymmetric) > pulse wit the following parameters: > pulse width = 0.5 - 500us (50% amplitude level) > rise time = 20-100ns > fall time = 20-200ns > sample interval = 1 - 10ns > Pulse repetition interval = 1 - 5000us > ... Why is the width (and shape) unknown? Where is the transmitter? Can you sample the outgoing pulses and match them up with the returns? Jerry -- Engineering is the art of making what you want from things you can get. -----------------------------------------------------------------------Article: 30016
OK. That's what I did. Was not as easy as it sounds, because you need to place constraints of the type LOC=RPCILOGIC and so on. Her is the result in cube notation: IRDY TRDY I1 I2 I3 PCI_CE -0--0 : 1 ---1- : 1 0-00- : 1 In other words: PCI_CE <= I2 or (not TRDY and not I3) or (not IRDY and not I1 and not I2); PCI_CE connects to the output clock enable of many pins. Has anybody any suggestions on what this is good for? Kolja Sulimma Eric Crabill wrote: > Hi, > > There is no component in the unisim library, as > Ray indicated, but the back annotation tools are > aware of the component and what it does. If you > are really dying to know what is in there, you > can manually create an NCD using fpga_editor, > and then use NGD2VER or NGD2VHDL to write out > a simulation model of it. > > Eric > > Ray Andraka wrote: > > > > One would think so, but it is not there. > > > > Simon Bacon wrote: > > > > > > I guess the logic should be available in a simulation library.Article: 30017
Anyone know of published RC5 implementations in FPGAs?
Thanks.
-------------------------------------------------------------------------------------
Adam Elbirt
Cryptography and Informations Security Laboratory
Electrical and Computer Engineering Department
Worcester Polytechnic Institute
Worcester, Massachusetts
508-831-5840 Phone
508-831-5491 Fax
"Actually intelligence has far less practical use than you would think."
-- Mensa member to Dilbert
Article: 30018Hi, You may want to double check that, I think it should be: PCI_CE <= I2 or (not TRDY# and not I3) or (not IRDY# and not I1); > Has anybody any suggestions on what this is good for? It may be a useful piece of a PCI 2.2 compliant output flip flop clock enable function... One that meets 66 MHz timing, with no effort required from the user or the router. EricArticle: 30019
On Tue, 20 Mar 2001 14:08:51 GMT, Ray Andraka <ray@andraka.com> wrote: >One would think so, but it is not there. > >Simon Bacon wrote: >> >> I guess the logic should be available in a simulation library. It is basically a function of 5 variables. If you assumed it was a 5-lut, then tada .... 0xf0f0f1f1 This is the truth table with the variable ordering (msb to lsb): PCILOGIC.TRDY PCILOGIC.I3 PCILOGIC.I2 PCILOGIC.I1 PCILOGIC.IRDY I leave it as an exercise for the reader to figure out the gate equivalents. This information was derived by Mark Shand about 2 years ago, by building it and exercising it. At the time Mark did this, the proposed solution of the back annotation method (proposed in another article) gave a different result. The back annotation was patently wrong since the logic function you got was of no use in implementing the output CE required by PCI. Let's hope they have since fixed their simulation models. Philip Freidin Philip Freidin FliptronicsArticle: 30020
Is there a difference between the XS40-005XL+ Prototyping Board with 128 KByte RAM and the XS95-108+ Prototyping Board with 128 KByte SRAM other than the CPLD/FPGA chip? I was thinking of just buying the CPLD board and then extracting the CPLD and replacing it with an FPGA when I needed it and back. Does anyone know of any schematics/plans to make a protoboard? Thanks EArticle: 30021
All Mux's are special :) The replacement was with CLB's (LUT's and special clb logic), which may implement the F5, F6, F7 or even F8 in Virtex II, so they can be very efficient. The fast that you could retarget the synthesis, and use even more powerful structures (e.g. horizontal cascade carry) makes things even faster with less area. The TBUF's occupy a large area in interconnect (metal wires) and buffers, and mux trees to get in and out. There are these strange warts that hang off the CLB and run really slowly now that everything has scaled so well into the ultra deep sub-micron world. Austin Rick Collins wrote: > Austin Lesea wrote: > > > > All, > > > > As the chips scale, driving a 1" long wire became slower and slower (relative to > > the whole picture). Recently we removed TBUF's and replaced them with mux's in > > a few thousands of designs, and without replacing and rerouting, the designs > > were all faster. They also took up more area (the mux's). By removing TBUF's > > we gain that area back (TBUF's have to be huge to drive the long wires), so that > > now are still more area efficient, and higher speed than before. With PAR, the > > designs are all "better" than before. > > > > As always, removing something is always a tough decision, and we made sure we > > had a way of succeeding before we asked everyone to give them up forever (which > > may happen in the future). > > > > They were great while they lasted, > > > > Austin > > > > TBUF: RIP 200? > > When you say that the muxes were added, are you saying that there are > "special" muxes available? Or are you referring to the LUTs in the CLBs? > > I guess I need to read the VII data sheet in detail and learn the > architecture. It seems to be the chip to beat these days. > > -- > > 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: 30022
Eric wrote: > Is there a difference between the XS40-005XL+ Prototyping Board with 128 KByte > RAM and the XS95-108+ Prototyping Board with 128 KByte SRAM other than the > CPLD/FPGA chip? > > I was thinking of just buying the CPLD board and then extracting the CPLD and > replacing it with an FPGA when I needed it and back. The XS40 and XS95 Boards look similar but all the wiring is different, so you cannot replace the CPLD in the XS95 with an FPGA. > > > Does anyone know of any schematics/plans to make a protoboard? We have complete schematics for all our boards in their respective user manuals. You can also find a complete description of how to build a slightly stripped-down version of the XS95 and XS40 Boards in an appendix of the old "Practical Xilinx Designer Lab Book" (if you can find a copy of it since it went out of print). > > > Thanks > E -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 30023
Kolja Sulimma wrote: > Chris Dunlap wrote: > > > You can always look in FPGA editor. Nothing can be left out there. If its > > routed or routable, its there. > > Sure it can be. > Or can you used the mysterious undocumented IRDY/TRDY pins special features of > Spartan-II in FPGA editor? > > Using a dominance in the FPGA market to get an advantage in the PCI-core market > looks at lot like the > Microsoft Internet Explorer case to me. > > CU, > Kolja O.k now this one's sorted on to the next magic PCI question. In the bitgen args list there is a set of global clock parameters called Gclkdel0-3. I've been assuming/wondering for some time if this is to do with meeting PCI66MHz setup timing. The give-away is the comment line: ``You should not use this option unless instructed by Xilinx'' Any ideas ?Article: 30024
The problem with the CLB muxes is that they don't match the pitch of the carry chain, so If I have a set of counters for instance that I want to address to read onto a common bus, it is a royal pain in the patoot without the Tbufs. It's a good thing there is more routing in these chips! For example, in Virtex, if I want to use the F6 mux, which would be the one I need to mux between two slices, I need to use the F5 muxes to feed the F6. Since the F5 selects between the F and G LUTs, this structure is broken for connecting to carry chain logic. Austin Lesea wrote: > > All Mux's are special :) > > The replacement was with CLB's (LUT's and special clb logic), which may implement the > F5, F6, F7 or even F8 in Virtex II, so they can be very efficient. > > The fast that you could retarget the synthesis, and use even more powerful structures > (e.g. horizontal cascade carry) makes things even faster with less area. > > The TBUF's occupy a large area in interconnect (metal wires) and buffers, and mux > trees to get in and out. There are these strange warts that hang off the CLB and run > really slowly now that everything has scaled so well into the ultra deep sub-micron > world. > > Austin > > Rick Collins wrote: > > > Austin Lesea wrote: > > > > > > All, > > > > > > As the chips scale, driving a 1" long wire became slower and slower (relative to > > > the whole picture). Recently we removed TBUF's and replaced them with mux's in > > > a few thousands of designs, and without replacing and rerouting, the designs > > > were all faster. They also took up more area (the mux's). By removing TBUF's > > > we gain that area back (TBUF's have to be huge to drive the long wires), so that > > > now are still more area efficient, and higher speed than before. With PAR, the > > > designs are all "better" than before. > > > > > > As always, removing something is always a tough decision, and we made sure we > > > had a way of succeeding before we asked everyone to give them up forever (which > > > may happen in the future). > > > > > > They were great while they lasted, > > > > > > Austin > > > > > > TBUF: RIP 200? > > > > When you say that the muxes were added, are you saying that there are > > "special" muxes available? Or are you referring to the LUTs in the CLBs? > > > > I guess I need to read the VII data sheet in detail and learn the > > architecture. It seems to be the chip to beat these days. > > > > -- > > > > 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 FAX -- -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
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