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
2017JanFebMarApr2017

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 4800

Article: 4800
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: Brad Taylor <blt@emf.net>
Date: Mon, 16 Dec 1996 13:26:15 -0800
Links: << >>  << T >>  << A >>
Alasdair MacLean wrote:
> 
> We tend to use antifuse parts (Actel) which are OTP rather
> than SRAM based parts. I'm fairly sure we would not be allowed
> to use SRAM parts in "flight-critical" applications.
> 
> 

Let's just assume:

1-  FPGAs allow you to weed out 'all' the BAD devices
    via extensive device testing.
3-  FPGAs do not ever just flip a program bit randomly.
4-  Loading of configuation data into an FPGA is 100% reliable
    if timing and voltage margins are met.
  
If anyone has any evidence contrary to the above assumptions
I'd like to see it.   

Lets also assume there are 0 bugs in the firmware. 
Folllowing these assumptions, the failures we will be left with will
include real hardware failures over time.

The 9/96 Xilinx data book includes the some curves (page 11-2) for FPGA
failure rates at 70 deg C. These are based on 20,000 devices and
36,000,000 hours of testing.

Here are a few representative data points for 12/95:

XC4000 devices  20 FITS 
XC3000 devices  15 FITS
XC3100 devices   0 FITS 
XC2000 devices   0 FITS

A FIT is a device failure in 1 billion operating hours. I assume this
implies that a system of 100, 10 FIT devices would run for an average of
100 years years before failing due to a hardware failure. The failure
curves are extrapolated from high temperature testing 125-145 deg C.

I wonder if custom devices will have has so much measured testing?

Of course, we have to wonder what to make of such low rates.  The curves
also show the XC3100 curves to be -1 FITS in August of 95.  I am trying 
to determine the physical meaning of this.
-
Brad

Article: 4801
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: "Alvin E. Toda" <aet@lava.net>
Date: Mon, 16 Dec 1996 14:13:57 -1000
Links: << >>  << T >>  << A >>
On Mon, 16 Dec 1996, Randy Tietz wrote:

> DISCLAIMER:  The opinions expressed are my own and do not neccessarily
>   reflect those of my employer.  My experience is in commercial avionics
>   and may not be applicable to other safety critical apps.
> 
> If I had my druthers, I'd also steer away from SRAM-based FPGAs.  It is
> not that they are technically inferior to antifuse parts, but rather
> that
> SRAM-based FPGAs bring with them some extra baggage from a safety
> assessment and reliability perspective.  For safety assessment you have
> to be able to prove to people who don't know all the technical details
> of any particular FPGA technology that bad things won't happen.  The
> fact that the hardware is dynamically configurable immediately raises
> red flags to even the most naive.  Now it is not that you can't make
> a valid argument, it is just that you don't need to make that argument
> with antifuse parts.  From a reliability perspective you also now will
> most likely have two parts to complete the intended function instead
> of just one.  You may also need to add monitoring circuitry to verify
> that everything has been loaded as one would expect.
> 
> Other concerns are the actual configuration time whether it be on power
> up or after a error is detected, the reaction time from when a wrong
> configuration is detected until it is corrected (exposure time), and
> the susceptibility to short power interrupts.
> 
> Don't get me wrong - I KNOW there are SRAM-based FPGAs flying in
> critical
> systems.  It is just my opinion that antifuse FPGAs are easier to design
> into critical systems.

This really gets to the root of the problem. At the design review,
a non-expert would probably feel very uncomfortable that out of all
the perhaps thousands of times the re-loading is done, that for some
reason (which the designer must now put forth) the loading may be in
error. What is more disturbing is that if it is likely to occur at 
least once in the lifetime of the system, why can't it occurr twice
or more times if the conditions persist. Putting these parts in a 
design for critical systems can open up a "can of worms" during the
design review. 

And also perhaps later if system undergoes rigorous 
testing. For example, during shock tests on a shaker table to simulate
dropping the package, the system operation may be inconsistant because
of an FPGA reload-- the analysis of the test result will complicated
and acceptance of the package may be held up.

**************************************************************
Alvin E. Toda				aet@lava.net
sr. engineer				Phone: 1-808-455-1331

2-Sigma			  	WEB: http://www.lava.net/~aet/2-sigma.html
1363-A Hoowali St.
Pearl City, Hawaii, USA

Article: 4802
Subject: ISPD-97 CFP (Dec 20 Submission Deadline)
From: ispd97@jade.cs.Virginia.EDU (1997 International Symposium on Physical Design)
Date: Tue, 17 Dec 1996 00:46:59 GMT
Links: << >>  << T >>  << A >>
=============================================================================

                             Call for Papers

               1997 International Symposium on Physical Design
                             April 14-16, 1997
                          Napa Valley, California

              Sponsored by the ACM SIGDA in cooperation with 
                   IEEE Circuits and Systems Society

   The International Symposium on Physical Design provides a forum to
