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 4850

Article: 4850
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: Ray Andraka <randraka@ids.net>
Date: Thu, 19 Dec 1996 21:17:39 -0800
Links: << >>  << T >>  << A >>
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.
> 
> Read up on single-event upsets in SRAM devices (both memory and logic).
> 
> >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.
> 
> [...]
> 
> See above...

Yes, given enough energy, an SRAM cell in the FPGA array can be upset. 
The point I was making is that upset to the FPGA SRAM cell takes
considerably more energy than the SRAM used for microprocessors to cause
upset.  This is due to the longer write cycle for the FPGA.  The FPGA
cells are deliberately designed with long write cycles to reduce the
probability of upset.  Since microprocessors are fairly well accepted in
safety critical applications, the more stable FPGA cell should also be
acceptable.

In an application that could seriously compromise safety, the design has
to be made fault tolerant regardless of what devices are used.  This may
mean duplicate circuits with voting logic, signal monitoring, extra
circuits for data integrity checking (eg. parity checking or duplicate
data paths) configuration monitoring via readback (in the case of SRAM
FPGAs) or other measures.  The later Xilinx parts do allow a CRC to be
computed on the bitstream to verify the chip got what you thought you
sent (implementation of the CRC is very easy).  Additionally, they offer
the ability to read the actual device state back.  This permits you to
monitor the configuration to catch any cell upsets.

It is worth noting that the OTP devices (especially the eprom and eeprom
types) are also susceptible to upset by high energy particles/radiation.
In those cases, there is nothing that can be done short of
reprogramming, or in some cases replacing the device.  In the case of
the SRAM FPGA, the fix is usually as simple as reloading it.

From all the evidence I have seen to date, the SRAM devices are no less
reliable than the OTP counterparts or dedicated ASICs (and are likely
more reliable due to the degree of testing available).  They do however
offer the significant advantages of easy 100% functional testing,
configuration monitoring and reprogrammability (both for time division
multiplexing of the hardware and for product
upgrades/enhancements/patches)

-Ray Andraka, P.E.
Chairman, the Andraka Consulting Group
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://www.ids.net/~randraka
Article: 4851
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: Ray Andraka <randraka@ids.net>
Date: Thu, 19 Dec 1996 21:57:58 -0800
Links: << >>  << T >>  << A >>
Gerhard Hoffmann wrote:

> So many questions... I'm really glad that a sailplane has no electronic
> flight critical parts.
> 
Then again, you would be shocked to see the insides of the avionics in
my airplane (or any other general aviation plane for that matter).  To
put it bluntly, my PC is designed and constructed better than most of
the avionics gear out there...and to think I stake my life on that
equipment everytime I fly in weather!

-Ray Andraka, P.E.
Chairman, the Andraka Consulting Group
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://www.ids.net/~randraka
Article: 4852
Subject: CPLD / VHDL question
From: rgaupsas@cts.com (Richard Gaupsas)
Date: 20 Dec 1996 07:12:11 GMT
Links: << >>  << T >>  << A >>

I've got a CPLD I've programmed via VHDL. I've inserted a test array
(called test) to make sure some conditionals have been reached. Once
set in a conditional to '1', the test vectors should stay latched until
the system is reset in which case they are reset to '0': 

	p2: process (rst,clk)
	begin
		if (rst='1') then
			.....
			test(2)<='0';
		elsif (rising_edge(clk)) then
			if(oen='0' and irq='0' and ....) then
				....
				test(2)<='1';
			end if;
	end process p2;

However the test vectors keep toggeling even though reset never comes on
again. Am I missing something with respect to how I think VHDL is describing
my circuit? Else can I be pushing the silicon too fast (33Mhz with a part rated
to 100Mhz) resulting in problems or can I have some race condition induced by
poor code, or any other ideas? Functional simulations does not indicate any
problems.

