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 4875

Article: 4875
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: Kayvon Irani <kirani@cinenet.net>
Date: Sun, 22 Dec 1996 22:15:11 -0800
Links: << >>  << T >>  << A >>
Hi everyone:

	When I started this question a couple of weeks ago I had no idea I'd get 
	so many responses! Thanks for all the comments. Having read all the comments,
	it was interesting to find out that only one person thought that ASICs would
	be significantly safer than FPGAs ( I guess assuming you'd test either one 	
	throughly before shipping your board). Most of the discussions were centered 	
	around Anti-fuse/Fuse technology Vs. SRAM based technology. Does any one care to 
 	comment on the use of flash or EEPROM/EPROM technology for safety critical
	applications? Would a minimum guaranted data retention of 10 years (in most
	cases) persuade you not to use these parts? What about the reliablity of 	
	flash/EEPROMs used to store your SRAM FPGA data?

	Regards,
	Kayvon Irani
	Los Angeles, Ca
Article: 4876
Subject: Re: Xilinx loading problem?
From: peter@diguserve.com
Date: Mon, 23 Dec 1996 11:45:52 GMT
Links: << >>  << T >>  << A >>

>Well that wouldn't work either, because the filter would make the slower 
>members of the product family unable to configure at 10 MHz. You can't 
>have it both ways.

A Schmitt trigger (not the same thing as a "filter") can easily run
with a say 50MHz clock, and it would prevent the problem on which I
have wasted many hours, namely that even a 300MHz scope may not show
the tiny non-monotonic waveform artefacts which are enough for these
devices to misconfigure. 

It would also make it nice and easy to route a clock all over a board
full of these devices - all you would need to do is drive that clock
from something slow, e.g. a HC gate, or from a RC filter. Presently,
one often cannot do that because a loaded HC output can easily take
>30ns to switch, and that I found is the upper limit for XC3000
reliable loading.

I am not saying that one cannot make these devices load reliably. Of
course one can. It is just that Xilinx have made it unnecessarily
difficult.

Peter.

Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 4877
Subject: New CAD tools for new Xilinx XC6200 FPGA
From: ludwig@inf.ethz.ch (Stefan Ludwig)
Date: 23 Dec 1996 15:47:45 +0100
Links: << >>  << T >>  << A >>
Announcement of Trianus/Hades tools for Xilinx XC6200 FPGA
==========================================================

The Institute for Computer Systems of ETH Zurich is proud to announce the
first publicly available CAD tool suite for the new Xilinx XC6200 FPGA
architecture.

The Trianus/Hades package was developed using the Oberon System over the past
three years by two graduate students, Stephan Gehring and Stefan Ludwig. It
uses and runs under the Oberon System V4 from the Institute for Computer
Systems, ETH Zurich, Switzerland and the Institute for System Software,
University of Linz, Austria. See the text below for a detailed description of
the capabilities of the CAD software.

Go to http://www-cs.inf.ethz.ch/Wirth/CADTools.html#Trianus for more
information and for downloading instructions or use anonymous ftp to
ftp-cs.inf.ethz.ch and go to directory /pub/Trianus

The development of this software was possible due to the open architecture of
the XC6200. It was not developed by Xilinx, Inc. and is different from their
Camelot software for the XC6200.

We would like to thank Xilinx Scotland and Xilinx San Jose for their
continuing support over the past years, without which the development of this
software would not have been possible.

Comments and criticism is welcomed.

Have a nice holiday!

Stefan Ludwig, Stephan Gehring

------------------------------------------------------------------------
Stefan H-M Ludwig                         Institute for Computer Systems
mailto:ludwig@inf.ethz.ch                 ETH Zentrum
http://www.inf.ethz.ch/personal/ludwig    CH-8092 Zurich, Switzerland
Phone: +41-1-632 7301                     Fax: +41-1-632 1307




Trianus/Hades by Stephan Gehring/Stefan Ludwig