exchange ideas and promote research on critical areas related to the
physical design of VLSI systems.  All aspects of physical design, from
interactions with behavior- and logic-level synthesis, to back-end
performance analysis and verification, are within the scope of the
Symposium.  Target domains include semi-custom and full-custom IC, MCM
and FPGA based systems.
 
   The Symposium is an outgrowth of the ACM/SIGDA Physical Design
Workshop.  Following its five predecessors, the symposium will
highlight key new directions and leading-edge theoretical and
experimental contributions to the field. Accepted papers will be
published by ACM Press in the Symposium proceedings. Topics of
interest include but are not limited to:

       1. Management of design data and constraints 
       2. Interactions with behavior-level synthesis flows 
       3. Interactions with logic-level (re-)synthesis flows 
       4. Analysis and management of power dissipation 
       5. Techniques for high-performance design 
       6. Floorplanning and building-block assembly 
       7. Estimation and point-tool modeling 
       8. Partitioning, placement and routing 
       9. Special structures for clock, power, or test
      10. Compaction and layout verification
      11. Performance analysis and physical verification 
      12. Physical design for manufacturability and yield 
      13. Mixed-signal and system-level issues.
      
IMPORTANT DATES:    Submission deadline:              December 20, 1996
                    Acceptance notification:          February 1, 1997
                    Camera-ready (6 page limit) due:  March 1, 1997

SUBMISSION OF PAPERS:

    Authors should submit full-length, original, unpublished papers 
    (maximum 20 pages double spaced) along with an abstract of at most 
    200 words and contact author information (name, street/mailing address, 
    telephone/fax, e-mail).

    Electronic submission via uuencoded e-mail is encouraged (single 
    postscript file, formatted for 8 1/2" x 11" paper, compressed with 
    Unix "compress" or "gzip''). Email to:

                        ispd97@ece.nwu.edu

    Alternatively, send ten (10) copies of the paper to:

                        Prof. Majid Sarrafzadeh
                        Technical Program Chair, ISPD-97
                        Dept. of ECE, Northwestern University
                        2145 Sheridan Road, Evanston, IL 60208 USA
                        Tel 847-491-7378 / Fax 847-467-4144 

SYMPOSIUM INFORMATION:

    To obtain information regarding the Symposium or to be added to the
    Symposium mailing list, please send e-mail to ispd97@cs.virginia.edu. 
    Information can also be found on the ISPD-97 web page:   

                         http://www.cs.virginia.edu/~ispd97/

SYMPOSIUM ORGANIZATION:

General Chair:               A. B. Kahng (UCLA and Cadence)
Past Chair:                  G. Robins (Virginia)
Steering Committee:          J. Cohoon (Virginia), S. Dasgupta (Sematech),
                             S. M. Kang (Illinois), B. Preas (Xerox PARC) 
Program Chair:               M. Sarrafzadeh (Northwestern)
Keynote Address:             T. C. Hu (UC San Diego) & E. S. Kuh (UC Berkeley)
Special Address:             R. Camposano (Synopsys)
Publicity Chair:             M. J. Alexander (Washington State)
Local Arrangements Chair:    J. Lillis (UC Berkeley)
Technical Program Committee: C. K. Cheng (UC San Diego)
                             W. W.-M. Dai (UC Santa Cruz) 
                             J. Frankle (Xilinx) 
                             D. D. Hill (Synopsys) 
                             M. A. B. Jackson (Motorola) 
                             J. A. G. Jess (Eindhoven)  
                             Y.-L. Lin (Tsing Hua) 
                             C. L. Liu (Illinois)
                             M. Marek-Sadowska (UC Santa Barbara)
                             M. Sarrafzadeh (Northwestern)
                             C. Sechen (Washington) 
                             K. Takamizawa (NEC)
                             M. Wiesel (Intel) 
                             D. F. Wong (Texas-Austin) 
                             E. Yoffa (IBM)

=============================================================================

Article: 4803
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: "John L. Smith" <jsmith@univision.com>
Date: Mon, 16 Dec 1996 20:07:48 -0800
Links: << >>  << T >>  << A >>
Brad Taylor wrote:
> 
> 
> The 9/96 Xilinx data book includes the some curves (page 11-2) for FPGA
> failure rates at 70 deg C. These are based on 20,000 devices and
> 36,000,000 hours of testing.
> 
> Here are a few representative data points for 12/95:
> 
> XC4000 devices  20 FITS
> XC3000 devices  15 FITS
> XC3100 devices   0 FITS
> XC2000 devices   0 FITS
> 
> A FIT is a device failure in 1 billion operating hours. I assume this
> implies that a system of 100, 10 FIT devices would run for an average of
> 100 years years before failing due to a hardware failure. The failure
> curves are extrapolated from high temperature testing 125-145 deg C.
> 
> I wonder if custom devices will have has so much measured testing?
> 
> Of course, we have to wonder what to make of such low rates.  The curves
> also show the XC3100 curves to be -1 FITS in August of 95.  I am trying
> to determine the physical meaning of this.

-1 FITS : Perfect parts get more perfect, use a bad part for a billion
hours and it will fix itself. Amazing devices ;o)