Thanks in advance,
Richard Gaupsas
rgaupsas@cts.com
Article: 4853
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: Joe Hinrichs <jhinrich@churchill.columbiasc.ncr.com>
Date: Fri, 20 Dec 1996 07:24:23 GMT
Links: << >>  << T >>  << A >>
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:
>.....
>....
>...
>..
>>Even here you have the backup of a co-pilot. If you look
>>at the whole system, certainly there are airplane incidents each year
>>but the accident rate is probably a lot lower than the auto accident
>>rate. It's a lot safer to ride a plane than a car.
>
>That is a common misconception combined with an incorrect interpretation
>of statistics.  Traveling a given DISTANCE by commercial airline is safer
>than traveling the same DISTANCE by car.  Traveling for a given TIME on
>a commercial airline is likely to be more dangerous than traveling for the
>same time by car.

This is true if the safety ratio is less than the speed ratio; out on
the
interstate cars hit 60; in the air planes average 500+ knots, or 550
mph.
So at 9 to 1 the risk-per-time ratio would be the same as the speed
ratio.

>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.  As far as difference in risk per mile, it would
help to have a number.  Is the ratio 1.5 to 1, or 10 to 1, or what? - my
Trivial Pursuit search engine is drawing a blank :-(    ....   but I
*think* it's in single digits, which means that minute by minute the
grim
reaper should be less interested when you are in a car.

Interesting factoid: allegedly you'd have to make one takeoff and
landing
every day for 1500 years or so to hit .5 probability of being in a
commercial air crash.  Now, since 40K people die annually in car wrecks,
or roughly one percent of all deaths, you'd have to live about 3500
years
to hit .5 probability of death by auto.  On the other hand, how often do
you use your auto to cover major inter-city distances?  Ahh, apples and
oranges and fruit salad!  Pass the waldorf.

Another death statistic:  300K people's livelihoods depend on growing,
processing, and selling tobacco, not counting the doctors who deal with
the aftereffects; and 300K people die from tobacco related causes each
year.  If your daddy's land won't grow anything else, you have my
sympathy.

>Arnold Frisch
>Tektronix Laboratories
>--------------------------------------------------------
>Any ideas or opinions expressed here do not necessarily
>reflect the ideas or opinions of my employer.
>--------------------------------------------------------

JoeH
Article: 4854
Subject: I2C Bus Interface in FPGAs
From: Stephan Gick <gck@iis.fhg.de>
Date: Fri, 20 Dec 1996 10:16:45 +0100
Links: << >>  << T >>  << A >>
Hi all,
does anybody know application notes of FPGA realizations of a I2C Bus
interface?
Stephan

------------------------------------------------
Stephan Gick
Fraunhofer Institute for Integrated Circuits IIS
Dep. Electronic Systems ESY
Am Weichselgarten 3
D-91058 Erlangen
EMail: gck@iis.fhg.de
-------------------------------------------------
Article: 4855
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: Gerhard Hoffmann <ghf@berlin.snafu.de>
Date: Fri, 20 Dec 1996 03:22:29 -0800
Links: << >>  << T >>  << A >>
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
antifuse blow if a heavy ion produces a local latch up?

How far do you trust your antifuse device programmer? It applies 
voltages that may be lethal to some parts of the device. How many 
parts did you program with it successfully? 10-100-1000-10,000? 
How many of the same type do you need to know that it _really_ works?
Were there programming rejects? Who was the culprit? 
The chip, the computer, the OS, the programmer software? (no, not
you.:-) 
Did it _really_ catch all the programming rejects?

The programmer changes the chip in many places. Did it re-apply a full
set of test patterns for every node or did it just verify that every
fuse
that had to be blasted  looked that way? Is  "The Golden Programmer" 
driven by a MS Windows program?  If not, has anybody else used it
before you?

OTOH i see that SRAM FPGAs can be tested exhaustively without changing
them forever; programming is half a page of C or just a ROM, and
you can verify the program memory any time you want. You may even 
update the hardware if the chip is already in orbit. To me, SRAM FPGAs
look 	quite appealing from a safety point of view.

So many questions... I'm really glad that a sailplane has no electronic
flight critical parts.

Gerhard

--
Gerhard Hoffmann - Engineering Services
               ^ I insist on that second 'n'.
on the air:    DK4XP
in the air:    D-1441,  Bergfalke III, jawoll!
Article: 4856
Subject: Re: Proper target for design
From: gregor.glawitsch@utimaco.co.at (Gregor Glawitsch)
Date: 20 Dec 1996 13:19:34 GMT
Links: << >>  << T >>  << A >>
In article <32B86B88.41C67EA6@redwood.dn.hac.com>, Mark Norton <mnorton@redwood.dn.hac.com> says:
>Hello, first time designer here.
>
>I've got an application that takes a serial 200 MBit/sec data stream
>that has a frame length of about 1024 bits give or take a few,

[snip]

Are you sure that FPGAs / CPLDs fast enough for 200 MBit/s are
available?

We do do stuff with FPGAs (Xilinx) and as far as I know practical
(multi-stage-logic) designs run at, say, 40MHz or 50MHz.

Your app would require 200MHz flipflop toggle rate, and most 
probably counters running at 200MHz. 
Counters tend to have carry propagation delays, at least when
implemented conventionally. 
(Of course there are such things as Omura adders using non-canonical 
number representation, and LFSRs, both of which do not have
the carry propagation problem.)

Just asking, I'm no FPGA expert myself.
(Just ordered the APS FPGA eval board, been following FPGA designs
of a co-worker.)

Gregor Glawitsch          |
Utimaco Safe Concept GmbH | Tel:    ++43 (0)732 655 755 - 33
Europaplatz 6             | Fax:    ++43 (0)732 655 755 - 5
A-4020 Linz, Austria      | E-Mail: Gregor.Glawitsch@utimaco.co.at


Article: 4857
Subject: Re: CPLD / VHDL question
From: Sundar Gopalan <sundar@com21.com>
Date: Fri, 20 Dec 1996 07:54:33 -0800
Links: << >>  << T >>  << A >>
Richard Gaupsas wrote:
> 
> I've got a CPLD I've programmed via VHDL. I've inserted a test array
> (called test) to make sure some conditionals have been reached. Once
> set in a conditional to '1', the test vectors should stay latched until
> the system is reset in which case they are reset to '0':
> 
>         p2: process (rst,clk)
>         begin
>                 if (rst='1') then
>                         .....
>                         test(2)<='0';
>                 elsif (rising_edge(clk)) then
>                         if(oen='0' and irq='0' and ....) then
>                                 ....
>                                 test(2)<='1';
>                         end if;
>         end process p2;
> 
> However the test vectors keep toggeling even though reset never comes on
> again. Am I missing something with respect to how I think VHDL is describing
> my circuit? Else can I be pushing the silicon too fast (33Mhz with a part rated
> to 100Mhz) resulting in problems or can I have some race condition induced by
> poor code, or any other ideas? Functional simulations does not indicate any
> problems.
> 
> Thanks in advance,
> Richard Gaupsas
> rgaupsas@cts.com


I do not know why your "test" toggles. But I think you need to add 
"oen", "irq" and ... to the sensitivity list for the synthesizer to 
interpret the code right.

sundar
Article: 4858
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: waynet@goodnet.com (Wayne Turner)
Date: Fri, 20 Dec 96 16:00:34 GMT
Links: << >>  << T >>  << A >>
In article <32BA2173.5620@ids.net>, Ray Andraka <randraka@ids.net> 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.
>> 
>> Read up on single-event upsets in SRAM devices (both memory and logic).
>> 
>> >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.
>> 
>> [...]
>> 
>> See above...
>
>Yes, given enough energy, an SRAM cell in the FPGA array can be upset. 
>The point I was making is that upset to the FPGA SRAM cell takes
>considerably more energy than the SRAM used for microprocessors to cause
>upset.  This is due to the longer write cycle for the FPGA.  The FPGA
>cells are deliberately designed with long write cycles to reduce the
>probability of upset.  Since microprocessors are fairly well accepted in
>safety critical applications, the more stable FPGA cell should also be
>acceptable.

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.

>In an application that could seriously compromise safety, the design has
>to be made fault tolerant regardless of what devices are used.  This may
>mean duplicate circuits with voting logic, signal monitoring, extra
>circuits for data integrity checking (eg. parity checking or duplicate
>data paths) configuration monitoring via readback (in the case of SRAM
>FPGAs) or other measures.  The later Xilinx parts do allow a CRC to be
>computed on the bitstream to verify the chip got what you thought you
>sent (implementation of the CRC is very easy).  Additionally, they offer
>the ability to read the actual device state back.  This permits you to
>monitor the configuration to catch any cell upsets.

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.

>It is worth noting that the OTP devices (especially the eprom and eeprom
>types) are also susceptible to upset by high energy particles/radiation.
>In those cases, there is nothing that can be done short of
>reprogramming, or in some cases replacing the device.  In the case of
>the SRAM FPGA, the fix is usually as simple as reloading it.

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.

>From all the evidence I have seen to date, the SRAM devices are no less
>reliable than the OTP counterparts or dedicated ASICs (and are likely
>more reliable due to the degree of testing available).  They do however
>offer the significant advantages of easy 100% functional testing,
>configuration monitoring and reprogrammability (both for time division
>multiplexing of the hardware and for product
>upgrades/enhancements/patches)

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.

Wayne
Article: 4859
Subject: PCI Bus Based designs using FPGA's
From: Sundar Gopalan <sundar@com21.com>
Date: Fri, 20 Dec 1996 08:09:58 -0800
Links: << >>  << T >>  << A >>
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: 4860
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: waynet@goodnet.com (Wayne Turner)
Date: Fri, 20 Dec 96 16:11:15 GMT
Links: << >>  << T >>  << A >>
In article <32BA76D5.4590@berlin.snafu.de>, ghf@berlin.snafu.de 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
>antifuse blow if a heavy ion produces a local latch up?

Who knows?  I was merely talking about SRAM susceptibility to an SEU.  Also, 
many flight app processor systems are redundant lock-step systems for those 
reasons.  I suppose one could do the same with an FPGA.

>How far do you trust your antifuse device programmer? It applies 
>voltages that may be lethal to some parts of the device. How many 
>parts did you program with it successfully? 10-100-1000-10,000? 
>How many of the same type do you need to know that it _really_ works?
>Were there programming rejects? Who was the culprit? 
>The chip, the computer, the OS, the programmer software? (no, not
>you.:-) 
>Did it _really_ catch all the programming rejects?

Is this some wacky conspiracy theory?

>The programmer changes the chip in many places. Did it re-apply a full
>set of test patterns for every node or did it just verify that every
>fuse
>that had to be blasted  looked that way? Is  "The Golden Programmer" 
>driven by a MS Windows program?  If not, has anybody else used it
>before you?

Let see; one gunman or many; what about the grassy knoll?

>OTOH i see that SRAM FPGAs can be tested exhaustively without changing
>them forever; programming is half a page of C or just a ROM, and
>you can verify the program memory any time you want. You may even 
>update the hardware if the chip is already in orbit. To me, SRAM FPGAs
>look    quite appealing from a safety point of view.
>
>So many questions... I'm really glad that a sailplane has no electronic
>flight critical parts.

Me too... ;)