The Trianus/Hades software system consists of a suite of tightly integrated
tools for the efficient design and implementation of algorithms for a custom
computing machine. The software is built upon a generic framework for FPGA
circuit design and comprises a compiler for the Lola hardware description
language, a layout editor, a circuit checker, a technology mapper, a placer, a
router, and a bit-stream generator and loader for the Xilinx XC6200
architecture. We argue that a tight coupling of design tools provides a base
for fast iterative and interactive circuit design, a feature which current
systems provide only in a very limited form.


Hardware Description Language Lola by Niklaus Wirth

Lola was designed as a simple, easily learned hardware description language
for describing synchronous, digital circuits. In addition to its use in a
digital design course for second year computer science students at ETH Zurich,
the Institute for Computer Systems uses it as a hardware description language
for describing hardware designs in general and coprocessor applications in
particular. The purpose of Lola is to statically describe the structure and
functionality of hardware components and of the connections between them. A
Lola text is composed of declarations and statements. It describes the
hardware on the gate level in the form of signal assignments. Signals are
combined using operators and assigned to other signals. Signals and the
respective assignments can be grouped together into types. An instance of a
type is a hardware component. Types can be composed of instances of other
types, thereby supporting a hierarchical design style and they can be generic
(e.g. parametrizable with the word-width of a circuit).
Article: 4878
Subject: Re: New CAD tools for new Xilinx XC6200 FPGA
From: walton@emc.com (John Walton)
Date: 23 Dec 1996 11:18:23 -0500
Links: << >>  << T >>  << A >>

>Announcement of Trianus/Hades tools for Xilinx XC6200 FPGA
>==========================================================

Looking at the Trianus Home I see that you supporting
Win95.

Is there a planned port to ..... (dare I say!) Linux?

Thanks
John
Article: 4879
Subject: Integer divide IC
From: cho@newport.ece.uci.edu (Jae Cho)
Date: 23 Dec 1996 16:32:56 GMT
Links: << >>  << T >>  << A >>
I have a H/W design that requires an unsigned integer divider
(20-bit divided by 10-bit integer) running at 13.5MHz.  Does
anyone know off-the-shelf IC that can satisfy such requirement?
Only other option I have, if there is no such IC available, is
to implement non-restoring divide algorithm in FPGA and use
many in parallel.

Thank you in advance.

J Cho

Article: 4880
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: arnief@wu.cse.tek.com (Arnie Frisch)
Date: 23 Dec 1996 16:59:47 GMT
Links: << >>  << T >>  << A >>
In article <32BA3F27.1FDE@churchill.columbiasc.ncr.com> Joe Hinrichs <jhinrich@churchill.columbiasc.ncr.com> writes:
>Arnie Frisch wrote:
>>
>>In article <Pine.BSI.3.91.961217220540.8995A-100000@malasada.lava.net> "Alvin E. Toda" <aet@lava.net> writes:
>>>On 18 Dec 1996, Jan Vorbrueggen wrote:
>>>
>>>>jet@eskimo.com (James Thiele) writes:
>>.....
>>....
>>...
....
...
..
>>Estimating exposure to risk for airline flyers has to be measured in
>>deaths per people-mile to create a normalized statistic.
>>
>>This takes into account both the difference in speed and the difference
>>in numbers of passengers.
>
>Difference in number of passengers is moot since the same fate generally
>applies to all, whether on the highway or in an airplane; your crash is
>simultaneously a couple of hundred other peoples' crash, skewing the
>stats back where they came.  .....

I don't agree the same fate applies to all.  Especially in auto
crashes, not all die in a crash fatal to one.  In air crashes, fatality
ratios vary greatly - though the 100% ones make the most press.  I
would argue that a disproportionate percentage of airline passengers
are fatalities with respect to automobile passengers, and that makes
the human cost of system critical failures higher - when measured in
deaths per people-miles.