-- 
John L. Smith, Pr. Engr.     | Sometimes we are inclined to class
Univision Technologies, Inc. | those who are once-and-a-half witted
6 Fortune Dr.                | with the half-witted, because we
Billerica, MA 01821-3917     | appreciate only a third part of their wit.
jsmith@univision.com         | - Henry David Thoreau
Article: 4804
Subject: FPGA market overview
From: Alon Hazay <alon@radnet.co.il>
Date: Tue, 17 Dec 1996 09:37:03 +0200
Links: << >>  << T >>  << A >>
I'm doing an overview of the FPGA market.
Does anyone know a review which compares the FPGA's of the leader
vendors in the market today(ALTERA,XILINX,ACTEL,ORCA etc.)?

Alon Hazay
Article: 4805
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: peter@nowhere.com
Date: Tue, 17 Dec 1996 09:03:30 GMT
Links: << >>  << T >>  << A >>

>the reliability of the part.  Naturally, a system that reloads several
>times in the course of operation has a higher probability of a bad
>load.  However, by utilizing the CRC and readback features, a designer
>can ensure that the load was performed properly.  It is incumbent on the
>designer of the load logic to use these features properly if the
>application demands it. 

This is an understatement, IMO. It is quite easy to have problems with
loading up these devices. I have done a number of (very different)
designs using SRAM-based FPGAs, and have had far more problems than
should have been the case.

One little example, discussed here ad nauseum some months ago: the
edge on CCLK needs to have its transition time within certain limits -
for no obvious reason. Glitches (or whatever) which are not visible on
a 350MHz scope can prevent reliable config. This is on an input which
never sees anything remotely that fast. They could so easily have put
a schmitt trigger in there. 

I know Xilinx will say 99.99999% of their customers never have config
problems, but this is of no help to me when it happens.

I personally have never done any safety-critical systems, but I know
of people who refuse to use SRAM-based FPGAs in them, and *their*
customers also ban their use. 

I think this is somewhat short-sighted because any glitch which can
corrupt an FPGA can equally crash the CPU, as well as any other
digital logic. The designer must ensure these glitches never get
inside the box in the first place, because there is a very small
margin (in terms of the spike's power) between crashing logic and
blowing up logic.

There is one difference however: you can generally detect a corrupted
CPU with a watchdog timer, but you cannot put a watchdog on an FPGA.

>The SRAM based FPGA will usually come through a power anomally better
>than other RAM or even a microprocessor (which can do some screwy things
>under adverse power conditions).  Either way, a power upset that is big
>enough to potentially upset system operation should be dealt with using
>a complete reinitialization. If this is a problem, some steps should be
>taken to fortify the power system to prevent such upsets.

Another understatement :)

I now never use anything less than a TL7705 (power monitor with reset)
and some external gating (HC132) to generate the proper D/P signal
timing, and a low-going *pulse* (rather than just a low level) on
/RST.



Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 4806
Subject: Re: Anyone tried a FFT in a FPGA?
From: Steve Wiseman <steve@sj.co.uk>
Date: Tue, 17 Dec 1996 11:36:09 +0000
Links: << >>  << T >>  << A >>
Simon wrote:
> 
> I am aware that a 40 MSPS 1024-point complex data FFT engine has
> been built using 24 XC4010. The total cost of the silicon is only
> around 2000 and it is faster than a CRAY supercomputer.
> Performance of 10 to 100 times that of a DSP chip is also
> achievable using single devices.

I note that Altera are offering a FFT MegaCore function from December.  
Quotes are 
  "significantly faster than DSP processors and substantially faster
than previously available programmable logic implementations"
  "512 point, 8bit data, 8 bit twiddle, 1150 LEs, 94uS" 
lots of other figures available in the ad, life's too short to retype
them. I'd guess their web page http://www.altera.com will have more
data. 

Please note that I have _no_ idea how fast a hardware FFT _ought_ to go,
so I'm not commenting, just passing on the ad.