Wayne
Article: 4861
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: grobh@nolian.ee.sun.ac.za (Hans Grobler)
Date: 20 Dec 1996 18:40:17 GMT
Links: << >>  << T >>  << A >>
I have been investigating the use of SRAM and/or Anti-Fuse FPGA's in a
Low Earth Orbit satellite, hence the interest in this thread. Some
comments/questions follow:

The only data I could find on FPGA's that have been subjected to radiation
testing have been on the Actel Anti-Fuse FPGA's [IEEE. Transactions on
Nuclear Science, Vol. 43, No. 3, June 1996].

According to that article, the A1280 had a Single Event Dielectric Rupture
(SEDR) rate of 3x10^{-5} per device-year. 

It was also stated that "the eight month Mars Pathfinder primary mission,
which incorporates seventeen flight-critical A1280As in single string
mission critical circuits, has a 99.96% change of not experiencing a SEDR."

During discussions with an Altera representive it became clear that
they have no interrest at all the radiation hardend/tolerant market. Apart
from Actel, Xilinx seems the only other major player in this market?

Does anyone have references on equivilant SRAM tests?

Any ideas to what damage could be caused by a flipped configuration cell?
Internal signal driver contention resulting in driver/device destruction?

--
Hans Grobler <grobh@nolian.ee.sun.ac.za>
Department Electrical & Electronic Engineering
University of Stellenbosch, South Africa
Article: 4862
Subject: Re: Proper target for design
From: chubbard@oneworld.owt.com (Charles W. Hubbard)
Date: Fri, 20 Dec 1996 23:14:59 GMT
Links: << >>  << T >>  << A >>
On 20 Dec 1996 13:19:34 GMT, gregor.glawitsch@utimaco.co.at (Gregor
Glawitsch) wrote:

