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
I'm looking for a comparison of sizes and speeds for fpga's of all different companies. Can someone point me towards this informations. thanks MattArticle: 47351
You will not find this comparison anywhere. The different families have different structures and different features, and the business is too competitive for any unbiased comparison with any validity. Many years ago, PREP was a disastrous attempt at such a normalized comparison. It got really ugly... I would judge the size by the number of available flip-flops and RAM bits (if you need them). Then look at features that enhance your design. I could name many good Xilinx features, but I want to keep this answer generic and unbiased. Peter Alfke, Xilinx Applications ====================================== Matthew E Rosenthal wrote: > I'm looking for a comparison of sizes and speeds for fpga's of all > different companies. > > Can someone point me towards this informations. > > thanks > > MattArticle: 47352
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3D8F2B52.9DA16C60@yahoo.com>... > After taking a quick look at the Cyclone family, I can see they are > taking a slightly different approach than Xilinx. > > The Xilinx Spartan II series is based on the Virtex family just as the > Spartan was based on the XC4000. In contrast, it looks like the Cyclone > family is not directly based on any existing Altera family. > > Comparing the Spartan II to the Cyclone shows that the Cyclone has a > higher LUT to IO ratio. The Cyclone looks a little more like a > potential future Spartan III based on the Virtex II family which also > has a high LUT to IO ratio. > > SpartanII 2S50E 2S100E 2S150E 2S200E 2S300E > LUTs 1536 2400 3456 4700 6144 > IOs 182 202 263 289 329 > ratio 8 12 13 16 19 > > Cyclone EP1C3 EP1C6 EP1C12 EP1C20 > LUTs 2910 5980 12060 20060 > IOs 104 185 249 301 > ratio 28 32 48 67 > > As it turns out this makes the Cyclone parts very expensive in high IO > count applications. Further, Altera seems to not have small chip scale > packages for the low end of the family. Looks like they really tried to > go for a low price, limited options product line, even more so than the > Spartan II. The high LUT count may prove a benefit for some > applications though. From what I've seen, the last 3 or so generations of Altera devices appear to have higher LUT/IO ratios than the comparible Xilinx family. In general, at least in the telecom industry where I am, I think this is the right direction to be moving and Xilinx appears to have finally figured this out, from the looks of the proposed Spartan III. Undoubtly, the problem is identifing exactly what features and what packages to offer for given LUT ranges. We are constantly bumping up against the largest device in a cost effective package. IE, we definitely would move to using a larger Virtex-II (XC2V4000) if it were available in anything smaller than an expensive 1152 pin flip chip package [or the monster 40x40 1.27 mm BGA package]. I realize Xilinx probably has their reasons for the offerings they have (most likely thermal?), but if they could overcome that, it'd be easy money for them, cause I'll bet there are others out there in the same boat as us. Same went for the Virtex-E... the 600E was the largest you could get in a reasonable cost/size package. The XCV812EM was available, but not competitively priced. We would have used a large device if Xilinx had offered it in a FG676. Instead, in both the Virtex-II and Virtex-E, we get to play roulette with MAP and PAR, constaintly bumping up against random timing violations that differ from run to run. Anyone else in the same boat, wishing there were an XC2V4000-FG676 [or actually, just a 3000 with more LUTs, not more BRAM's]? MarcArticle: 47353
"Markus Meng" <meng.engineering@bluewin.ch> wrote in message news:aaaee51b.0209230623.700eae42@posting.google.com... > hi all, > > has anybody done this using spartan-ii with - for example - > an LVDS interface? > > What I require is a fast serial - bus like - connection between > 3 or 4 electronic modules. Those modules are close to each other > but in separate cabinets. I would like to use - let's say - RJ11 > connector and cabling, the speed should be ~ 100 Mbps > > markus I have done this with the spartan2e. The transmitter was in my instrument and the receiver was in a PC. In my case, I had to have electrical isolation. The isolation came from an IL711 magnetic isolator (NVE Corp. from Digikey) so I used a system where the even numbered bits were clocked in on positive edges and the odd numbered bits were clocked in on the negative edges. The 711 will only pass 10 ns pulses reliably. Because of the isolation requirement, I used single ended transmission rather than the LVDS from the FPGA. In any case, it works just fine. In fact the receiver is implemented in a SpartanXL because of the startup current requirements. Theron HicksArticle: 47354
--------------339040D34997A0047A880BB8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Marc, I will reiterate something Peter has said once before: Altera has announced that they will have (note use of the future tense) ....... So comparing an exisiting Spartan IIE product that is selling like crazy today (and is the fourth generation Spartan Product) with a product that doesn't exist yet at a future technology node is a little silly. Also stating their projected future price per LUT is better than the existing price per LUT is silly. Of course: Moore's Law if they haven't totally missed the boat (which they are definitely smart enough not to do). Virtex II Pro is the ninth generation FPGA product. Maybe we have been doing this for awhile, and maybe we have figured out what sells, and what works? Obviously, we can't please absolutely everyone. I appreciate the comments, and we always listen to what the customer wants. Austin Marc Randolph wrote: > rickman <spamgoeshere4@yahoo.com> wrote in message news:<3D8F2B52.9DA16C60@yahoo.com>... > > > After taking a quick look at the Cyclone family, I can see they are > > taking a slightly different approach than Xilinx. > > > > The Xilinx Spartan II series is based on the Virtex family just as the > > Spartan was based on the XC4000. In contrast, it looks like the Cyclone > > family is not directly based on any existing Altera family. > > > > Comparing the Spartan II to the Cyclone shows that the Cyclone has a > > higher LUT to IO ratio. The Cyclone looks a little more like a > > potential future Spartan III based on the Virtex II family which also > > has a high LUT to IO ratio. > > > > SpartanII 2S50E 2S100E 2S150E 2S200E 2S300E > > LUTs 1536 2400 3456 4700 6144 > > IOs 182 202 263 289 329 > > ratio 8 12 13 16 19 > > > > Cyclone EP1C3 EP1C6 EP1C12 EP1C20 > > LUTs 2910 5980 12060 20060 > > IOs 104 185 249 301 > > ratio 28 32 48 67 > > > > As it turns out this makes the Cyclone parts very expensive in high IO > > count applications. Further, Altera seems to not have small chip scale > > packages for the low end of the family. Looks like they really tried to > > go for a low price, limited options product line, even more so than the > > Spartan II. The high LUT count may prove a benefit for some > > applications though. > > From what I've seen, the last 3 or so generations of Altera devices > appear to have higher LUT/IO ratios than the comparible Xilinx family. > In general, at least in the telecom industry where I am, I think this > is the right direction to be moving and Xilinx appears to have finally > figured this out, from the looks of the proposed Spartan III. > Undoubtly, the problem is identifing exactly what features and what > packages to offer for given LUT ranges. > > We are constantly bumping up against the largest device in a cost > effective package. IE, we definitely would move to using a larger > Virtex-II (XC2V4000) if it were available in anything smaller than an > expensive 1152 pin flip chip package [or the monster 40x40 1.27 mm BGA > package]. I realize Xilinx probably has their reasons for the > offerings they have (most likely thermal?), but if they could overcome > that, it'd be easy money for them, cause I'll bet there are others out > there in the same boat as us. > > Same went for the Virtex-E... the 600E was the largest you could get > in a reasonable cost/size package. The XCV812EM was available, but > not competitively priced. We would have used a large device if Xilinx > had offered it in a FG676. Instead, in both the Virtex-II and > Virtex-E, we get to play roulette with MAP and PAR, constaintly > bumping up against random timing violations that differ from run to > run. > > Anyone else in the same boat, wishing there were an XC2V4000-FG676 [or > actually, just a 3000 with more LUTs, not more BRAM's]? > > MarcArticle: 47355
Pierre-Olivier Laprise <plapri@tesserae.McRCIM.McGill.EDU> wrote in message news:<_Zpj9.624$%C6.203154@charlie.risq.qc.ca>... > This procedure is in fact documented in many places that speak > of the configuration procedure, amongst others in the Spartan-II > data sheet under the heading "Initiating Configuration", right > next to a flow chart describing the proper configuration flow. You are absolutely right. I don't know how I could have missed that. Actually, I do: I was reading the section in the configuration procedure under "Boundary Scan Mode" (JTAG) which contains misleading phrases such as "configuration being done entirely throught the TAP (JTAG port)", and "configuration and readback via the TAP are always available", and has a step-by-step procedure that does not mention the PROGRAM pin. Nevertheless, I plead guilty to not being observant enough, and I hereby acquit Xilinx of the heinous crime of docu-negligence, although I submit that much future grief could be averted if in the JTAG configuration documentation a simple clause was added, "... and of course, one must pulse the PROGRAM line low before reconfiguring the device via JTAG." Humbly, -tdArticle: 47356
Jeremy, what is the nature of the discharge? I suppose you do not see physical damage, "only" data corruption. How good is your Vcc decoupling? How stable is the PROG pin? Add a pull-up resistor or capacitor to ground? Just wild ideas... Peter Alfke ===================== "Jérémie WEBER" wrote: > I have a problem with a design ( 200k spartan II E ) that fail when an > Electrostatic discharge occurs. > > I presume that some flip-flop are reseted but not all. That means that my > design fail and is unstable. > > I have set some hardware things to avoid a large part of this problems but > when it occurs I always fail. > > Have you got any Idea to secure the FPGA design itself ? > > Regards. > > Jérémie WEBERArticle: 47357
Austin Lesea wrote
> Virtex II Pro is the ninth generation FPGA product.
Using a conventional interpretation of 'generation',
and omitting the in-between/nothing-much-new products:
2000
3000
4000/E
Virtex/E
VirtexII/Pro
Of course, if you include the 3000A, 4000A, 4000D,
4000H, 5200, 8200, and all the rest, it is probably
generation 42 :-)
BTW, was there ever silicon of a 1000 series, before
the 2064?
Article: 47358Sorry for this OT question, but maybe some of you guys have run into this problem! I'm doing a design in Ulticap 2001, and exported the netlist which I then imported into Ultiboard 2001. The bizarre thing is that some of the components did not import. What's even MORE bizarre is that if I go and tweak the schematic, re-export and re-import the netlist, some of the components that failed to import the first time now import. The design has about 1200 pins, easily below the 1400-pin limit of the version I bought. This is a total show-stopper. Anyone got any hints? Electronics Workbench tech support is "working on the problem." I have installed their Service Pack 1, and the patch to the service pack. Yes, I know, PCAD would be the solution, but for the cost... -Andy Peters Tucson, AZArticle: 47359
Does anyone know of a xilinx prototype board which has over 200 IO lines brought out to headers for use.Article: 47360
Jérémie WEBER wrote: > > I have a problem with a design ( 200k spartan II E ) that fail when an > Electrostatic discharge occurs. > > I presume that some flip-flop are reseted but not all. That means that my > design fail and is unstable. > > I have set some hardware things to avoid a large part of this problems but > when it occurs I always fail. > > Have you got any Idea to secure the FPGA design itself ? You need to determine if this is Config stream corruption, or Logic-state engine corruption - it sounds like the latter. Also check the energy flows from the static discharge - from where, to where.. State engine corruption with ESD is not uncommon ( and also with relay-contact-noise ) - modern devices can 'see' very narrow pulses : The design needs to have recovery schemes for this. As ESD levels ramp, there will be a range where corruption occurs, but damage does not. Ramp it more, and damage starts... - jgArticle: 47361
Hi, The device on my the Altera board connects to external RAMs and other devices. If all unused pins were left as "outputs driving gnd", would it be a problem if an output pin of another device on the board connected to an APEX pin, which is also set as an output (and driving gnd) ? Since I'm not using the external RAM, I would consider such a pin as unused. I'm not sure if that would be a problem or not. If it is a problem then I will have to go find all such pins and assign them as inputs tristated. Thanks, Prashant Christoph Fritsch <christoph_fritsch@gmx.de> wrote in message news:<3D8F5C5B.6E762EF7@gmx.de>... > Hi Prashant. > > > While compiling my design, I assign RESET and LED output to the correct > > pins on the board. I assume the CLK inputs get assigned correctly by themselves. > Depends on your designflow. If you use DSPBuilder and use the AltLib > elements for the development board, yes! > > > What needs to be done to the unused pins in the Apex20KE device on the > > A15E board ? > > Nothing else. > > > can I go ahead and compile my design with just the 2 > > assignments above and not bother about the rest of the pins assuming > > that the board design has taken care of what happens to the unassigned > > pins. > > If you use the generated scripts (and QuartusII default settings) all > unused > IO will be set to "outputs driving ground". > > If you want to make sure that nothing goes wrong, prepare a script that > configures those pins on the Apex which are meant to be inputs from > other devices (like the ADC) as unused inputs (which will be tristated, > if not used > in the design). All unconnected pins should be left "outputs driving > ground", > which is default for unused pins for Quartus. > > ChristophArticle: 47362
Hi, We tried to install the ISE5.1i on our Sun/Solaris 7 server which has 4GB memory. We are using ISE4.2i (SP3). We got the following error message. % ./setup ld.so.1: /foo/xilsetup: fatal: librt.so.1: version `SUNW_1.2' not found (required by file /foo/xilsetup) Killed ************ setup done! *************** % uname -a SunOS netra000.xxx.com 5.7 Generic_106541-18 sun4u sparc I reported this to Xilinx support. But they replied me that the ISE5.1i was not supported on Solaris 7 (no problem on Solaris 8). Has anybody tried to install the ISE5.1i on Sun/Solaris 7 machine? We cannot move to Solaris 8 at this point because of other CAD software. Any suggestions would be highly appreciated. Best regards, Aki NiimuraArticle: 47363
Hi! I'm using the Xilinx cordic core (v1.0) to calculate the square root during the calculation of an absolute value. the Xilinx-Spec says that the input-value has to be 0 <= X_IN (pos. integer) and the output value is 0 <= X_OUT (pos. integer), "there is no output scaling required". (For details please refer to the specification.) www.xilinx.com/ipcenter/catalog/logicore/docs/cordic.pdf That seemed to be easy, but I just do not understand the results of the calculation. I generated the core for sqrt-calculation with the Xilinx-coregen, 32 bit wide an get the following results (for example): X_IN X_OUT 0x4298436225 0xb5043e2f 0x4294705154 0xb5038929 0x35344 0x84efa3 0x43681 0x93c90b Am I wrong? Do I use the wrong data representation? Any idea would help. Thank you! (and now i hope that I wasn't just blind :-) Thomas WamberaArticle: 47364
"John" <john@tritec.biz> schrieb im Newsbeitrag news:ee78bb0.4@WebX.sUN8CHnE... > Are the GCLK pins fixed to IBUFG's or can they be directed to IBUF's if GCLK pins are required for inputs instead of clocks? You can use the IBUFGs as normal data inputs. But you have to tell the VHDL compiler to do so, or instanciate the IBUFG manually. -- MfG FalkArticle: 47365
It is a bug. Some bugs are harder to isolate than others. This is one of those harder ones because reproducing it required a specific relationship between the original bitstream and the reconfiguration bitstream. It is the case that prior to re-configuring a Spartan2 device, a special sequence of instructions needs to be transmitted to the the chip to effect a safe shutdown. With the 4.2i version of iMPACT (and all of its service packs) a bug was introduced whose effect was to abort the shutdown in the middle. This problem would result in three possible outcomes: (1) a device reconfigures successfully (this appeared to be the usual situation), (2) a device does not load the reconfiguration bitstream (meaning that when iMPACT checks the device status to see if configuration was successful, the device responds that it was because the original configuration bitstream is loaded and active) or (3) the device loads the reconfiguration bitstream but internal conflicts are generated during reconfiguration (between the originally configured bitstream design and the reconfiguration bitstream design). This, too, results in the device indicating that configuration was successful (because the bitstream was loaded correctly and the CRCs matched) but the design does not work because of the conflicts induced. It looks like the postings here have been witness to the situations (2) or (3) described. This bug also applied to Virtex (but not Virtex2) family devices. It was fixed in 5.1iSP1 (service pack 1) which is now available. Please let me know if SP1 does not fix your problem.Article: 47366
Simon wrote: > Peter Alfke wrote: > > Here is the "executive summary" from page 19 of that 218-page report: > > > > After testing devices for millions of device hours at 125 degr C, the > > calculated failure rate at Tj = 55 degr C is between 5 and 30 FIT, where > > one FIT = one failure per billion device hours. > > Millions of hours ? A million hours is ~114 years... I thought there was > generally an "acceleration" involved in the calculation. If so, what are > the systematic error-bars on those estimates ? No, not millions of hours, millions of DEVICE HOURS. So, there are 8172 hours a year, and if you put 1000 devices in a test chamber for a year, you have 8.172 million device hours. That is a pretty good test of running the chips at that temperature, internal power dissipation, etc. It may, or may not, predict the life of the chips under other conditions. For instance, what happens in a system that is powered on intermittently, or the flip-flops and logic only "work" when data is processed, ie. the chip heats up and cools down repeatedly? That wasn't tested in the above sort of accelerated life test (although it probably HAS been tested by the manufacturer.) Anyway, this whole system of MTBF calculations is based on the characteristics of mostly discrete semi systems from the Minuteman and Apollo programs in the 1960s. I have some serious doubts about the correctness of these extrapolations to modern VLSI gear, and other components. But,, I'm very certain, that when you extrapolate MTBF numbers meant for huge systems to ONE single cell phone, for instance, that you are being led astray. The statistical variation becomes meaningless on a sample size of one, so the result that your cell phone should be expected to operate for 5000 years is actually meaningless. I got bent out of shape when IBM (or was it HP?) announced a new line of 5" hard drives with an MTBF of 800,000 hours, which equals almost 100 years. This was stated as if it applied to the entire drive - "the DRIVE'S MTBF was xx hours". Clearly, the spindle bearings can't POSSIBLY last that many revolutions, no matter what kind of bearing they used. Other moving parts would also be suspect, as well as who knows what deteriorating inside the HDA and producing particles. So, I started looking at stated MTBFs on various products, and believing that the numbers produced were totally rediculous. I have been associated with enough electronic and computer gear (and especially computer disk drives) to know that the industry is NOWHERE near these stated reliability levels. Now, some of these drives had clear indications of non- electronic problems, ie. data loss on particular cylinders, and spreading until complete drive failure. But, a number of them were rejuvenated, at least for a final backup, by swapping the main circuit board from another drive. That pretty clearly indicates an electronic failure. I also tended a bunch of 8 mm tape drives, which would suffer electronic problems over time, too. I don't know if the equipment with these high reliability claims were tested under some ideal condition, like lots of air circulation at 20C, instead of a cramped equipment cabinet with minimal airflow. That probably accounts for some of the difference. Well, there's my rant! JonArticle: 47367
"Jérémie WEBER" wrote: > I have a problem with a design ( 200k spartan II E ) that fail when an > Electrostatic discharge occurs. > > I presume that some flip-flop are reseted but not all. That means that my > design fail and is unstable. > > I have set some hardware things to avoid a large part of this problems but > when it occurs I always fail. > > Have you got any Idea to secure the FPGA design itself ? Are you saying the chip configuration is altered? Not too surprising, as the configuration is only stored in CMOS memory cells (flip-flops) on chip. I have had a bunch of (original 5V) Spartan chips popped by several of my customers. I chalked it up to bad ESD precautions, and ignored it. I had an XCS30 blow up on me a couple of days ago, and I'm sure that it was not subject to any heavy ESD event. I powered it up, and a couple seconds after what seemed to be a normal power up, after load OK indicated the config download was successful, the board powered down. I applied external power, and the XCS30 was drawing 1.2 A at 600 mV, and was clearly the part getting hot. ESD damage is so rare at my facility, that I am getting concerned about serious reliability problems in the field with these devices. Does anyone have any comments on their experiences with Xilinx parts, especially? Thanks, JonArticle: 47368
"Christopher Saunter" <christopher.saunter@durham.ac.uk> ha scritto nel messaggio news:ampepb$773$1@sirius.dur.ac.uk... > I have also been learning (to tolerate ;-) VHDL recently. I'm going to hate it. I thought I never saw again that horrible Pascal syntax... :) There are some C-oriented syntesis languages (ABEL, for example), but I think it's more useful to obey the most known and supported standard, which is VHDL (if I'm not wrong - please, tell me I am! :-)). > I've got "Introductory VHDL, From Simulation to Synthesis" > by Sudhakar > Yalamanchili. Thank you! > Having spent a lot of time with the foundation simulator > craating > waveforms in the past, the chapter on creating VHDL > testbenches > was particularly invaliable! I don't know how to build a testbench yet, but I've just felt the power (and the horrible interface) of ModelSIM. Text-based interface and text command macros will be probably much more effective in a long-term period. > 2) Indentation. I know VHDL does not have any inbuilt > indentation > standards, but I am a firm believer than sensibly used > indentation > makes readability, and therefore the ease of spotting / > preventing > errors soars. I agree with you. I'm a C/C++ programmer, so I take a *lot* of care in code styling. :) > After a while doing it the right way becomes second > nature. Thank you for all the advices. -- LorenzoArticle: 47369
This is a multi-part message in MIME format.
------=_NextPart_000_0025_01C2BB30.405790A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
They *will have* should scare you (Xilinx). Most people doubted that =
Altera could deliver Stratix, and they did....and it is a fantastic =
product. They will deliver with this line as well.
From what I can see (and I'm not referring to the useless online blurbs =
from Vice Presidents), this Cyclone product has lots of interest....and =
that makes sense, due to the price targets and the features in Cyclone.
Care to comment on the Xilinx Ships 40 Millionth Spartan Device - =
World's Lowest Cost FPGA P.R that same day? Reactive, I would say.
I'm not "attacking"....but I think we see that Altera has awakened the =
sleeping Giant (Xilinx), and it should make for some great new products =
coming out down the line!
-Xanatos
"Austin Lesea" <austin.lesea@xilinx.com> wrote in message =
news:3D90A1BD.46C477BD@xilinx.com...
Marc,
I will reiterate something Peter has said once before: Altera has =
announced that they will have (note use of the future tense) .......
So comparing an exisiting Spartan IIE product that is selling like =
crazy today (and is the fourth generation Spartan Product) with a =
product that doesn't exist yet at a future technology node is a little =
silly.
Also stating their projected future price per LUT is better than the =
existing price per LUT is silly. Of course: Moore's Law if they =
haven't totally missed the boat (which they are definitely smart enough =
not to do).
Virtex II Pro is the ninth generation FPGA product.
Maybe we have been doing this for awhile, and maybe we have figured =
out what sells, and what works?
Obviously, we can't please absolutely everyone. I appreciate the =
comments, and we always listen to what the customer wants.
Austin
Marc Randolph wrote:
rickman <spamgoeshere4@yahoo.com> wrote in message =
news:<3D8F2B52.9DA16C60@yahoo.com>...
> After taking a quick look at the Cyclone family, I can see they =
are
> taking a slightly different approach than Xilinx.
>
> The Xilinx Spartan II series is based on the Virtex family just as =
the
> Spartan was based on the XC4000. In contrast, it looks like the =
Cyclone
> family is not directly based on any existing Altera family.
>
> Comparing the Spartan II to the Cyclone shows that the Cyclone has =
a
> higher LUT to IO ratio. The Cyclone looks a little more like a
> potential future Spartan III based on the Virtex II family which =
also
> has a high LUT to IO ratio.
>
> SpartanII 2S50E 2S100E 2S150E 2S200E 2S300E
> LUTs 1536 2400 3456 4700 6144
> IOs 182 202 263 289 329
> ratio 8 12 13 16 19
>
> Cyclone EP1C3 EP1C6 EP1C12 EP1C20
> LUTs 2910 5980 12060 20060
> IOs 104 185 249 301
> ratio 28 32 48 67
>
> As it turns out this makes the Cyclone parts very expensive in =
high IO
> count applications. Further, Altera seems to not have small chip =
scale
> packages for the low end of the family. Looks like they really =
tried to
> go for a low price, limited options product line, even more so =
than the
> Spartan II. The high LUT count may prove a benefit for some
> applications though.
From what I've seen, the last 3 or so generations of Altera devices
appear to have higher LUT/IO ratios than the comparible Xilinx =
family.
In general, at least in the telecom industry where I am, I think =
this
is the right direction to be moving and Xilinx appears to have =
finally
figured this out, from the looks of the proposed Spartan III.
Undoubtly, the problem is identifing exactly what features and what
packages to offer for given LUT ranges.
We are constantly bumping up against the largest device in a cost
effective package. IE, we definitely would move to using a larger
Virtex-II (XC2V4000) if it were available in anything smaller than =
an
expensive 1152 pin flip chip package [or the monster 40x40 1.27 mm =
BGA
package]. I realize Xilinx probably has their reasons for the
offerings they have (most likely thermal?), but if they could =
overcome
that, it'd be easy money for them, cause I'll bet there are others =
out
there in the same boat as us.
Same went for the Virtex-E... the 600E was the largest you could get =
in a reasonable cost/size package. The XCV812EM was available, but
not competitively priced. We would have used a large device if =
Xilinx
had offered it in a FG676. Instead, in both the Virtex-II and
Virtex-E, we get to play roulette with MAP and PAR, constaintly
bumping up against random timing violations that differ from run to
run.
Anyone else in the same boat, wishing there were an XC2V4000-FG676 =
[or
actually, just a 3000 with more LUTs, not more BRAM's]?
Marc
Article: 47370Is anyone here using JHDL for FPGA Design? There is no support e-mail address at the Web site www.jhdl.org apart from a mailing list that seems dead.Article: 47371
--------------A871AC1D77972A82F3E60991 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Xanatos, The market is a great thing. Competition is wonderful. Best products win. As for 'scare', that is a strange reaction from an engineer. Personally, I feel challenged to do each product even better than the last, regardless of what Altera is doing. After all, Altera is not the customer. In this market we compete with the ASIC and ASSP suppliers: it is pretty large market, larger than all other PLDs combined. Altera's vision of the market is no less valid, and no more valid than ours. 40 million Spartan devices says it all: we are already very successful in this market, and it is Altera that is reacting to our success. To remind everyone that we were there first is just our way of balancing the marketing "useless blurbs" (your words, not mine). Imitation is the sincerest form of flattery. Now they want to immitate our success in the consumer space. Welcome to telematics, game boxes, hand held devices, set top boxes, and displays (and who knows what else). A whole different space from the line cards, servers, telecom and data switch world. This is the world where the product sales pitch might be "Xilinx just sounds better" or "Xilinx makes the picture look better." Talk about a scarey world..... Austin Xanatos wrote: > They *will have* should scare you (Xilinx). Most people doubted that > Altera could deliver Stratix, and they did....and it is a fantastic > product. They will deliver with this line as well. From what I can see > (and I'm not referring to the useless online blurbs from Vice > Presidents), this Cyclone product has lots of interest....and that > makes sense, due to the price targets and the features in > Cyclone. Care to comment on the Xilinx Ships 40 Millionth Spartan > Device - World's Lowest Cost FPGA P.R that same day? Reactive, I would > say. I'm not "attacking"....but I think we see that Altera has > awakened the sleeping Giant (Xilinx), and it should make for some > great new products coming out down the line! -Xanatos > > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message > news:3D90A1BD.46C477BD@xilinx.com...Marc, > > I will reiterate something Peter has said once before: > Altera has announced that they will have (note use of the > future tense) ....... > > So comparing an exisiting Spartan IIE product that is > selling like crazy today (and is the fourth generation > Spartan Product) with a product that doesn't exist yet at a > future technology node is a little silly. > > Also stating their projected future price per LUT is better > than the existing price per LUT is silly. Of course: > Moore's Law if they haven't totally missed the boat (which > they are definitely smart enough not to do). > > Virtex II Pro is the ninth generation FPGA product. > > Maybe we have been doing this for awhile, and maybe we have > figured out what sells, and what works? > > Obviously, we can't please absolutely everyone. I > appreciate the comments, and we always listen to what the > customer wants. > > Austin > > > Marc Randolph wrote: > > > rickman <spamgoeshere4@yahoo.com> wrote in message > > news:<3D8F2B52.9DA16C60@yahoo.com>... > > > > > After taking a quick look at the Cyclone family, I can > > see they are > > > taking a slightly different approach than Xilinx. > > > > > > The Xilinx Spartan II series is based on the Virtex > > family just as the > > > Spartan was based on the XC4000. In contrast, it looks > > like the Cyclone > > > family is not directly based on any existing Altera > > family. > > > > > > Comparing the Spartan II to the Cyclone shows that the > > Cyclone has a > > > higher LUT to IO ratio. The Cyclone looks a little more > > like a > > > potential future Spartan III based on the Virtex II > > family which also > > > has a high LUT to IO ratio. > > > > > > SpartanII 2S50E 2S100E 2S150E 2S200E 2S300E > > > LUTs 1536 2400 3456 4700 6144 > > > IOs 182 202 263 289 329 > > > ratio 8 12 13 16 19 > > > > > > Cyclone EP1C3 EP1C6 EP1C12 EP1C20 > > > LUTs 2910 5980 12060 20060 > > > IOs 104 185 249 301 > > > ratio 28 32 48 67 > > > > > > As it turns out this makes the Cyclone parts very > > expensive in high IO > > > count applications. Further, Altera seems to not have > > small chip scale > > > packages for the low end of the family. Looks like they > > really tried to > > > go for a low price, limited options product line, even > > more so than the > > > Spartan II. The high LUT count may prove a benefit for > > some > > > applications though. > > > > From what I've seen, the last 3 or so generations of > > Altera devices > > appear to have higher LUT/IO ratios than the comparible > > Xilinx family. > > In general, at least in the telecom industry where I am, > > I think this > > is the right direction to be moving and Xilinx appears to > > have finally > > figured this out, from the looks of the proposed Spartan > > III. > > Undoubtly, the problem is identifing exactly what features > > and what > > packages to offer for given LUT ranges. > > > > We are constantly bumping up against the largest device in > > a cost > > effective package. IE, we definitely would move to using > > a larger > > Virtex-II (XC2V4000) if it were available in anything > > smaller than an > > expensive 1152 pin flip chip package [or the monster 40x40 > > 1.27 mm BGA > > package]. I realize Xilinx probably has their reasons for > > the > > offerings they have (most likely thermal?), but if they > > could overcome > > that, it'd be easy money for them, cause I'll bet there > > are others out > > there in the same boat as us. > > > > Same went for the Virtex-E... the 600E was the largest you > > could get > > in a reasonable cost/size package. The XCV812EM was > > available, but > > not competitively priced. We would have used a large > > device if Xilinx > > had offered it in a FG676. Instead, in both the Virtex-II > > and > > Virtex-E, we get to play roulette with MAP and PAR, > > constaintly > > bumping up against random timing violations that differ > > from run to > > run. > > > > Anyone else in the same boat, wishing there were an > > XC2V4000-FG676 [or > > actually, just a 3000 with more LUTs, not more BRAM's]? > > > > Marc >Article: 47372
I asked around within Xilinx, and here is the best answer I got: It's a software bug. There really is no need to pull PROG Low. Please download the 5.1i Service Pack 1 software from the support.xilinx.com website. This will eliminate the JTAG reconfiguration bug. If you have problems with some other method of reconfiguring, then we need to get details of how you are doing it. Peter Alfke, Xilinx ApplicationsArticle: 47373
Muthu wrote: > Hi all, > > I have a doubt. if we give the RLOC = "X0Y0", it will be passed to the > xilinx's PAR tool through the edif file. is that right? > > Is this a Permenet location of the FF or module whatever may be? or > the PAR tool can move the module or FF location if timing is not > acheived. > > How it will become, Relative Positional Macro.? > > Best regards, > Muthu Hi Muthu, The RLOC is a mapping constraint that defines the relative location for logical elements within the same macro. It gets passed from edif to .ngo, then .ngd during ngdbuild. Map takes the logical .ngd data as input and creates the .ncd physical design which contains the physical macro representation. The macro has no fixed location unless an RLOC_ORIGIN attribute has also been assigned, in which case Map writes a corresponding macro locate constraint to the .pcf (physical constraints file). PAR then takes the .ncd and .pcf files as input and places the macro, maintaining the relative position of the various components, usually slices. For your simple case of X0Y0, keep in mind that if the macro is a single component macro, the RLOCs are used as mapping directive to create that component, but then the macro representation is discarded since there is no further need to maintain any relative positioning in the physical design. No mention of the macro will appear in any of the report files. Regards, BretArticle: 47374
Jon, I agree with everything but your conclusions. I manufactured telecoms equipment for 17 years. One particular "circuit pack" had about 1700 components, and had a FIT rate of 2000. This was pretty darned good based on competing products. We were all wrorried though as we were selling 10's of thousands of these packs, and we were troubled that we would have tons of them coming home, failed. Turns out we had 6 in 5 years fail (real failures, not returns for "no problems found") out of ~ 50,000. That is 6/250,000 hrs. So six unlucky customer shelves had a failure in less than 5 years. the remainder of the ~ 50,000 packs never failed. Sure, there was a constant trickle of boards that came back because they had been dropped, stepped on, kicked across the floor, fried to a crisp when the -48V battery was applied backwards, etc. But that was use beyond the manufacturer's absolute maximum ratings. So a company like Nortel, Lucent, or Alcatel knows what is acceptable, and what will happen just from their vast experience in manufacturing over the years. The math is an exercise meant to indicate a trend. Austin Jon Elson wrote: > Simon wrote: > > > Peter Alfke wrote: > > > Here is the "executive summary" from page 19 of that 218-page report: > > > > > > After testing devices for millions of device hours at 125 degr C, the > > > calculated failure rate at Tj = 55 degr C is between 5 and 30 FIT, where > > > one FIT = one failure per billion device hours. > > > > Millions of hours ? A million hours is ~114 years... I thought there was > > generally an "acceleration" involved in the calculation. If so, what are > > the systematic error-bars on those estimates ? > > No, not millions of hours, millions of DEVICE HOURS. So, there are 8172 > hours a year, and if you put 1000 devices in a test chamber for a year, you > have > 8.172 million device hours. That is a pretty good test of running the chips > at that > temperature, internal power dissipation, etc. It may, or may not, predict > the life of the chips under other conditions. For instance, what happens in > a system that is powered on intermittently, or the flip-flops and logic only > "work" when data is processed, ie. the chip heats up and cools down > repeatedly? > That wasn't tested in the above sort of accelerated life test (although it > probably > HAS been tested by the manufacturer.) > > Anyway, this whole system of MTBF calculations is based on the > characteristics > of mostly discrete semi systems from the Minuteman and Apollo programs in > the 1960s. I have some serious doubts about the correctness of these > extrapolations > to modern VLSI gear, and other components. > > But,, I'm very certain, that when you extrapolate MTBF numbers meant for > huge systems to ONE single cell phone, for instance, that you are being led > astray. > The statistical variation becomes meaningless on a sample size of one, so the > > result that your cell phone should be expected to operate for 5000 years is > actually meaningless. > > I got bent out of shape when IBM (or was it HP?) announced a new line of > 5" hard drives with an MTBF of 800,000 hours, which equals almost 100 > years. This was stated as if it applied to the entire drive - "the DRIVE'S > MTBF > was xx hours". Clearly, the spindle bearings can't POSSIBLY last that many > revolutions, no matter what kind of bearing they used. Other moving parts > would also be suspect, as well as who knows what deteriorating inside the HDA > > and producing particles. So, I started looking at stated MTBFs on various > products, and believing that the numbers produced were totally rediculous. > I have been associated with enough electronic and computer gear (and > especially > computer disk drives) to know that the industry is NOWHERE near these > stated reliability levels. Now, some of these drives had clear indications > of non- > electronic problems, ie. data loss on particular cylinders, and spreading > until > complete drive failure. But, a number of them were rejuvenated, at least for > > a final backup, by swapping the main circuit board from another drive. That > pretty clearly indicates an electronic failure. I also tended a bunch of 8 > mm > tape drives, which would suffer electronic problems over time, too. > > I don't know if the equipment with these high reliability claims were tested > under some ideal condition, like lots of air circulation at 20C, instead of a > > cramped equipment cabinet with minimal airflow. That probably accounts > for some of the difference. > > Well, there's my rant! > > Jon
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