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
5 on an euro card 160 x 100 mm 10 cards in a 19 inch rack. For my brute force key cracker. If not Xilinx then any other manufacturer if it comes with free tools. There is a market here, I am sure. If you FPGA manufacturers stick with ball grid you close off many possible inroads to FPGA. Hopefully the market forces will fill this space. JPArticle: 55276
Mentor Graphics has a commercialized CAN core. A bit more information.. Altera SOPC generation tool (integrated into Quartus II) provide a smooth integration of a 31-bit CPU (Nios) and the Mentor Graphics Can core. CPU cores available for Xilinx FPGAs include Microblaze, PowerPC 405 (hardwared) etc. "Ching Wang" <bwang@remove.hal-pc.org> wrote in message news:3eb221ee$0$67179$a726171b@news.hal-pc.org... > Our project is using Motorola 68HC12 (DG128A) and its MSCAN communication. I > am interested in using some other MCUs that may not have built-in CAN > support. Is there CAN IP core available in public domain, so I can set up my > own FPGA to drive my Philips CAN transceiver chip? > >Article: 55277
The long wires on the 40 pin DIL make it impractical for the high edge
speeds on modern FPGAs. If you really want a 40 pin package, use an
adapter such as those made by Ironwood. Make sure you put bypass caps on
the adapter close to the FPGA. 40 pin DIPs are so 70's. Time to move
into the new millenium. BTW, there is a step in between BGAs and DIPs.
The smaller Xilinx parts, for instance, come in 44 pin quad flat packs.
Jan Panteltje wrote:
> 5 on an euro card 160 x 100 mm
> 10 cards in a 19 inch rack.
>
> For my brute force key cracker.
>
> If not Xilinx then any other manufacturer if it comes with free tools.
>
> There is a market here, I am sure.
> If you FPGA manufacturers stick with ball grid you close off
> many possible inroads to FPGA.
>
> Hopefully the market forces will fill this space.
>
> JP
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 55278
I've tried adjusting the constraints both ways. It is far from linear, sometimes
overconstraining makes it worse, sometimes better. Sometimes underconstraining
makes it better, sometimes worse. With 3.3, if you had a few paths that were not
meeting timing, you could go back to the design to reduce the levels of logic on
those paths and you could count on the router still routing the other paths pretty
much the same thus you had an honest shot of improving timing by looking at the
reported critical paths and fixing them in the design. With the new router's
behavior, the critical path has more to do with the router than it does with the
levels of logic, so fixing one critical path in logic just makes another pop up.
It is classic whack-a-mole. Overconstraining did sometimes work well with 3.3.
It is completely non-deterministic in 4.x and 5.x. This behavior is aggravated
when the design is dense because the router does not seek more or less optimum
paths, congesting the routing. VIrtex devices are over-routed given a good
router. The new routing algorithm takes advantage of the overrouting to let it be
really sloppy, which it can get away until you get a dense high speed design.
Brian Drummond wrote:
> On Thu, 01 May 2003 14:01:34 GMT, Ray Andraka <ray@andraka.com> wrote:
>
> >The problem is that since version 4.1 of the software, you can no
> >longer count on the router doing a good job given a good placement. Previous
> >versions did an excellent job finding pretty much optimal routes for a given
> >placement. The current router stops improving each net as soon as it has a
> >positive slack, so unlike the previous router, nearly every net has a delay
> >close to the period constraint when the design is aggressive and it
> >unneccesarily eats up routing resources.
>
> Have you tried overconstraining the timings by (say) 10% and then
> relaxing the constraints on a Timegrp consisting solely of the
> (hopefully few) failing paths?
>
> ISTM this could be semi-automated with a script.
>
> No I haven't tried it, I'm still using 3.3! :-)
>
> But I have tried overconstraining, and sometimes been surprised by how
> few paths fail constraints. (This may or may not be the case with your
> aggressively floorplanned designs)
>
> - Brian
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 55279In article <b8tkoe$79p$1@reader1.tiscali.nl>, Jan Panteltje <panteltje@yahoo.com> wrote: > >There is a market here, I am sure. >If you FPGA manufacturers stick with ball grid you close off >many possible inroads to FPGA. Personally I've gone with 44 PLCC since that seems to be the closest thing to an "entry level" package in a CPLD. You can get through-hole sockets on a .1" grid, which isn't entirely unlike DIP. And for prototyping you can buy (or make) PLCC->DIL adapters. They are ungodly wide, though. This 44PC one I have is 14 pins across. Electronix Express part# 03PLCC2, icyc. -- Ben Jackson <ben@ben.com> http://www.ben.com/Article: 55280
The main problem, in my opinion, is that you have to pay a royaltes to BOSH for each core you sell. Also the ESA has a CAN core. Bye Giuseppe "Ching Wang" <bwang@remove.hal-pc.org> ha scritto nel messaggio news:3eb221ee$0$67179$a726171b@news.hal-pc.org... > Our project is using Motorola 68HC12 (DG128A) and its MSCAN communication. I > am interested in using some other MCUs that may not have built-in CAN > support. Is there CAN IP core available in public domain, so I can set up my > own FPGA to drive my Philips CAN transceiver chip? > >Article: 55281
You should not use this as a physical limit unless you are trying to obtain maximum performance. Most designs work well until 75% of LUT's and FF's are consumed. I have not used the x2v4000, but 3 days to place and route would suggest another problem. Even 9 hours for synthesis seems high. I am currently using the x2v1000 at 75% capacity and it only takes 35mins for the tool to complete. I have had a problem with PAR.EXE (router) just stops responding. At first I waited 3 hours for a normal 35min run. I check the task manager and it showed 0% CPU usage. I restarted the run and it completed in the normal time frame, and task manager indicate PAR running 100% cpu usage. This has happened frequently since udating to 5.2. billh40@aol.com (Bill Hanna) wrote in news:97d137ce.0305010723.29dbbf7d@posting.google.com: > evans39084@aol.com wrote in message > news:<vb1508fogi3s1f@corp.supernews.com>... >> I can relate to the problems you are having with the place and route >> tools. I have spent countless hours tring rewrite and optimze my >> VHDL or schematics designs. We all try to obtain the maximum >> performance in the smallest real estate possible. You need to better >> understand the technology your working with before comdeming it. On >> a Xilinx device, maximun performance can usually be obtained until >> 99% of the slices are consumed. After that, unrelated logic packing >> in the slice occures to fit the design. This unrelated logic, and >> associated rat nest of routes used to perform this packing, is where >> the delays start to become a problem. The constraints file setup my >> the designer helps the software determine which signals are the most >> critical and give highest priority. To maintain maximum performance, >> the size of the FPGA should be large enough to minimize or eliminate >> the unrelated logic packing. There will a large amount of unused >> resources, but performance usually doesn't come without a price. For >> large DSP's, you may need multiple smaller FPGA's instead of one >> large one. >> >> As far as SystemAce is concerned, it is still new software. Any bugs >> it may have, will be fixed eventually. >> >> Welcome to the real world. >> >> >> Ray Andraka <ray@andraka.com> wrote in >> news:3EA5A01C.3F9E2878@andraka.com: >> >> > The problem is that there are no third party place and route tools. >> > The place and route tools are where the worst bugs (features) are. >> > The one that is particularly debilitating is the laziness of the >> > router in versions 4.x and 5.x that makes all paths in a design >> > become critical paths. >> > >> > Evan wrote: >> > >> >> I've worked with various tools since FPGA's first appeared. You >> >> can't beat the price and performance of the software provided by >> >> Xilinx or Altera. Their software may have bugs, but you can >> >> usually work around them. If the vendor put as much effort to >> >> make the perfect software product you wanted. You wouldn't be >> >> able to afford it. Has it stands, the high end software tools cost >> >> $10,000 to $20,000+. Altera and Xilinx provide these tools as a >> >> low cost alternative, to help promote their sales. If you can't >> >> deal with it, put up the big bucks and buy the good software. >> >> Don't ruin a good thing for the rest of us. >> >> >> >> billh40@aol.com (Bill Hanna) wrote in >> >> news:97d137ce.0304171001.5ec5461d@posting.google.com: >> >> >> >> > I have been designing a Digital Signal Processor using the >> >> > XC2V4000 chip. >> >> > Software errors in ISE 4.2 and 5.1 have caused long hours of >> >> > delay in developing the design: >> >> > >> >> > Software bugs in SystemAce causes erase problems in the MPM. >> >> > Deleting signal wires in ECS causes Fatal errors that crash >> >> > the >> >> > system. >> >> > A large design exceeds the 2GB memory limit and generates a >> >> > fatal >> >> > memory error. >> >> > >> >> > I have designed Altera chips for over 6 years and never had >> >> > a >> >> > problem. >> >> > >> >> > All digital designers should stop designing new projects >> >> > with >> >> > Xilinx ICs until Xilinx corrects all software problems with ISE. >> >> > >> >> > Bill Hanna >> > >> > -- >> > --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 >> > >> > "They that give up essential liberty to obtain a little >> > temporary safety deserve neither liberty nor safety." >> > -Benjamin Franklin, 1759 >> > >> > >> > > Thanks for your information. I exceeded the 99% limit at 23,038 > slices on a XC2V4000 and it never finished routing. It ran for 3 days > over the weekend. I ended up stopping the routing process. I am using > a 2GHz P4 with 1GB DDR SDRAM and 3.5GB VM. The normal synthesis time > is 9 hours and 1 hour to route for 17,000 slices (72% of the XC2V4000 > chip). I will use your guide line of 99% max of 22,800 slices. > Bill HannaArticle: 55282
Hi Mark, If you're still selecting a device, you may be interested in this white paper describing the hard (dedicated circuitry) implementation of dynamic phase alignment (DPA) in Stratix-GX vs. the soft implementation in Virtex-II/V-II Pro. Even if you've already put a Xilinx device on your board, the white paper lists the appropriate Xilinx App notes for soft DPA so it makes a good bibliography :). http://www.altera.com/literature/wp/wp_stratixgx_dpa_advantages.pdf The main advantages of a hard solution are speed (1 Gb/s in Stratix-GX), low resource usage (don't burn up LEs etc. to build your own DPA circuitry) and the fact that it's all been pre-verified to work in hardware by the Stratix-GX designers, so it's simpler to get going. This app note describes the DPA implementation in Stratix-GX in more detail. Even if you decide to use a soft solution in Xilinx FPGAs, the descriptions of how the DPA hardware works may be useful to you. http://www.altera.com/literature/an/an236.pdf Vaughn "Mark Dixon" <jmdixon@attbi.com> wrote in message news:<gRjsa.430896$OV.428311@rwcrnsc54>... > I was wondering if anyone had any hints on implementing per bit dynamic > alignment on an interface to a Xilinx FPGA (as is used with a SPI-4.2 > interface, for example). I understand the overall concept of utilizing a > training pattern and a "learning algorithm" to adjust for the correct phase > offset for each bit. However, I am more specifically wondering how to > implement the per bit phase shift within a Xilinx architecture. I have not > seen any app. notes on the details of implementing this type of per bit > dynamic delay. Any thoughts? > > Thanks! > -Mark DixonArticle: 55284
Bill; According to the 5.2i Release and Installation Guide, targeting a XC2V2000->XC2V6000 part range requires 2 Gb Physical ram and 2 Gb Swap area -- your excessive times may be due to the fact that your PC is swapping heavily to the disk because of insufficient ram. You ***NEED*** the physical ram to be there, otherwise you'll be at the mercy of memory/disk thrashing... Up the ram in your machine and you should get better P&R times... -bob Bill Hanna wrote: > > evans39084@aol.com wrote in message news:<vb1508fogi3s1f@corp.supernews.com>... > > I can relate to the problems you are having with the place and route > > tools. I have spent countless hours tring rewrite and optimze my VHDL or > > schematics designs. We all try to obtain the maximum performance in the > > smallest real estate possible. You need to better understand the > > technology your working with before comdeming it. On a Xilinx device, > > maximun performance can usually be obtained until 99% of the slices are > > consumed. After that, unrelated logic packing in the slice occures to > > fit the design. This unrelated logic, and associated rat nest of routes > > used to perform this packing, is where the delays start to become a > > problem. The constraints file setup my the designer helps the software > > determine which signals are the most critical and give highest priority. > > To maintain maximum performance, the size of the FPGA should be large > > enough to minimize or eliminate the unrelated logic packing. There will a > > large amount of unused resources, but performance usually doesn't come > > without a price. For large DSP's, you may need multiple smaller FPGA's > > instead of one large one. > > > > As far as SystemAce is concerned, it is still new software. Any bugs it > > may have, will be fixed eventually. > > > > Welcome to the real world. > > > > > > Ray Andraka <ray@andraka.com> wrote in > > news:3EA5A01C.3F9E2878@andraka.com: > > > > > The problem is that there are no third party place and route tools. > > > The place and route tools are where the worst bugs (features) are. > > > The one that is particularly debilitating is the laziness of the > > > router in versions 4.x and 5.x that makes all paths in a design become > > > critical paths. > > > > > > Evan wrote: > > > > > >> I've worked with various tools since FPGA's first appeared. You > > >> can't beat the price and performance of the software provided by > > >> Xilinx or Altera. Their software may have bugs, but you can usually > > >> work around them. If the vendor put as much effort to make the > > >> perfect software product you wanted. You wouldn't be able to afford > > >> it. Has it stands, the high end software tools cost $10,000 to > > >> $20,000+. Altera and Xilinx provide these tools as a low cost > > >> alternative, to help promote their sales. If you can't deal with it, > > >> put up the big bucks and buy the good software. Don't ruin a good > > >> thing for the rest of us. > > >> > > >> billh40@aol.com (Bill Hanna) wrote in > > >> news:97d137ce.0304171001.5ec5461d@posting.google.com: > > >> > > >> > I have been designing a Digital Signal Processor using the XC2V4000 > > >> > chip. > > >> > Software errors in ISE 4.2 and 5.1 have caused long hours of delay > > >> > in developing the design: > > >> > > > >> > Software bugs in SystemAce causes erase problems in the MPM. > > >> > Deleting signal wires in ECS causes Fatal errors that crash the > > >> > system. > > >> > A large design exceeds the 2GB memory limit and generates a > > >> > fatal > > >> > memory error. > > >> > > > >> > I have designed Altera chips for over 6 years and never had a > > >> > problem. > > >> > > > >> > All digital designers should stop designing new projects with > > >> > Xilinx ICs until Xilinx corrects all software problems with ISE. > > >> > > > >> > Bill Hanna > > > > > > -- > > > --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 > > > > > > "They that give up essential liberty to obtain a little > > > temporary safety deserve neither liberty nor safety." > > > -Benjamin Franklin, 1759 > > > > > > > > > > Thanks for your information. I exceeded the 99% limit at 23,038 > slices on a XC2V4000 and it never finished routing. It ran for 3 days > over the weekend. I ended up stopping the routing process. I am using > a 2GHz P4 with 1GB DDR SDRAM and 3.5GB VM. The normal synthesis time > is 9 hours and 1 hour to route for 17,000 slices (72% of the XC2V4000 > chip). I will use your guide line of 99% max of 22,800 slices. > Bill HannaArticle: 55285
Mark, Other than we (obviously) have a lot of comments on the app note that the other guys have created (and have a full response to all of its errors and omissions on the way), the SFI core that we have as IP was first done using the variable phase shift feature of the DCM (using two global clocks, one on 0 and one on 180 outputs to eliminate any clock skew from rising to falling edge), and then done using the carry chain and CLBs to automatically find the center of the bit. Nice not to have any hard and fixed logic, as we always have options of how to implement the best solution. Oh, and GX having 8 phases at 600 MHz (208 ps per step) is pretty coarse compared to our tap of ~40 ps in VII Pro (or the carry chain delays). Need to change to a better phase? Must jump 208 ps? Oops, missed it..... When the phase step is 12.5% of a UI, then worst case the adjustment step is 1/4 UI (because you might step the wrong way due to jitter), which is so large that you have no eye margin left. The two methods both had their pluses (our cary chain and our DCM), and when we were all done, the carry chain 'won' for the SFI application with individual bit timing alignment (had better performance overall -- not always the case for the many many cores for source synchrounous parallel interfaces however). The DCM still wins for the best eye margin in actual applications for wide parallel buses where the pcb designer controls the individual bit skew. Measurements of 68% margin at 622 Mb/s DDR are not uncommon. Oh, and we know our margin, and you do too, as you can move the phase back and forth to measure it with the DCM. Generally speaking, there are two ways to train: in line, and off line. Off line is where there is a training sequence that is sent. Problems with that is how often do you send it? How often must you send it to re-train? How do you know when you are aligned? How do you know when you are not aligned? The in line method is to have two separate servo systems, where one dithers back and forth to find the center, and then gets switched in to be used, while the other then gets to dither for awhile. The two recovery systems ping-pong back and forth forever. I am not saying that one is better, or worse, I am just telling you what your options are as a systems designer. You can "grow your own" core or IP, or you can use the IP that is offered by the respective companies. Any system that adjusts while recovering has issues that are shared with all clock and data recovery circuits, in that it is then sensitive to data jitter, and has to have its jitter tolerance meet certain specifications and requirements before you can trust it. These servo loops can be fooled by jitter into finding the wrong slicing point, and generating errors. If it is hard logic, oh well. No chance to "improve" or fix it. And speaking of jitter, the PLL in the referenced note attenuates no jitter below 6 MHz in frequency (and the DCM attenuates no jitter at any frequency as noted). Since most of the jitter power is below 6 MHz in any real system, the claim of jitter attenuation while technically accurate, is not likely to provide any real benefit in a system. I would be more interested in a jitter tolerance curve for the hard logic, as that would tell the tale. And by the by, since the app note says that the "....PLL in Stratix is the same as the one in Stratix GX...." why wasn't the GX part actually tested? Why wasn't the hard logic core actually tested? By contacting Xilinx, we will be happy to bring an actual demonstration board to show the customer all of the benefits and features of all of our parallel and serial solutions, many of which are listed at http://www.support.xilinx.com/esp/index.htm AustinArticle: 55286
ESA no longer hands out its CAN core. Yes, you have to pay Bosch royalities for a 'CAN' core. There's a certification process involved, and a rather large test bench. Yes, there are commercial and public domain cores available. A web search will find them. I wrote one in VHDL, and could be enticed to sell it. IMHO, it has better bit-rate synching than the public domain ones. SH On Fri, 2 May 2003 14:17:53 +0200, "Giuseppeł" <miaooaim@inwind.it> wrote: >The main problem, in my opinion, is that you have to pay a royaltes to BOSH >for each core you sell. >Also the ESA has a CAN core. > >Bye >Giuseppe > >"Ching Wang" <bwang@remove.hal-pc.org> ha scritto nel messaggio >news:3eb221ee$0$67179$a726171b@news.hal-pc.org... >> Our project is using Motorola 68HC12 (DG128A) and its MSCAN communication. >I >> am interested in using some other MCUs that may not have built-in CAN >> support. Is there CAN IP core available in public domain, so I can set up >my >> own FPGA to drive my Philips CAN transceiver chip? >> >> >Article: 55288
Ziad, Thanks for the information. We are trying to prototype a PCI host bridge for an embedded system. A PCI development board that would function in the CPU slot of a PCI only version of a PICMG 1.0 passive backplane would address our needs. See PBP-04P at http://www.portwell.com/backplane.htm#pci for an example of the backplane we're considering. A card in the CPU slot has to supply the PCI clock and REQ and GNTs to the other slots. The arbitration signals are straitforward to implement if the FPGA pins are connected to the appropriate pins on the edge connector, but the clocks have meet PCI skew requirements. Would the Altera Stratix PCI development board meet these requirements? Thanks, Mike zabulebdeh@yahoo.com (Ziad Abu-Lebdeh) wrote in message news:<f784b02b.0304302031.a3476d9@posting.google.com>... > Hi Mike, > > You are correct, the PCI32 Nios Target board plugs into the PMC > connectors on the APEX Nios board. Unfortunately, the PMC connectors > were removed from the Startix and Cyclone Nios boards. > > As far as prototyping is concerned, I believe you can can do > prototyping for designs that will end up in Cyclone using a Stratix > board just as well. The reason is because Startix is a superset of > the Cyclone and as long as you make sure you do not use a feature in > Stratix that is not supported in Cyclone you are well on your way. > The best way to do that is just compile the design in Quartus for > Cyclone while you are prototyping to ensure that will be able to use > Cyclone in the end. If you are doing something wrong with Cyclone, > Quartus will tell you. Quartus will also give you the timing you > should expect for the design in Cyclone. > > Altera is about to fully release a Stratix PCI development board. See > http://www.altera.com/products/devkits/altera/kit-pci_stx.htm. > > This board allows you to also prototype Nios Based applications. You > will have to do some of your own work to get the Nios stuff to work on > the board, but it should not be that hard if you are familiar with > Nios. > > Finally, when you say PCIMG style backplane. Is it Compact PCI, PMC > or something else? The board I am talking about is standard PCI and > may not address your need for CompactPCI or PMC. > > Regards, > > Ziad Abu-Lebdeh > > mxv@yahoo.com (mike) wrote in message news:<8ea508fe.0304281139.3f6ef067@posting.google.com>... > > The Altera PCI32 Target daughtercard doesn't seem to be compatible > > with the Cyclone NIOS board. The Cyclone NIOS board doesn't have the > > same connectors as the older Apex NIOS this daughtercard was designed > > for. Correct me if I'm wrong, Altera. > > > > Any other vendors out there working on a Cyclone PCI board? I'm > > looking for a PCI host version that would fit into a PICMG passive PCI > > backplane. That's asking for a lot, but it doesn't hurt to ask. > > > > BTW, is anyone out there using the Cyclone 1C3 in a PCI application? > > It doesn't have PCI buffers, but I'm wondering if anyone has worked > > around this issue. > > > > Thanks. > > > > > > > > > "Paul Leventis" <paul.leventis@utoronto.ca> ha scritto nel messaggio > > > news:SY8qa.141485$BQi.97105@news04.bloor.is.net.cable.rogers.com... > > > > Hi Mike, > > > > > > > > One product Altera offers is the PCI32 Nios Add-on Dev Kit. This is a > board > > > > that you hook-up to any Nios dev kit (including the Cyclone version), and > > > > you can plug it into a PCI32 slot. It provides a PCI interface to your > Nios > > > > dev board, an API, etc. I don't know anything about it besides what's on > > > > our web site. > > > > > > > > You can read about it here: > > > > > > > > http://www.altera.com/products/devkits/altera/kit-dev_nios_pci32.html > > > > > > > > - Paul > > > > > > > > "mike" <mxv@yahoo.com> wrote in message > > > > news:8ea508fe.0304242036.224f0c6e@posting.google.com... > > > > > I've searched the web with no luck for a PCI development board with > > > > > using an Altera Cyclone part. Probably because it's a new part, but if > > > > > anyone knows where I can find one, please post a link. It must be > > > > > Cylone, and it can be a PCI board or PMC module. > > > > > > > > > > Thanks in advance. > > > > > > > >Article: 55289
"Ching Wang" <bwang@remove.hal-pc.org> ha scritto nel messaggio news:3eb221ee$0$67179$a726171b@news.hal-pc.org... > support. Is there CAN IP core available in public domain, Try there: www.opencores.org Seems like they have a CAN IP core, but I haven't tried it yet. -- LorenzoArticle: 55290
FWIW, I have a 2V6000 design that I ran through both 4.2 and 5.1. 4.2 was running on
a Dual PIII-800 with 1GB RAM and 3GB paging running under NT4.0, where 5.1 was
running on a 1.8GHz dual K7 with 2GB RAM and 4GB paging under 'doze 2000 prof. The
run on the older, smaller, slower machine using 4.2 completes considerably faster
than the run on the new machine using 5.1, and the quality of results is considerably
better. Just one data point. It is a tool breaker of a design tho (it is the
sonar processor design shown in the gallery pages of my website). Synthesis of the
full design under synplify takes about 9 hrs on the K7 machine, but if I break the
design into 3 subdesigns, synthesize them separately and let xilinx paste them
together, synthesis completes in under 2 hrs. This design has lots of structural
instantiation, which seems to slow the synthesis considerably.
Robert Myers wrote:
> Bill;
>
> According to the 5.2i Release and Installation Guide,
> targeting a XC2V2000->XC2V6000 part range requires 2 Gb Physical ram
> and 2 Gb Swap area -- your excessive times may be due to the
> fact that your PC is swapping heavily to the disk because of
> insufficient ram. You ***NEED*** the physical ram to be there,
> otherwise you'll be at the mercy of memory/disk thrashing...
>
> Up the ram in your machine and you should get better P&R times...
>
> -bob
>
> Bill Hanna wrote:
> >
> > evans39084@aol.com wrote in message news:<vb1508fogi3s1f@corp.supernews.com>...
> > > I can relate to the problems you are having with the place and route
> > > tools. I have spent countless hours tring rewrite and optimze my VHDL or
> > > schematics designs. We all try to obtain the maximum performance in the
> > > smallest real estate possible. You need to better understand the
> > > technology your working with before comdeming it. On a Xilinx device,
> > > maximun performance can usually be obtained until 99% of the slices are
> > > consumed. After that, unrelated logic packing in the slice occures to
> > > fit the design. This unrelated logic, and associated rat nest of routes
> > > used to perform this packing, is where the delays start to become a
> > > problem. The constraints file setup my the designer helps the software
> > > determine which signals are the most critical and give highest priority.
> > > To maintain maximum performance, the size of the FPGA should be large
> > > enough to minimize or eliminate the unrelated logic packing. There will a
> > > large amount of unused resources, but performance usually doesn't come
> > > without a price. For large DSP's, you may need multiple smaller FPGA's
> > > instead of one large one.
> > >
> > > As far as SystemAce is concerned, it is still new software. Any bugs it
> > > may have, will be fixed eventually.
> > >
> > > Welcome to the real world.
> > >
> > >
> > > Ray Andraka <ray@andraka.com> wrote in
> > > news:3EA5A01C.3F9E2878@andraka.com:
> > >
> > > > The problem is that there are no third party place and route tools.
> > > > The place and route tools are where the worst bugs (features) are.
> > > > The one that is particularly debilitating is the laziness of the
> > > > router in versions 4.x and 5.x that makes all paths in a design become
> > > > critical paths.
> > > >
> > > > Evan wrote:
> > > >
> > > >> I've worked with various tools since FPGA's first appeared. You
> > > >> can't beat the price and performance of the software provided by
> > > >> Xilinx or Altera. Their software may have bugs, but you can usually
> > > >> work around them. If the vendor put as much effort to make the
> > > >> perfect software product you wanted. You wouldn't be able to afford
> > > >> it. Has it stands, the high end software tools cost $10,000 to
> > > >> $20,000+. Altera and Xilinx provide these tools as a low cost
> > > >> alternative, to help promote their sales. If you can't deal with it,
> > > >> put up the big bucks and buy the good software. Don't ruin a good
> > > >> thing for the rest of us.
> > > >>
> > > >> billh40@aol.com (Bill Hanna) wrote in
> > > >> news:97d137ce.0304171001.5ec5461d@posting.google.com:
> > > >>
> > > >> > I have been designing a Digital Signal Processor using the XC2V4000
> > > >> > chip.
> > > >> > Software errors in ISE 4.2 and 5.1 have caused long hours of delay
> > > >> > in developing the design:
> > > >> >
> > > >> > Software bugs in SystemAce causes erase problems in the MPM.
> > > >> > Deleting signal wires in ECS causes Fatal errors that crash the
> > > >> > system.
> > > >> > A large design exceeds the 2GB memory limit and generates a
> > > >> > fatal
> > > >> > memory error.
> > > >> >
> > > >> > I have designed Altera chips for over 6 years and never had a
> > > >> > problem.
> > > >> >
> > > >> > All digital designers should stop designing new projects with
> > > >> > Xilinx ICs until Xilinx corrects all software problems with ISE.
> > > >> >
> > > >> > Bill Hanna
> > > >
> > > > --
> > > > --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
> > > >
> > > > "They that give up essential liberty to obtain a little
> > > > temporary safety deserve neither liberty nor safety."
> > > > -Benjamin Franklin, 1759
> > > >
> > > >
> > > >
> > Thanks for your information. I exceeded the 99% limit at 23,038
> > slices on a XC2V4000 and it never finished routing. It ran for 3 days
> > over the weekend. I ended up stopping the routing process. I am using
> > a 2GHz P4 with 1GB DDR SDRAM and 3.5GB VM. The normal synthesis time
> > is 9 hours and 1 hour to route for 17,000 slices (72% of the XC2V4000
> > chip). I will use your guide line of 99% max of 22,800 slices.
> > Bill Hanna
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 55291Jim Granville wrote: > > > Neither Xilinx, nor Atmel quote operating Tj MAX for the three classes, > and as such their data is incomplete. [Peter / Austin ? ] > > [Xilinx are remiss in not quoting an operating Tj MAX, nor do they give > a thermal load under which the TA is acceptable] Sorry, Jim. This statement is wrong: We at Xilinx pioneered the "junction-temperature" specification method for programmable devices, since it would be meaningless and misleading for a manufacturer of PLDs to guarantee operation at a given ambient temperature. (I have publicly used words like "stupid" and "irresponsible" in this connection). The user might vary power consumption and cooling arrangements over an enormous range, that we as a manufacturer have no control over. Xilinx has for many years specified the max guaranteed junction temperature (up to which the performance parameters are guaranteed) as 85 degree centigrade for C-grade and 100 for I-grade. This is documented in each of our data sheets. We also document the thermal resistance ( in degree C per Watt of dissipation) for all our packages (in the package information). Once the user knows the power consumed, everything is in the open. We also used to publish derating numbers for the ac parameters ( add 0.35% for every degree above max), but this number is not guaranteed, and it should definitely never be used in the opposite direction to calculate higher performance at lower max temperature. This stuff is close to my heart, and I really do not understand how anybody can accuse Xilinx of having incomplete documentation. We have been the leader in supplying sane and defensible numbers, instead of the old Ta nonsense. (I know that users would love us to guarantee performance at Ta, but that is inherently impossible, see above). Peter Alfke, Xilinx Applications Engineering.Article: 55292
"Peter Alfke" <peter@xilinx.com> wrote in message news:3EB2BDC2.24FE8D94@xilinx.com... > > > Jim Granville wrote: > > > > > > Neither Xilinx, nor Atmel quote operating Tj MAX for the three classes, > > and as such their data is incomplete. [Peter / Austin ? ] > > > > [Xilinx are remiss in not quoting an operating Tj MAX, nor do they give > > a thermal load under which the TA is acceptable] > > Sorry, Jim. This statement is wrong: > We at Xilinx pioneered the "junction-temperature" specification method > for programmable devices, since it would be meaningless and misleading > for a manufacturer of PLDs to guarantee operation at a given ambient > temperature. (I have publicly used words like "stupid" and > "irresponsible" in this connection). The user might vary power > consumption and cooling arrangements over an enormous range, that we as > a manufacturer have no control over. > > Xilinx has for many years specified the max guaranteed junction > temperature (up to which the performance parameters are guaranteed) as > 85 degree centigrade for C-grade and 100 for I-grade. This is documented > in each of our data sheets. > We also document the thermal resistance ( in degree C per Watt of > dissipation) for all our packages (in the package information). Once the > user knows the power consumed, everything is in the open. > We also used to publish derating numbers for the ac parameters ( add > 0.35% for every degree above max I presume you are right about this. Some time ago, though, I was trying to decide if a given design would have thermal problems. What one needs to know, then, is how much power a design will generate, given the clock rate and the fraction of clock cycles an average signal wire changes state. (Maybe a little more information would be desirable, but that should be enough to get close. The average should include both used and unused routing links.) At the time, I couldn't find any information describing that. -- glenArticle: 55293
Peter Alfke wrote: > > Jim Granville wrote: > > > > > > Neither Xilinx, nor Atmel quote operating Tj MAX for the three classes, > > and as such their data is incomplete. [Peter / Austin ? ] > > > > [Xilinx are remiss in not quoting an operating Tj MAX, nor do they give > > a thermal load under which the TA is acceptable] > > Sorry, Jim. This statement is wrong: > We at Xilinx pioneered the "junction-temperature" specification method > for programmable devices, since it would be meaningless and misleading > for a manufacturer of PLDs to guarantee operation at a given ambient > temperature. (I have publicly used words like "stupid" and > "irresponsible" in this connection). The user might vary power > consumption and cooling arrangements over an enormous range, that we as > a manufacturer have no control over. Sounds commendable. > Xilinx has for many years specified the max guaranteed junction > temperature (up to which the performance parameters are guaranteed) as > 85 degree centigrade for C-grade and 100 for I-grade. This is documented > in each of our data sheets. > We also document the thermal resistance ( in degree C per Watt of > dissipation) for all our packages (in the package information). Once the > user knows the power consumed, everything is in the open. > We also used to publish derating numbers for the ac parameters ( add > 0.35% for every degree above max), but this number is not guaranteed, > and it should definitely never be used in the opposite direction to > calculate higher performance at lower max temperature. > > This stuff is close to my heart, and I really do not understand how > anybody can accuse Xilinx of having incomplete documentation. We have > been the leader in supplying sane and defensible numbers, instead of > the old Ta nonsense. > (I know that users would love us to guarantee performance at Ta, but > that is inherently impossible, see above). Did you look at the datasheet titled 'XCR3032XL 32 Macrocell Automotive IQ CPLD' I downloaded an Automotive spec sheet, as I assumed that would have the best thermal info. ie I followed a path typical for any designer. I did the same at all 3 vendors sites. In 'XCR3032XL 32 Macrocell Automotive IQ CPLD' you will find : Very first line, under Features " Guaranteed to meet full electrical specifications over TA = –40°C to +125°C " Recommended Operating Conditions = Ta ONLY is mentioned, and no thermal load info. I believe Tj appears once only, under ABS MAX< and does not state if it is under bias. I could see no links to other thermal design docs (unlike Lattice) Since we both agree on the important thermal info, perhaps you could scan/critique this particular data sheet ( just put some tape over the brand name, or assume it is a brand A product :) -jgArticle: 55294
On a sunny day (Fri, 02 May 2003 11:35:42 GMT) it happened Ray Andraka <ray@andraka.com> wrote in <3EB258D6.D81F9E08@andraka.com>: >The long wires on the 40 pin DIL make it impractical for the high edge >speeds on modern FPGAs. Well if I look at my digilab 2 then there is a l o n g set of wires coming from the FPQ208 or whatever. If you use the middle pins on the DIL 40 for supply, the wires are short (for decoupling). 70 ties he? I started designing with RTL that was long before that... Then we had DTL too. >If you really want a 40 pin package, use an >adapter such as those made by Ironwood. Make sure you put bypass caps on >the adapter close to the FPGA. 40 pin DIPs are so 70's. Time to move >into the new millenium. BTW, there is a step in between BGAs and DIPs. >The smaller Xilinx parts, for instance, come in 44 pin quad flat packs. Yes but I want 800 K gates in ONE package. Really I see those manufacturers have some strange concept about more gates -> more pins. More then 700 pins on the Actel 750 k gates for example. Why? IO depends on the IO, not on the complexity of the logic. It is just an assumption, that cannot possible hold either in the long run, 7000 pins for a 7 million gates? No logic here. The 40 pin DIL is easy to use on protoboard, you can make your own boards, double sided will do, man even single sided. MY opinion is that a lot of people have no idea what FPGA sales could improve if the chips were more relaxed in packaging. Many people start with DIL PIC micro controllers, they sell by the millions. High density FPGA with few pins is ideal for crypto and for example filters. As your own short-wave filters... I designed some transceivers with real stuff (like coils oops), it is ALWAYS a tradeoff. How about a good SAW filter :-) FPGA will beat it in flexibility. I would like to experiment with that one day if I find the time. So many projects going on... Anyways thank you for the nice site, fascinating stuff. Regards JanArticle: 55295
Jim Granville wrote: > > > I could see no links to other thermal design docs (unlike Lattice) > > Since we both agree on the important thermal info, perhaps you > could scan/critique this particular data sheet > ( just put some tape over the brand name, or assume it is a brand A > product :) Thanks, Jim., for pointing this out. And in an automotive data sheet to boot :-( Luck has it that I do not need to camouflage the identity. I can raise hell within Xilinx, and have done so before. What you refer to is a disgrace, or at best a damn oversight. I will load up the big cannon... Peter AlfkeArticle: 55296
I gave you the wrong URL. It has to be http://www.xilinx.com/xcell/xl34/xl34_54.pdf (the xl34 needs to be there twice. Don't ask me why) Sorry for the mistake... Peter Peter Alfke wrote: > > Here are two solutions: > You can make any input into a Schmitt trigger, but it costs you an extra pin: > > http://support.xilinx.com/support/techxclusives/6easy-techX37.htm > > or you can make the inside circuit immune to double-triggering. See > www.xilinx.com/xcell/xl34_54.pdf > > I hope either of these circuits helps. > Peter Alfke, Xilinx Applications > > Jock wrote: > > > > Is it possible to define a Xilinx Virtex input as a Schmitt trigger? > > > > On my application, some inputs have a 30ns rise time which seems to be > > causing an intermittant timing problem. Reducing the input capacitance so I > > get 10ns rise time fixes the problem, but I get RF problems elsewhere.Article: 55297
Jan Panteltje wrote: > 5 on an euro card 160 x 100 mm > 10 cards in a 19 inch rack. > > For my brute force key cracker. > > If not Xilinx then any other manufacturer if it comes with free tools. > > There is a market here, I am sure. > If you FPGA manufacturers stick with ball grid you close off > many possible inroads to FPGA. > > Hopefully the market forces will fill this space. Very unlikely. A device with 800k gates produces quite a bit of heat at the intended frequencies. FBGA solves part of this. Further, 40 pins for 800k gates are considered far below the lean side. Meaning the market would be far too small, just a handful of cavemen actually. You cannot use wrapwires at 200MHz either. Forget it. FBGA is doable. With some luck and especially with little IO requirement perhaps even with a 2 layer pcb. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 55298
The package, and therefore the number of pins is driven to a large extent by the
die size and the cavity sizes in the packages. FPGA dies are large, so they
won't fit in many of the small packages, especially as you get towards the
million gates density. It is also far easier for you to not use the extra pins
than it is for another user to work around a shortage of pins, and each package
option adds a very real cost to the manufacturer's as well as the distributor's
bottom line. There is also the issue of dynamic ground current on the larger
devices, which requires low impedance connections, which in turn translates to
lots of power/ground pairs. 40 pins isn't much if you need 30+ of them for power
supply. With the small geometries of the current fab technologies, an inch to
the bypass leaves a very significant inductance between the supply plane and the
chip, enough to make the bypass cap pretty much useless.
40 pin devices were in their heyday in the late 70's and early 80's. Before
that, there were very few devices with enough pins, after that they fell out of
favor for the smaller and better electrically quad flat packs and PLCC packages.
I don't recall *any* RTL or DTL devices in 40 pin DIPs. Even if you do manage to
put the FPGA on an adapter, you'll likely encounter all sorts of signal integrity
gremlins with a single or double sided board given the very fast edge speeds of
modern FPGAs (it is not so much the clock speed, rather it is the rise and fall
times that will bite you). It can be done, but it takes an incredible amount of
SI work to get something that works right out of the chute. It is far cheaper
(when engineering hours are considered) to use a 4+ layer board with proper vcc
and ground planes than to invest in the huge signals integrity work or the seat f
the pants engineering (with it's associated debug). Sorry to break it to you,
but this is a different league than your RTL,DTL and TTL. For hobby use, the
easiest approach is to use one of the many premanufactured FPGA boards, many of
which are available for about what you'd pay for the parts on the board and for
making your single/double layer board. The shortwave receiver, for example is
done on an Insight SpartanII board, which sells for about $125. That one even
has a prototype area for adding your own circuits if you need it (I added 2
resistors, 2 capacitors and a mini phone jack for the radio demo).
Jan Panteltje wrote:
> On a sunny day (Fri, 02 May 2003 11:35:42 GMT) it happened Ray Andraka
> <ray@andraka.com> wrote in <3EB258D6.D81F9E08@andraka.com>:
>
> >The long wires on the 40 pin DIL make it impractical for the high edge
> >speeds on modern FPGAs.
> Well if I look at my digilab 2 then there is a l o n g set of wires coming
> from the FPQ208 or whatever.
> If you use the middle pins on the DIL 40 for supply, the wires are short (for
> decoupling).
> 70 ties he?
> I started designing with RTL that was long before that...
> Then we had DTL too.
>
>
> >If you really want a 40 pin package, use an
> >adapter such as those made by Ironwood. Make sure you put bypass caps on
> >the adapter close to the FPGA. 40 pin DIPs are so 70's. Time to move
> >into the new millenium. BTW, there is a step in between BGAs and DIPs.
> >The smaller Xilinx parts, for instance, come in 44 pin quad flat packs.
> Yes but I want 800 K gates in ONE package.
>
> Really I see those manufacturers have some strange concept about more gates
> -> more pins.
> More then 700 pins on the Actel 750 k gates for example.
> Why?
> IO depends on the IO, not on the complexity of the logic.
> It is just an assumption, that cannot possible hold either in the long run,
> 7000 pins for a 7 million gates?
> No logic here.
>
> The 40 pin DIL is easy to use on protoboard, you can make your own boards,
> double sided will do, man even single sided.
> MY opinion is that a lot of people have no idea what FPGA sales could improve
> if the chips were more relaxed in packaging.
> Many people start with DIL PIC micro controllers, they sell by the
> millions.
> High density FPGA with few pins is ideal for crypto and for example filters.
> As your own short-wave filters...
> I designed some transceivers with real stuff (like coils oops), it is
> ALWAYS a tradeoff.
> How about a good SAW filter :-) FPGA will beat it in flexibility.
> I would like to experiment with that one day if I find the time.
> So many projects going on...
> Anyways thank you for the nice site, fascinating stuff.
> Regards
> Jan
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 55299
Xilinx can't tell you what the power is going to be. It depends very heavily on
your design. If you need to know the power, Xilinx does provide the XPOWER tool
that will compute your power based on the actual place and route and simulation
vectors you feed the tool. THe accuracy will depend on how representative your
simulation vectors are of the actual operation. Xilinx also has some spread
sheets that can be used to get an estimate based on your estimates of the logic
used, your assessment of 'routing complexity', and your declaration of clock
rates and toggle rates. Those spread sheets will get you to about +/-12dB.
Glen Herrmannsfeldt wrote:
> >
> I presume you are right about this. Some time ago, though, I was trying to
> decide if a given design would have thermal problems. What one needs to
> know, then, is how much power a design will generate, given the clock rate
> and the fraction of clock cycles an average signal wire changes state.
> (Maybe a little more information would be desirable, but that should be
> enough to get close. The average should include both used and unused
> routing links.) At the time, I couldn't find any information describing
> that.
>
> -- glen
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
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