Arnold Frisch
Tektronix Laboratories
--------------------------------------------------------
Any ideas or opinions expressed here do not necessarily
reflect the ideas or opinions of my employer.
--------------------------------------------------------
Article: 4881
Subject: Re: Integer divide IC
From: fliptron@netcom.com (Philip Freidin)
Date: Mon, 23 Dec 1996 18:47:59 GMT
Links: << >>  << T >>  << A >>
How about an SA110 (StrongARM processor from DEC), or R4650 or R4640 MIPS 
processor from IDT.


In article <59mc7o$2r0@news.service.uci.edu> cho@newport.ece.uci.edu (Jae Cho) writes:
>I have a H/W design that requires an unsigned integer divider
>(20-bit divided by 10-bit integer) running at 13.5MHz.  Does
>anyone know off-the-shelf IC that can satisfy such requirement?
>Only other option I have, if there is no such IC available, is
>to implement non-restoring divide algorithm in FPGA and use
>many in parallel.
>
>Thank you in advance.
>
>J Cho
>


Article: 4882
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: Ben Mathew <mathew@sgi.com>
Date: Mon, 23 Dec 1996 13:03:01 -0800
Links: << >>  << T >>  << A >>
Gerhard Hoffmann wrote:
> 
> Wayne Turner wrote:
> 
> > >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.
> >
> > Actually, they can.  In flight applications for example, a heavy ion
> > hitting an SRAM cell can cause the value to change and thereby
> > change the functionality of the circuit without being able to
> > detected before the functionality has already changed.
> 
> .. And what if the heavy ion hits a cpu register or a latch in
> the ASIC you have constructed from gates? Won't they flip? Will an


i don't follow the argument.  ignoring fact that you need a higher Qcrit
for FPGA memory cell, i would guess that an FPGA would have a higher
rate of failure than an asic which implements the same function.

the fpga has at least the same number of memory locations, but has the
additional configuration bits...

-- 
ben

Ben Mathew                 http://reality.sgi.com/mathew/mathew.html  
(url)
Silicon Graphics, Inc., MS 10U-552                    mathew@sgi.com
(email) 
2011 North Shoreline Blvd.                              415-933-4241
(voice)
Mountain View, CA 94043                                 415-390-6176  
(fax)
Article: 4883
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: Henry Spencer <henry@zoo.toronto.edu>
Date: Tue, 24 Dec 1996 18:21:20 GMT
Links: << >>  << T >>  << A >>
In article <59edl7$bpa@news.goodnet.com> waynet@goodnet.com (Wayne Turner) writes:
>>It is worth noting that the OTP devices (especially the eprom and eeprom
>>types) are also susceptible to upset by high energy particles/radiation...
>
>I would believe that a hard-programmed device is much less susceptible to 
>upset however.  The energy required to change the value in an EPROM cell would 
>be enormous compared to that needed to change an SRAM cell, I would think.

Note that some of the more complex OTP devices are now reportedly using
SRAM cells internally, with the SRAM loaded from EPROM at powerup.  Just
because it's nonvolatile doesn't mean that no SRAM is involved...
-- 
"We don't care.  We don't have to.  You'll buy     |       Henry Spencer
whatever we ship, so why bother?  We're Microsoft."|   henry@zoo.toronto.edu
Article: 4884
Subject: Re: XLNX M-1
From: "Austin Franklin" <darkroom@ix.netcom.com>
Date: 24 Dec 1996 21:34:19 GMT
Links: << >>  << T >>  << A >>
Not released yet (that I know of...)

Austin Franklin
..darkroom@ix.netcom.com.

CMJsemi <cmjsemi@aol.com> wrote in article
<19961223000800.TAA29566@ladder01.news.aol.com>...
> Has anyone seen the new XLNX M-1 software for the EX family. Any
comments?
> thanks :)
> 
> Chris
> 
Article: 4885
Subject: Re: PCI Bus Based designs using FPGA's
From: "Austin Franklin" <darkroom@ix.netcom.com>
Date: 24 Dec 1996 21:39:39 GMT
Links: << >>  << T >>  << A >>
I have done four PCI designs of my own.  Three target/master, and one burst
target.  Three have been in a Xilinx 4ke, and one in a 4k.  PCI is tough to
implement in an FPGA because of the 33MHz speed requirement.  This
necessitates a lot of manual placement and logic mapping.  It is very easy
to underestimate what it takes to implement a PCI design in an  FPGA....