A side issue, has anyone out there used any of the AMPP modules?
Success? Nightmare? inbetween?

    Steve
-- 
Steve Wiseman, Senior Systems Engineer, SJ Consulting Ltd, Cambridge, UK
Desk +44 1223 578524 (Fax 578525) Group +44 1223 578518   steve@sj.co.uk
Article: 4807
Subject: Re: Anyone tried a FFT in a FPGA?
From: Simon <106072.1620@CompuServe.COM>
Date: 17 Dec 1996 11:39:01 GMT
Links: << >>  << T >>  << A >>
I am aware that a 40 MSPS 1024-point complex data FFT engine has 
been built using 24 XC4010. The total cost of the silicon is only 
around 2000 and it is faster than a CRAY supercomputer. 
Performance of 10 to 100 times that of a DSP chip is also 
achievable using single devices.

-- 
Simon
106072.1620@Compuserve.com
These opinions are entirely my own and, in keeping with the 
true nature of opinions, are not always valid or rational.
Article: 4808
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: Simon <106072.1620@CompuServe.COM>
Date: 17 Dec 1996 11:45:24 GMT
Links: << >>  << T >>  << A >>
Xilinx FPGAs, although of an SRAM nature are in fact around 10 
times more reliable than a comparable SRAM part. Also it is 
possible to have a system where by in the unlikely event that the 
FPGA fails to power up correctly you can detect it and 
re-initialise it. If you asic develops a fault your buggered.

Also, I am aware of a number of saftey critical systems which 
depend on Xilinx FPGAs. Most notably a well known ship to shore, 
explosive delivery system (Made famouse in the Gulf War) which 
uses Xilinx FPGAs in its guidance system.

-- 
Simon
106072.1620@Compuserve.com
These opinions are entirely my own and, in keeping with the 
true nature of opinions, are not always valid or rational.
Article: 4809
Subject: Re: Fpga, Epld, cpld....
From: Simon <106072.1620@CompuServe.COM>
Date: 17 Dec 1996 11:55:05 GMT
Links: << >>  << T >>  << A >>
Just thought that I aught to point out that despite calling them 
cplds the Altera Flex10k parts do not have the predictable timing 
they claim. In order to fit achieve the desities that they claim 
Altera have had to sacrifice routing resurces to try and keep the 
die size down. As a consequence of this as the routing complexity 
increases the Altera parts start having to use logic cells to 
perform routing functions which adds additional delay and removes 
any sense of predictability that may have been there originally.

As an aside if you look at Altera Flex10K pricing Vs Xilinx 4KE 
pricing you'll see that Altera have accepted that the Flex10K50 
is only really the equivalent of the Xilinx XC4028E in terms of 
usable gates.

-- 
Simon
106072.1620@Compuserve.com
These opinions are entirely my own and, in keeping with the 
true nature of opinions, are not always valid or rational.
Article: 4810
Subject: Re: Xilinx configuration PROM
From: dan.bartram@gtri.gatech.edu (Dan Bartram)
Date: Tue, 17 Dec 96 13:36:39 GMT
Links: << >>  << T >>  << A >>
In article <32b223f4.187444683@news.smart.net>, bkwilli@smart.net (Bryan Williams) wrote:
>Know anything about using Data I/O Unisite to program the Atmel
>17C128's?  I use it but there's a confusing issue - the Atmel, like
>the Xilinx 17128, claims to have a programmable reset polarity.  How
>you specify this is a mystery -- the algorithm mentions the
>programmable polarity, but how you specify it is unclear.  I've been
>just doing the way I did the Xilinx part -- for the 128kbit part, the
>Xilinx algorithm reports a 4004 (hex) device size, the final 4 bytes =
>0 for active-low reset, ff for active-high.  The Atmel reports a 4000
>(hex) device size, no mention of the extra bytes, but once I tried it
>with FF's in the same place the Xilinx expects them - no dice (the
>board was designed for active low reset).   Set them to zeros like the
>Xilinx and it worked.

We use the Data I/O Unisite, and they only way I know to set the polarity
is to manually set it - I didn't change the polarity from the default, so I 
can't say that it actually worked, although perhaps a colleague has done 
this...


****************************************************************************
Dan Bartram, Jr.
Internet:  dan.bartram@gtri.gatech.edu
****************************************************************************
Article: 4811
Subject: Re: Fpga, Epld, cpld....
From: mma@rt66.com (Mark Aaldering)
Date: Tue, 17 Dec 1996 13:58:57 GMT
Links: << >>  << T >>  << A >>
On Thu, 12 Dec 1996 15:47:39 -0700, peter@xilinx.com (Peter Alfke)
wrote:


