Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 47350

Article: 47350
Subject: fpga comparisons???
From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
Date: Tue, 24 Sep 2002 11:59:29 -0400 (EDT)
Links: << >>  << T >>  << A >>
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

Matt


Article: 47351
Subject: Re: fpga comparisons???
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 24 Sep 2002 09:28:04 -0700
Links: << >>  << T >>  << A >>
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
>
> Matt


Article: 47352
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: mrand@my-deja.com (Marc Randolph)
Date: 24 Sep 2002 09:34:47 -0700
Links: << >>  << T >>  << A >>
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: 47353
Subject: Re: Fast serial interconnect bus using spartan-II
From: "Theron Hicks" <hicksthe@egr.msu.edu>
Date: Tue, 24 Sep 2002 13:19:23 -0400
Links: << >>  << T >>  << A >>

"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 Hicks



Article: 47354
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 24 Sep 2002 10:32:45 -0700
Links: << >>  << T >>  << A >>

--------------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]?
>
>    Marc



Article: 47355
Subject: Re: Spartan II JTAG reconfiguration bug - workaround
From: td@emu.com (Tony Dean)
Date: 24 Sep 2002 10:50:08 -0700
Links: << >>  << T >>  << A >>
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,
-td

Article: 47356
Subject: Re: FPGA fail when Electrostatic discharge Occurs
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 24 Sep 2002 11:19:43 -0700
Links: << >>  << T >>  << A >>
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 WEBER


Article: 47357
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Tue, 24 Sep 2002 19:24:30 +0100
Links: << >>  << T >>  << A >>
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: 47358
Subject: OT: Ulticap/Ultiboard 2001 netlist import failure
From: Bassman59a@yahoo.com (Andy Peters)
Date: 24 Sep 2002 12:00:05 -0700
Links: << >>  << T >>  << A >>
Sorry 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, AZ

Article: 47359
Subject: xilinx demo board
From: "pbpc" <pbpc@yahoo.com>
Date: Tue, 24 Sep 2002 12:50:29 -0700
Links: << >>  << T >>  << A >>
Does anyone know of a xilinx prototype board which has over 200 IO lines
brought out to headers for use.



Article: 47360
Subject: Re: FPGA fail when Electrostatic discharge Occurs
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 25 Sep 2002 07:52:18 +1200
Links: << >>  << T >>  << A >>
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...

 - jg

Article: 47361
Subject: Re: Unused pins in Apex20KE
From: prashantj@usa.net (Prashant)
Date: 24 Sep 2002 13:03:43 -0700
Links: << >>  << T >>  << A >>
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. 
> 
> Christoph

Article: 47362
Subject: Installing ISE5.1i (Alliance) on Solaris 7.
From: akineko@pacbell.net (Aki Niimura)
Date: 24 Sep 2002 13:34:51 -0700
Links: << >>  << T >>  << A >>
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 Niimura

Article: 47363
Subject: Xilinx Cordic Core and Square Root...help
From: Thomas Wambera <thomas@wambera.de>
Date: Tue, 24 Sep 2002 22:44:26 +0200
Links: << >>  << T >>  << A >>
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 Wambera

Article: 47364
Subject: Re: Question about IOB, BUFG, IBUF and IBUG.
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Tue, 24 Sep 2002 23:42:46 +0200
Links: << >>  << T >>  << A >>
"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
Falk




Article: 47365
Subject: Re: Spartan II JTAG reconfiguration bug - workaround
From: Neil Glenn Jacobson <neil.jacobson@xilinx.com>
Date: Tue, 24 Sep 2002 14:45:20 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: MTBF
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Tue, 24 Sep 2002 16:49:07 -0500
Links: << >>  << T >>  << A >>
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


Article: 47367
Subject: Re: FPGA fail when Electrostatic discharge Occurs
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Tue, 24 Sep 2002 16:58:44 -0500
Links: << >>  << T >>  << A >>
"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,

Jon


Article: 47368
Subject: Re: Timing accuracy with Modelsim
From: "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it>
Date: Tue, 24 Sep 2002 22:12:38 GMT
Links: << >>  << T >>  << A >>
"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.

--
Lorenzo



Article: 47369
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: "Xanatos" <fpsbb98@yahoo.com>
Date: Tue, 24 Sep 2002 22:15:32 GMT
Links: << >>  << T >>  << A >>
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: 47370
Subject: JHDL Help
From: "Verilog USER" <tkirke_No_spamxxx@pacbell.net>
Date: Tue, 24 Sep 2002 22:40:02 GMT
Links: << >>  << T >>  << A >>
Is 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
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 24 Sep 2002 15:49:00 -0700
Links: << >>  << T >>  << A >>

--------------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
Subject: Re: Spartan II JTAG reconfiguration bug - workaround
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 24 Sep 2002 15:56:39 -0700
Links: << >>  << T >>  << A >>
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 Applications




Article: 47373
Subject: Re: MAP problem: Trivial RPM fails
From: Bret Wade <bret.wade@xilinx.com>
Date: Tue, 24 Sep 2002 17:22:27 -0600
Links: << >>  << T >>  << A >>


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,
Bret





Article: 47374
Subject: Re: MTBF
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 24 Sep 2002 16:32:31 -0700
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search