The PCI interface it self is only about %25 of the work.  The back end
interface is the other %75.  Given this, just buying a canned PCI interface
may end up being more work than doing it from scratch.

Austin Franklin
..darkroom@ix.netcom.com.


Sundar Gopalan <sundar@com21.com> wrote in article
<32BABA56.2781E494@com21.com>...
> In our Fast Ethernet/ATM product we have decided to use the PCI bus as
> our local interconnect. Have any you folks implemented PCI bus based
> designs using some of the dense FPGA's(Altera 10K, Xilinx 4K)?  The
> design is fairly intensive and we ruled out CPLD's due to its limited
> gate count. 
> 
> I appreciate you sharing your experience.
> 
> Thank you
> 
> Sundar
> 
Article: 4886
Subject: Motorola 68HC16 background debugger
From: wctech@why.net (Larry Chen)
Date: 25 Dec 1996 01:51:05 GMT
Links: << >>  << T >>  << A >>
If you are using or going to use 68HC16 microcontroller, you may
be interested to look at HC16BGND, an advanced programmer’s 
interface that helps you to develop, test, and refine your 
assembly language programs for MOTOROLA’s 68HC16 microcontrollers.
The key features include:
- Run under MS Windows
- Interface through PC’s parallel port
- Motorola suggested 10 pin target connector
- Download and debug HC16 assembly language program in S19 or HEX format
- trace through your code by step through or step over
- set up to 100 breakpoints
- On-screen editing of register and data memory
- On-fly assembly of instruction using mnemonics in program memory
- Open infinite Register, Program, and Data windows
- Watch window so that you can watch important variables
- Exchange data through Windows clipboard
- File I/O which can be used to automatically read a hex input file
  into the file and write the result to an output file.
- Easy to use.  Just click on the menu with left mouse or click on 
  the windows’ area.  Everything is self-explained
- Convenient and easy to install due to its parallel port interface.
  You can use laptop to do an on-site demonstration of you products
- Low cost
- 30 day money back guarantee and one year product warranty
For more information or need a demo program,
see http://users.why.net/wctech/hc16bgnd.htm, 
or FTP to FTP.WHY.NET/FTP/PUB/USERS/WCTECH, 
or send email to WCTECH@WHY.NET

Larry Chen
WC Technology
Article: 4887
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: eteam@aracnet.com (bob elkind)
Date: Wed, 25 Dec 1996 02:59:38 -0000
Links: << >>  << T >>  << A >>
Perhaps this begs the issue, perhaps not. Let's pose these
questions:

Who amongst us (in the listening audience) has *experienced*
an unsatisfactory level of reliability in a
[fuse-programmed | SRAM-based] FPGA ?

Of these experiences, which are *unresolved* (i.e. not "fixed")
issues ? [Let's not cloud the issues with problems
appropriately attributable to the designer's "learning curve"
in the use of the devices.]

Are these reliability problems, if identified, attributable
to the FPGA's [SRAM | fuse-programmed] architecture ?

I *have* experienced unreliability problems in an FPGA design,
but the issues were completely unrelated to SRAM vs. fuse
issues.

I *expect* that reliability simply has not been an issue in
practice with *either* type of FPGAs, and the reliability
issue is a question primarily in the eyes of designers who
have not yet gained practical experience (mileage) with the
type of FPGA that they are regarding as "suspect".

Dealing with an issue on a basis of supposition is OK if the
real-world experience is lacking.  As a designer, I *prefer*
dealing with issues based on real-world practical experience,
when possible.

If there *are* real-world experiences of reliability problems
that are fundamental to a given FPGA architecture or technology,
those sorts of issues are proper and interesting subjects for
this newsgroup.

-- Bob Elkind