>EPLDs and CPLDs are derived from the PAL architecture and thus have an
>AND-OR logic structure ( with most of the programmability in the AND array
>) feeding a flip-flop macrocell.
>That means less logic flexibility, but predictable delays, fewer
>flip-flops, but faster compile times than for FPGAs.
>Also, the technology used tends to have substantial static power consumption.

I certainly would like to see what Mr. Alfke can do with his boolean
gates (in SRAM look-up tables) that offers more "logic flexibility"
that PAL / PLA boolean structures. Perhaps he can demonstrate doing a
37-wide full Sum of Products equation in 8nS from external pin-to-pin
like I can in a single macrocell with CoolRunner CPLDs in any of his
FPGA (or CPLD) products. And while most CPLDs (including Xilinx's)
have 'substantial static power consumption' - he is obviously hasn't
seen (or chooses to ignore) our recent introduction that offers 'zero'
static power ( less than 50 microamps) without sacrificing very
deterministic high speeds (6nS pin-to-pin at 5 product terms wide, 8nS
at 37). 

>Altera confuses the issue by calling their SRAM-based FPGA-like families
>"CPLDs" for peculiar, non-technical reasons.

Ah yes - the continuing Altera mis-information...perhaps it is
Xilinx's litigation in progress that caused Altera to call their FPGA
a CPLD...hmmm.

Mark Aaldering
Philips Programmable Products Group
Mark.Aaldering@abq.sc.philips.com
www.coolpld.com

Article: 4812
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: handleym@apple.com (Maynard Handley)
Date: Tue, 17 Dec 1996 06:59:49 -0800
Links: << >>  << T >>  << A >>
In article <32B61C94.54B9@univision.com>, "John L. Smith"
<jsmith@univision.com> wrote:

> > 
> > Of course, we have to wonder what to make of such low rates.  The curves
> > also show the XC3100 curves to be -1 FITS in August of 95.  I am trying
> > to determine the physical meaning of this.
> 
> -1 FITS : Perfect parts get more perfect, use a bad part for a billion
> hours and it will fix itself. Amazing devices ;o)
> 

Bit rot is a known problem. Leave your code and CPU alone and untouched
for a long time and it mysteriously decays. Obviously Xilinx have found a
way to turn this phenomenon to their advantage.

Maynard

-- 
My opinion only
Article: 4813
Subject: Re: Fpga, Epld, cpld....
From: waynet@goodnet.com (Wayne Turner)
Date: Tue, 17 Dec 96 16:05:45 GMT
Links: << >>  << T >>  << A >>
In article <5961mp$lh5$3@mhade.production.compuserve.com>, Simon <106072.1620@CompuServe.COM> wrote:
>Just thought that I aught to point out that despite calling them 
>cplds the Altera Flex10k parts do not have the predictable timing 
>they claim. In order to fit achieve the desities that they claim 
>Altera have had to sacrifice routing resurces to try and keep the 
>die size down. As a consequence of this as the routing complexity 
>increases the Altera parts start having to use logic cells to 
>perform routing functions which adds additional delay and removes 
>any sense of predictability that may have been there originally.

Really?  The Flex 10K has more routing resources both per row and per column 
than its predecessor, the Flex 8000, as well as additional routing resources 
added to every row/column corner to allow more row-to-column connections.  
Feel free to offer data to support your claim of "less routing resources".

>As an aside if you look at Altera Flex10K pricing Vs Xilinx 4KE 
>pricing you'll see that Altera have accepted that the Flex10K50 
>is only really the equivalent of the Xilinx XC4028E in terms of 
>usable gates.

Incredible.  From the Xilinx data book, the 4028E is a 28,000 logic gate 
device or a 32,768 bit RAM device (but don't forget, you can do both because 
CLBs can only be RAM *OR* logic, but not both) with 2560 flops.  The Flex 
10K50 is a 50,000 gate device (there is a white paper available on the 
gate-counting methodology, if you like) with 3184 flops (624 or 25% MORE) PLUS 
you can still use all 20,480 bits of RAM even if all of the logic is used 
(because there is no trade-off in Altera devices: RAM is RAM and LOGIC is 
LOGIC).

So you are saying because Altera will give you a part that has 25% more flops 
PLUS over 20,000 more bits of RAM (when both devices are fully utilized) for 
the same price as the 4028E that it means that Altera considers the devices 
equivalent?

I just call that a better deal...

Wayne
Article: 4814
Subject: How to get MORE ORDERS for ANYTHING you SELL!!!
From: Jim <birdman@pcinternet.com>
Date: Tue, 17 Dec 1996 08:29:59 -0800
Links: << >>  << T >>  << A >>
Would you like to get  MORE ORDERS for ANYTHING YOU SELL?  Do you market 
products/services with your computer? 
 Would you like to learn how to do so QUITE a bit BETTER than what you 