>In article <32B86B88.41C67EA6@redwood.dn.hac.com>, Mark Norton <mnorton@redwood.dn.hac.com> says:
>>Hello, first time designer here.
>>
>>I've got an application that takes a serial 200 MBit/sec data stream
>>that has a frame length of about 1024 bits give or take a few,
>
>[snip]
>
>Are you sure that FPGAs / CPLDs fast enough for 200 MBit/s are
>available?

For what it's worth an engineer in my group has just finished an FPGA
design using FPGAs from QuickLogic which, under normal operation, is
expected to run at 100MHz.  However, he's tested it to 200MHz without
problems.

C.

Article: 4863
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: David Kessner <dkessner@cyclades.com>
Date: Fri, 20 Dec 1996 15:39:23 -0800
Links: << >>  << T >>  << A >>
Hans Grobler wrote:
> Any ideas to what damage could be caused by a flipped configuration cell?
> Internal signal driver contention resulting in driver/device destruction?

I can think of lots of nasty things that can go wrong...  In particular,
what if an output of the FPGA controls a power transistor or MOSFET.  In
some circuits if two MOSFETs are on at one time the power supply will
short
out.  This would be most distressing to some devices.

Driver/device destruction is "minor damage" compared to the potential 
effects of it's desctruction.  Imagine what'd happen if the steering of
a rocket went out because of a faulty FPGA...