****************************************************************
Bob Elkind                              mailto:eteam@aracnet.com 
7118 SW Lee Road               part-time fax number:503.357.9001
Gaston, OR 97119           cell:503.709.1985   home:503.359.4903
****** Video processing, R&D, ASIC, FPGA design consulting *****
Article: 4888
Subject: Re: I2C Bus Interface in FPGAs
From: wil@tms.hobby.nl (Wil Taphoorn)
Date: 25 Dec 1996 11:44:00 +0200
Links: << >>  << T >>  << A >>
John L. Smith wrote on 20.12.96 about "Re: I2C Bus Interface in FPGAs":

 >I think that I2C may be of sufficient complexity and commercial
 >interest that even if people have developed one, they are not willing
 >to share.

Not if it's from the makers of...

 > However, if someone has developed something in the meantime, pls
 > let me know too.

Yes, Aloys Schatorje (Philips The Netherlands) did... His examples for  
both receiver and transmitter on a PLC42CA12 are written in SNAP

Try www.semiconductors.philips.com, try to search for 'iic_plc4'.

regards,
wil
--

Article: 4889
Subject: Re: Integer divide IC
From: peter@nowhere.com
Date: Wed, 25 Dec 1996 11:19:41 GMT
Links: << >>  << T >>  << A >>

I assume when you say 13.5MHz you mean you want to get the result in
74ns. This is not easy, since ordinary division will take (at least)
20 clocks, and even a Newton-Raphson division will need maybe 5-10
clocks to do it. And I am not sure of N/R division is worth doing for
such short numbers; certainly for 80-bit stuff it makes a big
difference.

Should be possible in a fast FPGA though. I suggest you look up
division using successive approximation, and other clever ways of
doing it.

What will certainly help a lot with regard to parallelism is if you
can generate multiple clocks, slightly skewed relative to each other.
This will probably have to be done externally. In things like micros
these are done using gate delays but you obviously don't want to do
that in an FPGA.

>I have a H/W design that requires an unsigned integer divider
>(20-bit divided by 10-bit integer) running at 13.5MHz.  Does
>anyone know off-the-shelf IC that can satisfy such requirement?
>Only other option I have, if there is no such IC available, is
>to implement non-restoring divide algorithm in FPGA and use
>many in parallel.


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 4890
Subject: HC16 background debugger
From: wctech@why.net (Larry Chen)
Date: 25 Dec 1996 17:38:06 GMT
Links: << >>  << T >>  << A >>
If you are using or going to use 68HC16 microcontroller, you may
be interested to look at HC16BGND, an advanced programmer’s 
interface that helps you to develop, test, and refine your 
assembly language programs for MOTOROLA’s 68HC16 microcontrollers.
The key features include:
- Run under MS Windows
- Interface through PC’s parallel port
- Motorola suggested 10 pin target connector
- Download and debug HC16 assembly language program in S19 or HEX format
- trace through your code by step through or step over
- set up to 100 breakpoints
- On-screen editing of register and data memory
- On-fly assembly of instruction using mnemonics in program memory
- Open infinite Register, Program, and Data windows
- Watch window so that you can watch important variables
- Exchange data through Windows clipboard
- File I/O which can be used to automatically read a hex input file
  into the file and write the result to an output file.
- Easy to use.  Just click on the menu with left mouse or click on 
  the windows’ area.  Everything is self-explained
- Convenient and easy to install due to its parallel port interface.
  You can use laptop to do an on-site demonstration of you products
- Low cost
- 30 day money back guarantee and one year product warranty
For more information or need a demo program,
see http://users.why.net/wctech/hc16bgnd.htm, 
or FTP to FTP.WHY.NET/FTP/PUB/USERS/WCTECH, 
or send email to WCTECH@WHY.NET