are allready doing?  If so just E-mail
 me the words "MORE ORDERS" and I'll send you a free file that will show 
you how.

Best regards,
Jim  (in California)
Article: 4815
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: jet@eskimo.com (James Thiele)
Date: Tue, 17 Dec 1996 18:02:23 GMT
Links: << >>  << T >>  << A >>
In article <32B61C94.54B9@univision.com> "John L. Smith" <jsmith@univision.com> writes:
>Brad Taylor wrote:
>> 
>> 
>> The 9/96 Xilinx data book includes the some curves (page 11-2) for FPGA
>> failure rates at 70 deg C. These are based on 20,000 devices and
>> 36,000,000 hours of testing.
>> 
>> Here are a few representative data points for 12/95:
>> 
>> XC4000 devices  20 FITS
>> XC3000 devices  15 FITS
>> XC3100 devices   0 FITS
>> XC2000 devices   0 FITS
>> 
>> A FIT is a device failure in 1 billion operating hours. I assume this
>> implies that a system of 100, 10 FIT devices would run for an average of
>> 100 years years before failing due to a hardware failure. The failure
>> curves are extrapolated from high temperature testing 125-145 deg C.
>> 

One expectation in flight critical applications is to have a part
that is not expected to fail during the lifetime of the *fleet* of
planes.  This is much different than one system running 100 years.

The service life of a commercial airliner is typically 50,000 to
100,000 hours.  A production run of 1,000 planes, while high, is
not out of the question, and many avionics systems are shared between
different aircraft models.  (Boeing has delivered or has orders for
about 3,500 737s.)

This leads to a total fleet lifetime of 100,000,000 (10^8) hours.
Thus a 10 FIT part has a significant chance of failing in that
time period.  And it is almost certain that a system of 100 such
parts would fail.  

If the failure of such a part causes the crash of a comercial
airliner even once during the lifetime of the system, I would
consider that unacceptable.

--
James Thiele
jet@eskimo.com

Article: 4816
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: Brad Taylor <blt@emf.net>
Date: Tue, 17 Dec 1996 12:01:42 -0800
Links: << >>  << T >>  << A >>
James Thiele wrote:
> 
>
> One expectation in flight critical applications is to have a part
> that is not expected to fail during the lifetime of the *fleet* of
> planes.  This is much different than one system running 100 years.
> 
> The service life of a commercial airliner is typically 50,000 to
> 100,000 hours.  A production run of 1,000 planes, while high, is
> not out of the question, and many avionics systems are shared between
> different aircraft models.  (Boeing has delivered or has orders for
> about 3,500 737s.)
> 
> This leads to a total fleet lifetime of 100,000,000 (10^8) hours.
> Thus a 10 FIT part has a significant chance of failing in that
> time period.  And it is almost certain that a system of 100 such
> parts would fail.
> 
> If the failure of such a part causes the crash of a comercial
> airliner even once during the lifetime of the system, I would
> consider that unacceptable.
> 

This has got me thinking. Isn't the real problem undetected failures?
With an SRAM based FPGA, the logic can be tested on boot.  This cannot
be done with an ASIC.  Also, it is easy to build redundant systems with 
FPGAs, you just parallel two FPGAs and run only one at a time. Given the
apparent opportunity to increase reliability with intelligent use of
FPGAs,  doesn't it make sense to figure out how to use them, how to
qualify them, and to develop the methodologies necessary. As you say
peoples lives are at stake. 
-
Brad

Article: 4817
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: Scott Kroeger <Scott.Kroeger@mail.mei.com>
Date: Tue, 17 Dec 1996 15:32:11 -0600
Links: << >>  << T >>  << A >>
Brad Taylor wrote:
> 
> James Thiele wrote:
> >
> >
> > One expectation in flight critical applications is to have a part
> > that is not expected to fail during the lifetime of the *fleet* of
> > planes.  This is much different than one system running 100 years.
> >
> > The service life of a commercial airliner is typically 50,000 to
> > 100,000 hours.  A production run of 1,000 planes, while high, is
> > not out of the question, and many avionics systems are shared between
> > different aircraft models.  (Boeing has delivered or has orders for
> > about 3,500 737s.)
> >
> > This leads to a total fleet lifetime of 100,000,000 (10^8) hours.
> > Thus a 10 FIT part has a significant chance of failing in that
> > time period.  And it is almost certain that a system of 100 such
> > parts would fail.
> >
> > If the failure of such a part causes the crash of a comercial
> > airliner even once during the lifetime of the system, I would
> > consider that unacceptable.
> >
> 
> This has got me thinking. Isn't the real problem undetected failures?
> With an SRAM based FPGA, the logic can be tested on boot.  This cannot
> be done with an ASIC.  Also, it is easy to build redundant systems with
> FPGAs, you just parallel two FPGAs and run only one at a time. Given the
> apparent opportunity to increase reliability with intelligent use of
> FPGAs,  doesn't it make sense to figure out how to use them, how to
> qualify them, and to develop the methodologies necessary. As you say
> peoples lives are at stake.
> -