Just a thought...

David Kessner
dkessner@cyclades.com
Article: 4864
Subject: Re: I2C Bus Interface in FPGAs
From: jimmiew@sprynet.com (James West)
Date: Fri, 20 Dec 1996 23:58:06 GMT
Links: << >>  << T >>  << A >>
Stephan Gick <gck@iis.fhg.de> wrote:

>Hi all,
>does anybody know application notes of FPGA realizations of a I2C Bus
>interface?
>Stephan
About a year ago, I considered the same thing. I really looked, and I
didn't find anything. But the more I thought about it, the more I
realized it shouldn't be too hard to do from scratch. Good luck.

>------------------------------------------------
>Stephan Gick
>Fraunhofer Institute for Integrated Circuits IIS
>Dep. Electronic Systems ESY
>Am Weichselgarten 3
>D-91058 Erlangen
>EMail: gck@iis.fhg.de
>-------------------------------------------------


Article: 4865
Subject: Re: PCI Bus Based designs using FPGA's
From: bkwilli@smart.net (Bryan Williams)
Date: Sat, 21 Dec 1996 01:24:53 GMT
Links: << >>  << T >>  << A >>
Actually, Xilinx has a PCI "macro" available.  I believe the target
version is final and available (cost is ~$10,000 I think - I got info
from Hamilton-Hallmark about this but I don't have it in front of me.
Check their web site for more info.).  As far as a PCI bus-master
goes, I'm not sure if they've done that yet.  Perhaps more info is at
Xilinx's home page.  It sounds like you want a bus-master for your
application though, though I suppose a slave approach could also be
used.

Sundar Gopalan <sundar@com21.com> wrote:

>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: 4866
Subject: Re: I2C Bus Interface in FPGAs
From: "John L. Smith" <jsmith@univision.com>
Date: Fri, 20 Dec 1996 18:46:21 -0800
Links: << >>  << T >>  << A >>
Stephan Gick wrote:
> 
> Hi all,
> does anybody know application notes of FPGA realizations of a I2C Bus
> interface?

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. I posted same question a few months back, had no reply.

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