Larry Chen
WC Technology
Article: 4891
Subject: Motorola 68HC16 background debugger
From: wctech@why.net (Larry Chen)
Date: 25 Dec 1996 17:52:50 GMT
Links: << >>  << T >>  << A >>
If you are using or going to use 68HC16 microcontroller, you may
be interested to look at HC16BGND, an advanced programmer’s 
interface that helps you to develop, test, and refine your 
assembly language programs for MOTOROLA’s 68HC16 microcontrollers.
The key features include:
- Run under MS Windows
- Interface through PC’s parallel port
- Motorola suggested 10 pin target connector
- Download and debug HC16 assembly language program in S19 or HEX format
- trace through your code by step through or step over
- set up to 100 breakpoints
- On-screen editing of register and data memory
- On-fly assembly of instruction using mnemonics in program memory
- Open infinite Register, Program, and Data windows
- Watch window so that you can watch important variables
- Exchange data through Windows clipboard
- File I/O which can be used to automatically read a hex input file
  into the file and write the result to an output file.
- Easy to use.  Just click on the menu with left mouse or click on 
  the windows’ area.  Everything is self-explained
- Convenient and easy to install due to its parallel port interface.
  You can use laptop to do an on-site demonstration of you products
- Low cost
- 30 day money back guarantee and one year product warranty
For more information or need a demo program,
see http://users.why.net/wctech/hc16bgnd.htm, 
or FTP to FTP.WHY.NET/FTP/PUB/USERS/WCTECH, 
or send email to WCTECH@WHY.NET

Larry Chen
WC Technology
Article: 4892
Subject: Motorola 68HC16 background debugger
From: wctech@why.net (Larry Chen)
Date: 25 Dec 1996 17:56:02 GMT
Links: << >>  << T >>  << A >>
If you are using or going to use 68HC16 microcontroller, you may
be interested to look at HC16BGND, an advanced programmer’s 
interface that helps you to develop, test, and refine your 
assembly language programs for MOTOROLA’s 68HC16 microcontrollers.
The key features include:
- Run under MS Windows
- Interface through PC’s parallel port
- Motorola suggested 10 pin target connector
- Download and debug HC16 assembly language program in S19 or HEX format
- trace through your code by step through or step over
- set up to 100 breakpoints
- On-screen editing of register and data memory
- On-fly assembly of instruction using mnemonics in program memory
- Open infinite Register, Program, and Data windows
- Watch window so that you can watch important variables
- Exchange data through Windows clipboard
- File I/O which can be used to automatically read a hex input file
  into the file and write the result to an output file.
- Easy to use.  Just click on the menu with left mouse or click on 
  the windows’ area.  Everything is self-explained
- Convenient and easy to install due to its parallel port interface.
  You can use laptop to do an on-site demonstration of you products
- Low cost
- 30 day money back guarantee and one year product warranty
For more information or need a demo program,
see http://users.why.net/wctech/hc16bgnd.htm, 
or FTP to FTP.WHY.NET/FTP/PUB/USERS/WCTECH, 
or send email to WCTECH@WHY.NET

Larry Chen
WC Technology
Article: 4893
Subject: Low $$$ XLNX Kits w Routing
From: "Richard Schwarz" <aaps@erols.com>
Date: 26 Dec 1996 00:05:54 GMT
Links: << >>  << T >>  << A >>
APS now sells the XILINX Foundation series software with its FPGA
development boards. The kits are ideal for new users wanting to get into
XILINX FPGAs. 

http://www.erols.com/aaps/x84.html
Article: 4894
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: waynet@indirect.com (Wayne Turner)
Date: 26 Dec 1996 15:59:20 GMT
Links: << >>  << T >>  << A >>
In article <MPG.d2aa8f5b35bf5b9897c1@nntp.aracnet.com>,
   eteam@aracnet.com (bob elkind) wrote:
>Perhaps this begs the issue, perhaps not. Let's pose these
>questions:
>
>Who amongst us (in the listening audience) has *experienced*
>an unsatisfactory level of reliability in a
>[fuse-programmed | SRAM-based] FPGA ?
>
>Of these experiences, which are *unresolved* (i.e. not "fixed")
>issues ? [Let's not cloud the issues with problems
>appropriately attributable to the designer's "learning curve"
>in the use of the devices.]
>
>Are these reliability problems, if identified, attributable
>to the FPGA's [SRAM | fuse-programmed] architecture ?
>
>I *have* experienced unreliability problems in an FPGA design,
>but the issues were completely unrelated to SRAM vs. fuse
>issues.
>
>I *expect* that reliability simply has not been an issue in
>practice with *either* type of FPGAs, and the reliability
>issue is a question primarily in the eyes of designers who
>have not yet gained practical experience (mileage) with the
>type of FPGA that they are regarding as "suspect".
>
>Dealing with an issue on a basis of supposition is OK if the
>real-world experience is lacking.  As a designer, I *prefer*
>dealing with issues based on real-world practical experience,
>when possible.
>
>If there *are* real-world experiences of reliability problems
>that are fundamental to a given FPGA architecture or technology,
>those sorts of issues are proper and interesting subjects for
>this newsgroup.
>
>-- Bob Elkind

It's a matter of specification.  Perhaps you/ve never done a design where MTBF 
is specified and calculated to see if this spec is met.  As we were discussing 
here, in safety critical applications (such as commercial flight equipment 
that *I* designed), the *probability* of failure is what is measured, even if 
you never have seen such a failure in your life.

Wayne
Article: 4895
Subject: BitStream in Online
From: Khalid Alotaibi <k.alotaibi@qub.ac.uk>
Date: Thu, 26 Dec 1996 17:38:10 +0000
Links: << >>  << T >>  << A >>
Hi All and Good Doing In 1997

   . Is it possible to write C++ program to genetare BitStream file
     for Xilinx XC6200 borad. I mean depending on users requirements
     that C++ program will genetare Bitstream for FPGA configuring
     according the requirements.

     Is it possible? 

.... Thanks All
Mr. Khalid Alotaibi
Queen's Unvirsity of Belfast 
K.Alotaibi@qub.ac.uk
Article: 4896
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: "Romuald K. Andraka" <randraka@erols.com>
Date: Thu, 26 Dec 1996 14:10:46 -0500
Links: << >>  << T >>  << A >>
Wayne Turner wrote:
> Actually, I believe from a physics standpoint that it has to do with the fact
> that SRAM cells in FPGAs are larger then those in memory and therefore require
> more energy to change state.  True, that does make the FPGA SRAM cell have a
> longer write cycle as well, but it is a result of the cell geometry.What I said.  The cells are deliberately made this way to reduce the probability of 
upset.
> 
> 
> Not necessarily before it has impacted your functionality.  If that part of
> your FPGA has been running anything between when the upset occurred and when
> the CRC is complete, then your functionality has been compromised.

The CRC alone obviously will not detect or prevent upsets to a loaded device.  It is 
there to permit you to verify the device got the program you thought you sent.  As 
I've said before, if the function of the device is in a safety critical application, 
then the design must have additional safeguards to ensure any failure will not cause 
"loss of life or limb".  This would be true whether your design is implemented in an 
FPGA or in something else.  The advantage the SRAM FPGA has over OTP and ASIC 
solutions is the ability to test the physical hardware (which consists of an array 
of similar logic cells and an interconnection network) exhaustively.  Actual 
hardware failures can therefore be detected. In the case of the OTP or ASIC, the 
test vectors may or may not be able to detect any failure of the physical hardware. 
In both cases, additional logic is usually required to permit monitoring when the 
circuit is performing its intended function.
> 
> I would believe that a hard-programmed device is much less susceptible to
> upset however.  The energy required to change the value in an EPROM cell would
> be enormous compared to that needed to change an SRAM cell, I would think.