Agreed!

What's wrong with reading back the configuration now and then, just to
make sure everything is OK?  And let's not forget than many of the EPROM
based CPLD's are really SRAM based.  The SRAM switches are loaded at
startup from the EPROM array.  As there is no means of verifying these,
I vastly prefer pure SRAM based devices.  And how many modern peripheral
devices have write-only configuration registers?  How do you know that
these things haven't gone silly?

A little care in the design of a device can mitigate many of the
problems (perhaps even the imagined ones) with the technologies used
therein.

Regards,
Scott
Article: 4818
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: dale@giskard.demon.co.uk (Dale Shuttleworth)
Date: Tue, 17 Dec 1996 22:28:34 GMT
Links: << >>  << T >>  << A >>
Hi,

Despite the references line, I'm not responding to any particular post.

If you're looking at parts in isolation, you are doing something
wrong.  If your FPGA absolutely, positively must not fail then at
some point you are going to end up in court explaining why you placed
peoples lives at the mercy of a single electronic component.

You have to accept that these parts will fail.  You design your system
to accommodate the expected failure rate (plus a safety margin of
course).  If one particular type of device is more prone to failure
then you may require a higher level of redundancy, or a more robust
sanity checking system or whatever...  There is no reason why you
can't use components with a MTBF of 5 minutes, it just means that the
redundancy required probably means your kit is somewhat bigger and
bulkier than you want (and maintenance is probably not cheap either).

What if you decide you can solder the SRAM device to the board, but
you have to put the OTP device in a socket to allow for upgrades?
I bet the SRAM based device suddenly looks a lot more reliable...
(Of course, this ignores where the configuration is actually stored,
but you get the point).

Sure, its nice to know if OTP devices are more reliable when sitting
on their own on the bench doing nothing.  In the end though, it doesn't
actually buy you much.

		Dale.
-- 
**************************************************************************
*  Dale Shuttleworth                                                     *
*  Email: dale@giskard.demon.co.uk                                       *
**************************************************************************
Article: 4819
Subject: Re: FPGA market overview
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 17 Dec 1996 17:28:02 -0700
Links: << >>  << T >>  << A >>
Are you willing to share this overview with us ?
You would get some unbiased or biased opinions, since several of us are
not shy and willing to agree or disagree with you.

I want to say it once more: It is a joy to be a part of this
professional group, where controversial subjects are being discussed in
a reasonably civilized manner. Intelligent people know how to disagree
without getting personal or vulgar about it. Life would be boring if we
all had the same opinion.

Peter Alfke, Xilinx Applications
Article: 4820
Subject: Re: Exemplar's Leonardo on Linux
From: David Emrich <emrich@exemplar.com>
Date: Tue, 17 Dec 1996 19:35:48 -0800
Links: << >>  << T >>  << A >>
Phil Ptkwt Kristin wrote:
> I've heard that Exemplar will release a Linux version of their Leonardo
> synthesis tool for Linux early next year.  Has anyone else heard this?
> It would be good if someone from Exemplar could comment on this.

The port is complete for Leonardo 4.0.3.  Available in January 97.

It's wonderful now to be able to rlogin to a PC and run jobs on it just
like any UNIX workstation.

And getting the EE Times front page (12/9/96), 'What's Hot' was really nice.

I'll just make one minor edit.  EE Times referred to Leonardo as an FPGA
synthesis tool. It is also an ASIC synthesis tool.

> 
> If this is true it is very good news for the Linux engineering community.
> Leonardo is a popular synthesis tool on NT, having it ported to Linux
> could very well be the catalyst that causes other EDA vendors to follow
> suit.
> 
> Also, Exemplar is part of Antares now, which is owned by Mentor.  Can we
> look forward to seeing other Antares family companies (like Model
> Technologies - hint, hint) follow Exemplar's lead?

I think user pressure would be required for that.  As far as MTI is concerned,
a simulator port is more involved than a synthesizer port.  Although Frontline
is already on Linux. And Speedsim.