-- 
John L. Smith, Pr. Engr.
Univision Technologies, Inc.
6 Fortune Dr.
Billerica, MA 01821-3917
jsmith@univision.com
Article: 4867
Subject: Xilinx loading problem?
From: cgbi@ionsys.com (Garnet Brace)
Date: 21 Dec 1996 04:46:01 GMT
Links: << >>  << T >>  << A >>
I first posted this to a thread about FPGAs in mission critical
applications where it was inappropriate, For this I apologize.
I would appreciate comments on the following:
	
Fascinating!!   I too have spent many hours trying to fix Xilinx loading
problems. The Xilinx help line glibly suggested that I get a high speed 
scope and look at the CCLK signal for glitches. This is very difficult
to do. 

If someone can point to some good info on the limits required on CCLCK
transition time I would be very grateful.

Is this a case of Xilinx refusing to own up to a known problem?

I guess that's why users have to get together every now and then
to find out about common problems.

                                ... Garnet


In article <32b65809.5741395@news.u-net.com>, peter@nowhere.com says...
> snip <
>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.
>

>
>Peter.
>
>Return address is invalid to help stop junk mail.
>E-mail replies to z80@digiserve.com.


Article: 4868
Subject: Re: CPLD / VHDL question
From: Greg Peek <gpeek@worldnet.att.net>
Date: Sat, 21 Dec 1996 11:29:42 -0700
Links: << >>  << T >>  << A >>
Sundar Gopalan wrote:
> 
> Richard Gaupsas wrote:
> >
> > I've got a CPLD I've programmed via VHDL. I've inserted a test array
> > (called test) to make sure some conditionals have been reached. Once
> > set in a conditional to '1', the test vectors should stay latched until
> > the system is reset in which case they are reset to '0':
> >
> >         p2: process (rst,clk)
> >         begin
> >                 if (rst='1') then
> >                         .....
> >                         test(2)<='0';
> >                 elsif (rising_edge(clk)) then
> >                         if(oen='0' and irq='0' and ....) then
> >                                 ....
> >                                 test(2)<='1';
> >                         end if;
> >         end process p2;
> >
> > However the test vectors keep toggeling even though reset never comes on
> > again. Am I missing something with respect to how I think VHDL is describing
> > my circuit? Else can I be pushing the silicon too fast (33Mhz with a part rated
> > to 100Mhz) resulting in problems or can I have some race condition induced by
> > poor code, or any other ideas? Functional simulations does not indicate any
> > problems.
> >
> > Thanks in advance,
> > Richard Gaupsas
> > rgaupsas@cts.com
> 
> I do not know why your "test" toggles. But I think you need to add
> "oen", "irq" and ... to the sensitivity list for the synthesizer to
> interpret the code right.
> 
> sundar

No, the sensitivity list is correct.

You don't say what tools you are using, but the statement:
                elsif (rising_edge(clk)) then