Yes, It does take (in your words) enormously more energy to upset a properly 
programmed EPROM or antifuse cell.  HOwever when that happens, the only recovery is 
reprogramming the device, which may be impossible while it is in-system!  In the 
case of the SRAM part, the upset can be cleared by reloading the configuration. 
Obviuosly the configuration logic is already present in the design.
> 
> I find it hard to believe that all of these engineers designing flight and
> space equipment have been hoodwinked all of these years.  When you are
> talking about failure rates that must be calculated over a 20-year product
> lifespan (i.e. aircraft), it is pretty accepted that ASICs and OTP devices are
> more reliable than SRAM.

I'm not sure of your reference here.  Yes, a hardwired connection is inherently more 
stable than a bit stored in SRAM.  There is no reason the SRAM cell itself would be 
any less reliable than an ASIC or OTP device!  Data (configurations) stored in 
EEPROM, EPROM and Antifuse based devices are all susceptible to degradation over 
time and to incomplete programming.  I've seen several instances of OTP and EPROM 
type devices that verify correctly on the programmer then exhibit programming 
failures within a few months or years.  The vendor analysis of these usually 
indicate a weakly programmed bit.  ASICs are hardwired, so they will not suffer from 
configuration data going bad.  However, they are susceptable to process problems 
that may not show up in device test due to poorly designed test vectors or test 
circuits.  My point is that SRAMs are easily reprogrammed when required, are capable 
of 100% testing, and provide more flexibility for upgrades or repairs than the ASIC 
and OTP approaches.

-Ray Andraka, P.E.  (via remote)
Chairman, the Andraka Consulting Group
401/884-7930   FAX 401/884-7950
email:randraka@ids.net
http://www.ids.net/~randraka
Article: 4897
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: "Romuald K. Andraka" <randraka@erols.com>
Date: Thu, 26 Dec 1996 14:20:08 -0500
Links: << >>  << T >>  << A >>
Wayne Turner wrote:

> Please offer data to support the above statement.  Why would Xilinx SRAM parts
> be 10x more reliable than another SRAM part?I'm not sure about the numbers, but his statement is true regarding the 
integrity of the data stored in the XILINX cell relative to data stored 
in SRAM used in a microprocessor.  The XILINX SRAM cells are 
deliberately designed as slow cells so that more energy is required to 
cause an upset than a conventional SRAM memory (which is designed for 
speed).

> 
> >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.
> 
> Really a moot point, since ASICs don't configure on power up.  They are
> hard-wired.I think the point here is that if a failure occurs in an SRAM FPGA, it 
is often possible to correct or work-around the fault by reprogramming. 
In the case of the ASIC, there are typically no options. This can be 
advantageous in a system (such as a space probe) where there is no 
physical access to the system, but an ability to load new programming 
remotely exists.


-Ray Andraka, P.E. via remote
Chairman, the Andraka Consulting Group
401/884-7930  FAX 401/884-7950
mailto:randraka@ids.net
http://www.ids.net/~randraka
Article: 4898
Subject: Re: Proper target for design
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 26 Dec 1996 12:48:47 -0700
Links: << >>  << T >>  << A >>
I am pretty sure that this can be implemented in an XC3190A or XC3195A.
It might be advisable to use a few non-globally clocked FFs to
demultiplex the 200 MHz data stream to a more convenient 100 MHz.
Or you can go one step further and demultiplex by four and stuff the
data into the dual-port RAMs inside XC4000E CLBs.

If you really need to store 1024 bits, there are no CPLDs that can do
that. Even the biggest have not enough FFs.

Send me more design details, and I'll take it as a challenging
applications effort.I am quite confident that it can be done without
violating the worst-case timing requirements of either XC3100A or
XC4000E. But you have to be willing to use some logic tricks. That's
what makes design engineering exciting  :-).

Peter Alfke, Xilinx Applications
Article: 4899
Subject: Re: Integer divide IC
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 26 Dec 1996 12:58:02 -0700
Links: << >>  << T >>  << A >>
You did not mention whether you can tolerate a pipeline delay. With
pipelining, it is obviously much easier to have high throughput rates,
and - dare I say - FPGAs are ideally suited for pipelined designs, since
they have all these flip-flops...

Peter Alfke, Xilinx Applications.


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