Regards,
David Emrich
Exemplar Logic
Article: 4821
Subject: Test
From: pec@fastlane.net (Liyong Chen)
Date: 18 Dec 1996 04:14:47 GMT
Links: << >>  << T >>  << A >>
This is a test
Article: 4822
Subject: Jedec file format definition?????
From: brntrout@hypercon.com (F. Wirtz)
Date: Wed, 18 Dec 1996 05:44:02 GMT
Links: << >>  << T >>  << A >>
Help!

I am attempting to create a small device programmer for a CPLD (more for an
academic challenge than anything practical) and I am trying to decipher the
downloadable JEDEC (.jed) file.

I have a programming specification for the CPLD that details the mechanics of
the programming sequence, however it does not provide any details on JEDEC file
interpretation.  So I have the JED file, and the info on how to get binary data
into the part, but I have no way of determining the correct address within the
part from the JED file [ must be an obvious issue and left to the student :) ].

Any help on this would be greatly appreciated.

Regards,

Frank.

P.S.  Yeah, I know this is not an fpga issue, but my news server has no CPLD
groups.  Sigh.... feel free to flame.

Article: 4823
Subject: Re: what is "token chain"?
From: fliptron@netcom.com (Philip Freidin)
Date: Wed, 18 Dec 1996 06:46:21 GMT
Links: << >>  << T >>  << A >>
Symon, (and other interested readers :-)
	Your readings (when you were shorter) were true, and in 
particular, in systems with different clock domains that are asynchronous 
and pass data between them, metastability is indeed unavoidable. If 
you understand the problem and can use devices that have been 
characterized for metastability, you can reduce the probability of 
metastability affecting your system to an acceptable level. An example of 
'acceptable' is 'twice the duration you intend to be working for that 
employer' . In my article I described 3 types of FIFOs, and pointed out 
that the first two have arbiters (the thing that crosses the clock 
domains) and that these are NOT characterized for metastability. 

In the third case (included below), the device is self clocking, and uses
asynchronous state machines to move the data through the fifo. Within
itself, it can't go metastable. It does however present at least two
flags, an input ready, and an output available signal. Assuming that both
the source and destination environments have their own clocks, then they
will need to still deal with metastability on either side of the FIFO,
since it can be thought of as representing a third domain (actually a
fourth too, since the input and output are asynchronous to each other).

I consider this to be better than the first two architectures (for this 
issue), since the management of the metastability is left up to me, and I 
know how to design a suitable level of robustness. So metastability does 
not disappear, it just moves from being inside the FIFO where I can't help
it and it isn't characterized, to outside where it is clearly my domain.

Philip


In article <32B52ADF.7441@wago.de> symon.brewer@wago.de writes:
>Philip,
>	I once read somewhere, when I was little, that metastability was as
>unavoidable as death and taxes. This is something I've always found to
>be true except in the 'trivial' case of fully synchronous systems. (I
>say trivial because almost all systems I've had experience with accept
>data that are not synchronised to the system master clock). I'm kind of
>interested how the fifo system you describe can avoid metastability
>issues if the input and output systems' clocks are not phase locked
>somehow. Otherwise, doesn't any fifo need at least one status flag so
>that the circuitry knows when the register bank is either empty or full?
>		regards, Symon.
>
>Philip Freidin wrote:
>***snipped fifo stuff***
>> Some fifo's are built out of an array of registers, with each register
>> having a validity flag (i.e. the register has valid data in it). These
>> registers are cascaded together (sort of like a shift register), and they
>> autonomously move data from one register to the next, if the current
>> register has valid data and the next does not. the data therefore ripples
>> through the array. All this logic is self clocking. The output basically
>> looks at the last registers validity flag, and the input uses the first
>> registers validity flag. If designed right, this type of fifo does not
>> have metastability issues, unless it includes additional status flags.
>> 
>> The set of validity flags, and their control logic is what you were
>> asking about: "the token chain".
>> 
>> Philip Freidin.
>> 
Article: 4824
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>
Date: 18 Dec 1996 08:42:00 +0100
Links: << >>  << T >>  << A >>
jet@eskimo.com (James Thiele) writes:

> This leads to a total fleet lifetime of 100,000,000 (10^8) hours.
> Thus a 10 FIT part has a significant chance of failing in that
> time period.  And it is almost certain that a system of 100 such
> parts would fail.  
> 
> If the failure of such a part causes the crash of a comercial
> airliner even once during the lifetime of the system, I would
> consider that unacceptable.

Is this a reasonable target, compared to other components of the system
(especially the human part)? That is, aren't we holding the electronic
component to (nuch?) higher standards than the rest of the system, and to much
higher standards than we historically tolerated in a system of this type?

	Jan


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
2017JanFebMarApr2017

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