is suspect to me.  Take out the function and code it directly:
                elsif (clk='1' and clk'event) then

Another thing to do would be to look at whatever report files 
your tool generates to see what you can see about how the design
was implemented.  Is test(2) the output of a flip flop?  Can 
you find out what the synthesized equation/logic is for the input 
to that flip flop?

Finally, look at your signals on the physical system carefully with
a good oscilloscope.  Is there noise on rst?  Is the CPLD in a two-sided 
or (shudder) wire-wrapped proto board?  Check the power/gnd pins for excess
noise.

	Greg
Article: 4869
Subject: Re: Xilinx loading problem?
From: fliptron@netcom.com (Philip Freidin)
Date: Sat, 21 Dec 1996 20:37:42 GMT
Links: << >>  << T >>  << A >>
Xilinx chips do not have loading problems.

The following assumes you are (like me) working with the 1994 data book.

Xilinx documentation, while sufficient on some typical applications, is
poorly presented, has ommissions and errors, has insufficient examples,
and does nothing to address the process of selecting one mode over
another, or the system issues related to designing with high speed
components.

The documentation fails to explain the startup sequence at the end of 
configuration (leading to the "I need a few more clocks to make it work" 
syndrome), fails to explain how the daisy chain works, and the 
interaction with the header ("My done pin doesn't go high"). The poor
description of the relationship between bitstream length, the value of the
length count in the header, the type of startup sequence, and whether you
are using a serial or parallel config mode, and daisy chain of FPGAs and
daisychain of config proms (and some little details related to serial 
config prom reset pin polarity), all conspire to cause problems.

When you figure this stuff out, the devices configure fine, every time,
without any problems.

To make matters worse, designers don't read the manuals, don't check
their timing, and don't think that they need to follow good design 
practice if clock rates are slow (see below). If you shoot yourself in
the foot, don't be surprised if it hurts.

I have worked on over 150 FPGA designs (in the last two years), and ALL 
of them configure correctly each and every time. This is not magic, or 
rocket science. The configuration logic in these chips is a state 
machine. If you give it valid clock and data signals the state machine 
advances from state to state the same way every time, and the end result 
is a configured chip.

If you want to have similar results, may I recomend you carefully read 
pages 2-25 thru 2-30 of the 1994 Xilinx data book, paying close attention 
to the flow chart on page 2-27, the startup options on page 2-29, and
the startup state machine schematic on page 2-30.

In the new data book (1996) there is a better description, on pages 4-54 
thru 4-63, which addresses some of the above issues with the older 
documentation.


The configuration logic is built with the same high speed sub-micron
silicon gates that the rest of the chip is built of. In the faster parts,
the basic flipflops can toggle at better than 200MHz, so the actual
minimum clock low or high times that could cause a flip flop to toggle can
be only a nanosecond or two. That means you need to have clean clock
signals, both rising and falling edges. You do this the same way you do
any other high speed design clock line, appropriately terminated
transmission lines. If you fan a clock line out to multiple destinations,
with out terminations, with stubs, vias, trace width changes, and other
things that make clock signals look crappy, the destination flipflops
don't work the way you want, no matter if they are logic flipflops, CPU
chips, synch-DRAMS, EPLDs, PALs, FPGAs, or configuration logic. 


In article <59fq29$40e@maggie.ionsys.com> cgbi@ionsys.com (Garnet Brace) writes:
>I first posted this to a thread about FPGAs in mission critical
>applications where it was inappropriate, For this I apologize.
>I would appreciate comments on the following:
>	
>Fascinating!!   I too have spent many hours trying to fix Xilinx loading
>problems. The Xilinx help line glibly suggested that I get a high speed 
>scope and look at the CCLK signal for glitches. This is very difficult
>to do. 

You might have thought it was glib, I think it was exactly the right thing
to recomend. If you have intermittently successful configuration, then the
quality of your clock signal is the most common cause of problems. The
fact that you have trouble finding a high speed scope hardly seems to be
Xilinx's fault :-) .  As I wrote above, this is high speed logic, with
toggle rates that can exceed 200MHz. The parts are fast because end users
like you keep asking for faster parts. 

>If someone can point to some good info on the limits required on CCLCK
>transition time I would be very grateful.

An excelent question and unfortunately an example of a most agregious 
ommision from the data book. 

First, some period stuff (from the data book):

Since the configuration data rate can be from DC to 10 MHz, I would 
recomend that clock low and clock high time be no less than 45 nS.

For XC3000, 3000A, 3100, and 3100A, Clock high can be as long as you 
like, but clock low has a maximum of 5 uS. This means that if you are 
bit-banging the clock from a processor, don't take any interrupts while 
clock is low, Or build you hardware so that the clock idle state is high.

For the XC4000, 4000A, 4000H, 4000D, and 4000E, there is no maximum time 
for either clock low or high.

Now, for edge rates (not in the data book):

I would recomend that rising and falling edges be no slower than 20 nS, 
and most importantly, be monotonic! . If you do have slow edges, then the 
above requirement of 45nS clock high time should be from the 90% points, 
and the clock low time should be between 10% points. I.E. if you have 
slow clock edges, you don't get to run at the fastest clock rate.

As for fastest clock edge rates, the answer is as fast as you want, i.e. 
sub 1nS, but still the critical issue is monotonicity!. This means good 
distribution practices, and attention to transmission line issues.

If you dont have monotonic transitions, then the glitches can cause 
additional clock edges to be seen by some (but maybe not all) of the 
flipflops in the configuration logic. This can lead to configuration 
failures.

>Is this a case of Xilinx refusing to own up to a known problem?

I don't think so.

>I guess that's why users have to get together every now and then
>to find out about common problems.
>                                ... Garnet

Or maybe just to be helpful.

>>In article <32b65809.5741395@news.u-net.com>, peter@nowhere.com says...
>>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.

I hope the above is sufficient reason for you :-)

>>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. 

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.

>>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.
>>Peter.

I will say 95%  :-)  so hopefully the above is some help when it happens 
to you.  If you have problems, I will certainly try and help, but you had 
better have a clean clock signal :-)


Philip Freidin
fliptron@netcom.com



Article: 4870
Subject: Re: design should fit, but it doesn't
From: Steve Wiseman <steve@sj.co.uk>
Date: Sun, 22 Dec 1996 10:23:29 +0000
Links: << >>  << T >>  << A >>
Eric Edwards wrote:
> 
> 'Got a design, written in verilog of about 1000 lines. 
> For a variety of reasons, I'm trying to fit this to an Altera Flext 10K10
> FPGA.  Should be easy, right?  3500 gate design, 10000 gate part.  But it
> doesn't fit.  I could understand possibly having routing problems but I'm
> running out of logic cells:  610 vs the 565 cell capacity of the 10k10.

> Any ideas on what could be causing this area explosion?  Better yet,
> suggestions as to what to do about it?

Sounds a lot like you're running without any serious optimisation.
Perhaps _all_ nodes are being preserved, so each of your 3500 ASIC
gates  is being fitted separately. (as in Altera's WYSIWYG mode) Whose
fitter are you using? A quick grovel through the output files ought to
show you what's going on. Altera tech support in the UK are good, don't
know about where you are, but give them a go. After years of Xilinx, I'm
still amazed by how much I can wedge into an Altera part and still have
it run at a sensible speed. 

  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: 4871
Subject: Re: New CAD tools for new Xilinx XC6200 FPGA
From: andym@trend.demon.co.uk (Andrew Morley)
Date: Sun, 22 Dec 96 14:44:43 GMT
Links: << >>  << T >>  << A >>
In article <1996Dec23.111701@emc.com> walton@emc.com "John Walton" writes:

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

Well, the poster said that it runs under Oberon, which certainly is available 
for a wide range of machines (I have it on my Mac), so porting it should be 
quite possible.


-- 
 -----------------------------------------------------------------------------
| Andrew Morley, Design & Development, Trend Communications Ltd, High Wycombe.|
| email: andrew.morley@trendcomms.com  Phone +44 1628-524977        Bucks, UK.|
 -----------------------------------------------------------------------------

Article: 4872
Subject: XLNX M-1
From: cmjsemi@aol.com (CMJsemi)
Date: 23 Dec 1996 00:08:55 GMT
Links: << >>  << T >>  << A >>
Has anyone seen the new XLNX M-1 software for the EX family. Any comments?
thanks :)

Chris
Article: 4873
Subject: Re: ASICs Vs. FPGA in Safety Critical Apps.
From: waynet@indirect.com (Wayne Turner)
Date: 23 Dec 1996 01:00:44 GMT
Links: << >>  << T >>  << A >>
In article <59614k$lh5$2@mhade.production.compuserve.com>,
   Simon <106072.1620@CompuServe.COM> wrote:
>Xilinx FPGAs, although of an SRAM nature are in fact around 10 
>times more reliable than a comparable SRAM part. 

Please offer data to support the above statement.  Why would Xilinx SRAM parts 
be 10x more reliable than another 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.

Really a moot point, since ASICs don't configure on power up.  They are 
hard-wired.

>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.

Does this have a name?

Wayne
Article: 4874
Subject: Re: Anyone tried a FFT in a FPGA?
From: Kayvon Irani <kirani@cinenet.net>
Date: Sun, 22 Dec 1996 21:56:23 -0800
Links: << >>  << T >>  << A >>
To add to your list you may want to check out a product offered
	by Rice Electronics which apparently developped a new way to do
	FFTs optimized for FPGAs and also the tool Atmel is offering tar-
	geted for their reconfigurable FPGAs.

	Regards,
	Kayvon Irani
	Los Angeles, Ca


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