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 21625

Article: 21625
Subject: Re: FPGA openness
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sun, 26 Mar 2000 22:23:15 -0500
Links: << >>  << T >>  << A >>
Greg Alexander wrote:
> 
> In article <38DE1529.F491AE42@yahoo.com>, Rickman wrote:
> >I stand corrected. I was not aware that Xilinx ever provided support to
> >Neocad users. That would have been very special indeed.
> >
> >But I think my point is still valid. I doubt that anyone would expect
> >Xilinx to provide such support. It would be a far reach of the mind for
> >a user to expect anyone to support the operation of tools that they did
> >not provide. Again, the analogy would be like asking Intel to support
> >the GNU tools.
> 
> Not really, since Intel releases specs to allow the GNU tools to exist.
> The analogy would only be complete if Xilinx opened up their specs.
> Perhaps any company which keeps closed specs /does/ have a responsibility
> to help people who use third party tools developed through reverse
> engineering.  It doesn't make any sense, but it explains why Intel doesn't
> feel responsibility to support GNU tools while Xilinx does feel
> responsibility to support Neocad.

My comments were in the context of what would happen if Xilinx DID
provide the necessary information to build your own bitstream. Peter
indicates that Xilinx (for example) would still have users who are
buying their chips and want support for the bitstream in spite of the
fact that the bitstream was generated by a third party (or a no party?
;) toolset. 

This is a valid point by Xilinx. I may not agree with the need to
provide such support, but the chips are sold by Xilinx and they can sell
them as they please. 

Are the bitstream formats protected by any licence or patent so that
reverse engineering them would be improper or illegal? I can't believe
that it is really such a large job. The internal organization of the
chips are very regular and only a percentage of the chip would have to
be broken down by hand. Many aspects of the format would be rather
trivial if you understood the details of the chip well enough. Talk
about a good way to learn the internals of the chips!

It seems like everyone understands each other pretty well at this point.
At least I think I understand both sides (and the middle). Too bad that
we can't seem to find a solution to the impasse. 

I have not kept up with the various open source tool efforts. I know
they exist and I believe they would not be useful (or as useful) to most
engineers doing work that must get done on schedule and within budget.
Certainly if they provided the capability of generating a bitstream
without the backend tools, they would be just what Greg is looking for.
But I believe they all use the same bitfile generators that the vendors
provide. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 21626
Subject: Re: FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Mon, 27 Mar 2000 04:04:43 GMT
Links: << >>  << T >>  << A >>


Rickman wrote:

>
> One area that Atmel may be very interested in supporting open source
> tools in is finding ways to design partial configuration. The Atmel
> parts are designed so that any rectangular area of the chip (at least on
> the older 6000 series parts) can be reprogrammed on the fly (while the
> rest of the chip is still operating). This is a capability that has been
> very hard to make use of. The main problem is the way that routing tends
> to be hard to keep inside of any given boundries. But this could be a
> very useful feature if the right tools are developed.
>
> You could design chips with logic that changes to match the instructions
> being executed as the instruction is decoded! Talk about code morphing!

You might look at Mike Wirthlin's (BYU) Dynamic Instruction Set Computer (DISC)
paper from about 5 years ago.  It was implemented in a National Clay31, which
is virtually identical to the Atmel 6k.  You can make partial reconfig work in
Atmel, but do expect to do at least the placement by hand.  The Atmel chips
will pretty much keep the routing within the rectangle (most of the routing is
on the nearest neighbor cell connections, so there is little opportunity to go
outside the box), but you do have to be careful about the use of the local and
express busses.  The harder part is to make sure you don't let unrelated
signals cross the rectangle.  Some of the issues are highlighted in my Dynamic
Hardware Video Processor paper, available on my website.  BTW, the 40K also
handles partial reconfiguration in arbitrary rectangular windows, just like the
6K.  If you can find an old machine and a copy of the old interact software, it
still beat the new software hands down for manual place and route
(unfortunately, that is a necessary exercise if you want to really use the 6K
devices anywhere near their potential).

>
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> remove the XY to email me.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21627
Subject: Re: FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Mon, 27 Mar 2000 04:14:14 GMT
Links: << >>  << T >>  << A >>

--------------623E5D40A1E87FF3B25363BF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Rickman wrote:

> But I think my point is still valid. I doubt that anyone would expect
> Xilinx to provide such support. It would be a far reach of the mind for
> a user to expect anyone to support the operation of tools that they did
> not provide. Again, the analogy would be like asking Intel to support
> the GNU tools.
>

Not really, there's a fundamental difference.  When you buy an intel processor, you
know exactly what it's function is and you know the chip works.  With an FPGA, you
have a hardware design in there too, which from what I have seen is more often than
not a poor fit to the FPGA.  That invariably generates the "you say the chips run at
XX MHz, but I can't get my design to run even at XX/10 or 20" calls.  You also get
the "I'm not sure if this is a hardware or software problem" call.  Finally, since
you are the silicon vendor, you get the customer who figures since you have an
interest in selling the chips, you should help him out even if he's using a totally
off the wall design flow.

The poor suckers on the other end of the hot line not only have to know the Xilinx
software, they also have to know the silicon (obvious) as well as all the major
design entry tool flows used to do the designs.  They also need to be diplomatic
when dealing with the really shitty designs (yes there are alot of them out there).
The interface between tools generates a fairly large number of problems/bugs.  Look
at the number of tool-specific answers in the answers database if you need to be
convinced.


--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


--------------623E5D40A1E87FF3B25363BF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>Rickman wrote:
<blockquote TYPE=CITE>But I think my point is still valid. I doubt that
anyone would expect
<br>Xilinx to provide such support. It would be a far reach of the mind
for
<br>a user to expect anyone to support the operation of tools that they
did
<br>not provide. Again, the analogy would be like asking Intel to support
<br>the GNU tools.
<br><a href="http://www.arius.com"></a>&nbsp;</blockquote>
Not really, there's a fundamental difference.&nbsp; When you buy an intel
processor, you know exactly what it's function is and you know the chip
works.&nbsp; With an FPGA, you have a hardware design in there too, which
from what I have seen is more often than not a poor fit to the FPGA.&nbsp;
That invariably generates the "you say the chips run at XX MHz, but I can't
get my design to run even at XX/10 or 20" calls.&nbsp; You also get the
"I'm not sure if this is a hardware or software problem" call.&nbsp; Finally,
since you are the silicon vendor, you get the customer who figures since
you have an interest in selling the chips, you should help him out even
if he's using a totally off the wall design flow.
<p>The poor suckers on the other end of the hot line not only have to know
the Xilinx software, they also have to know the silicon (obvious) as well
as all the major design entry tool flows used to do the designs.&nbsp;
They also need to be diplomatic when dealing with the really shitty designs
(yes there are alot of them out there).&nbsp; The interface between tools
generates a fairly large number of problems/bugs.&nbsp; Look at the number
of tool-specific answers in the answers database if you need to be convinced.
<br>&nbsp;
<p>--
<br>-Ray Andraka, P.E.
<br>President, the Andraka Consulting Group, Inc.
<br>401/884-7930&nbsp;&nbsp;&nbsp;&nbsp; Fax 401/884-7950
<br>email randraka@ids.net
<br><A HREF="http://users.ids.net/~randraka">http://users.ids.net/~randraka</A>
<br>&nbsp;</html>

--------------623E5D40A1E87FF3B25363BF--

Article: 21628
Subject: Re: FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Mon, 27 Mar 2000 04:25:34 GMT
Links: << >>  << T >>  << A >>


muzo wrote:

> Ray,
> Maybe a couple of exceptions. Very small groups who understand the
> technology well can do wonders, my comments were mostly for large
> group efforts. Also I suspect your design is mostly data path in which
> it is little bit easier to generate large gate counts because the
> system is mostly replicated calculations. complex control logic
> development takes more time to develop and verify.
> Also in my experience an FPGA gate is 4 to 5 times less dense than an
> standard cell gate.

I'd argue that the vast majority of million gate designs are going to be
predominantly data path (includes both switching and arithmetic).  If not, you
are probably doing something very wrong.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21629
Subject: Re: Anyone using Philips (now Xilinx) Coolrunner PLDs?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Mon, 27 Mar 2000 16:35:53 +1200
Links: << >>  << T >>  << A >>
Peter wrote:
> 
> I wonder what would happen if Xilinx dropped the range, or just some
> parts?
> 
> What other "zero power" solutions are there? There are the static-CMOS
> FPGAs, at quite high prices especially by the time you include the
> serial EPROM etc.
> 
> I do think someone else makes a "zero power" 22V10, though.

There are a few 'Zero Power' 22V10's. ATMEL, ICT. 

The ATF750CL ( 2 x 22V10) has now ramped, and can be cheaper than some
22V10 'Z's - it has a ~130uA Static Icc.

- jg

-- 
======= 80x51 Tools & IP Specialists  =========
= Want to work smarter than C ?
= http://www.DesignTools.co.nz/modbench.htm
= http://www.DesignTools.co.nz
Article: 21630
Subject: Re: FPGA openness
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 27 Mar 2000 01:54:07 -0500
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> Rickman wrote:
> 
> > But I think my point is still valid. I doubt that anyone would
> > expect
> > Xilinx to provide such support. It would be a far reach of the mind
> > for
> > a user to expect anyone to support the operation of tools that they
> > did
> > not provide. Again, the analogy would be like asking Intel to
> > support
> > the GNU tools.
> 
> Not really, there's a fundamental difference.  When you buy an intel
> processor, you know exactly what it's function is and you know the
> chip works.  With an FPGA, you have a hardware design in there too,
> which from what I have seen is more often than not a poor fit to the
> FPGA.  That invariably generates the "you say the chips run at XX MHz,
> but I can't get my design to run even at XX/10 or 20" calls.  You also
> get the "I'm not sure if this is a hardware or software problem"
> call.  Finally, since you are the silicon vendor, you get the customer
> who figures since you have an interest in selling the chips, you
> should help him out even if he's using a totally off the wall design
> flow.

I disagree that if you are using a third party tool that you would
expect support from Xilinx. If I am using Xilinx software and Xilinx
parts, then I might be willing to call them and say, "Your parts don't
run as fast as you said". But if I am running my own tools from some
other planet, then how could I possibly expect Xilinx to support me? At
that point the only things I could call about would be issues of
configuration or operation that are not related directly to design. 

 
> The poor suckers on the other end of the hot line not only have to
> know the Xilinx software, they also have to know the silicon (obvious)
> as well as all the major design entry tool flows used to do the
> designs.  They also need to be diplomatic when dealing with the really
> shitty designs (yes there are alot of them out there).  The interface
> between tools generates a fairly large number of problems/bugs.  Look
> at the number of tool-specific answers in the answers database if you
> need to be convinced.

Yes, I do have a better realization of the problems of providing support
on such a complex hardware/software product as an FPGA. But I don't know
that the support is always "diplomatic" ;)  I do feel that opening the
bitstream might just releave them of some of the load since more people
would have more knowledge of the internals of the chip and would need
less support to get to where they want to be. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 21631
Subject: Re: FPGA & single point failure
From: "EDM" <edemarchi@hotmail.com>
Date: Mon, 27 Mar 2000 09:08:28 +0200
Links: << >>  << T >>  << A >>
Ok, I think I need to clarify:

"clue point"  stays for  "key point" -- simple mental error, as Greg
Alexander <galexand@sietch.bloomington.in.us> suggested.

and  "redound"  stays for  "make redundant".

Sorry for English. I just translated from italian:-)

I hope that now somebody could help me.

edemarchi@hotmail.com



Article: 21632
Subject: Stimulus generator
From: Jamil Khatib <khatib@ieee.org>
Date: Mon, 27 Mar 2000 09:13:59 +0200
Links: << >>  << T >>  << A >>
Hi
I made a stimulus generator component. This file can be generated
automatically using some graphical interface or text files do you have
any
comments on it. Are there any other good idas?

The file is located at
www.geocities.com/SiliconValley/Pines/6639/files/Stimulus.zip


pls: replay to khatib@ieee.org

Thanks
Jamil Khatib
OpenIP Organization http:/www.openip.org
OpenIPCore Project  http://www.openip.org/oc
OpenCores  Project  http://www.opencores.org


Article: 21633
Subject: Re: Clock on non-dedicate pin
From: Jaroslaw Kubica <jkubica@sigma.krakow.pl>
Date: Mon, 27 Mar 2000 09:02:49 GMT
Links: << >>  << T >>  << A >>
I had similar problem with FPGA Express and Foundation series. I've set in
Express's constraints editor Ports/Global Buffer/DONT USE for this signal.
Maybe it helps you.
Regards
Jarek

spyng@my-deja.com wrote:

> I am using virtex xcv 1000 from Xilinx, and foundation series for
> development.
>
> thanks
> spyng
>
> In article <38DC9ED1.61E4EBFA@sigma.krakow.pl>,
> Jaroslaw Kubica <jkubica@sigma.krakow.pl> wrote:
> > What is the type of your FPGA device and what tools do you use?
> > Regards,
> > Jarek
> >
> > spyng@my-deja.com wrote:
> >
> > > hi,
> > >
> > > other than GCK0-3, is there anyway to have a clock signal without
> > > using dedicate Pin?
> > >
> > > I need to input two external clock to my FPGA board, but
> unfortunately
> > > the board is design such that only one external clock is possible.
> > > So, i am trying to inject the second external clock to a I/O, but
> the
> > > design refuse to map.
> > >
> > > skew of the second clock is not important to me, I just want a clock
> > > in a normal I/O pin!
> > >
> > > thanks
> > > spyng
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> >
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Article: 21634
Subject: Re: Good book on learning FPGA/VHDL/Verilog programming
From: "Holger Kleinert" <Kleinert@ibpmt.com>
Date: Mon, 27 Mar 2000 11:30:58 +0200
Links: << >>  << T >>  << A >>
<iglasner@my-deja.com> schrieb in im Newsbeitrag:
8bdkf7$7co$1@nnrp1.deja.com...
> Hi,
>
>    My recommendation is the "HDL Chip Design" it have examples in
> verilog as well as in Vhdl, also you should consider also buying one
> referance book in Verilog or Vhdl. (if you have openbook you can save
> the verilog book, and maybe Vhdl have something similar)
....... you can buy this book from Doone Publications. www.doone.com
By(t)e
Holger



>
> In article <qJWB4.19073$YU2.424590@typhoon.ne.mediaone.net>,
> pratipm@yahoo.com (Pratip Mukherjee) wrote:
> > I want learn about FPGA and VHDL or Verilog programming. I am planning
> to buy
> > the kit from XESS Corp. along with their book and software. Is that
> sufficient
> > for learning or should I also buy a standard book on the subject? In
> that case
> > which book has good practical examples for the starters to try (which
> are not
> > too simple like blink a LED nor too difficult like design of a 16bit
> RISC
> > processor, as in the recent Circuit Cellar article?
> > Thanks.
> >
> > Pratip Mukherjee
> >
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Article: 21635
Subject: Re: FPGA & single point failure
From: "Kate Atkins" <kate.atkins@siraeo.nospam.co.uk>
Date: Mon, 27 Mar 2000 12:25:37 +0100
Links: << >>  << T >>  << A >>
surely you wouldn't use SRAM based FPGA on space equipment? SEU in the
configuration RAM could completely change the operation of the design,
an input buffer could turn into an output buffer!

You could consider having two FPGAs, just one powered at any one time.
Open collector buffers on outputs (eg LS05 powered off/on with associated
FPGA), series resistors on inputs to limit current seen by input protection
diodes of the powered off FPGA.

If you also have to consider SEU Synplicity has an application note on "safe
statemachines" and one on using Actels rad hard FPGAs.

I believe Actel have one or two of the RT54SX family due with SEU hardened
registers.

Regards


Tom Burgess <tom.burgess@home.com> wrote in message
news:38DDDDED.6FF50630@home.com...
> Yes, Greg's interpretation makes sense. One solution would be to wire 2
> FPGAs in parallel, with independent configuration paths, leaving one
> always unconfigured (tri-state). If the host could detect a fault, it
could
> configure the other one. Of course if any output becomes stuck active,
this
> doesn't work, so you could use CMOS bus switches, but if these break, you
are
> screwed. No wonder space shuttle toilets are so expensive ... but then
they
> have zip-lock baggies to fall back on. (ooof!)
>
> regards, tom
>
> Greg Alexander wrote:
> >
> > In article <38DC94F7.D2D0B8D6@home.com>, Tom Burgess wrote:
> > >Seeing the lack of responses, I can guess that many were mystified by
your
> > >use of the unfamiliar terms "clue point" and "redound". The context is
> > >not sufficient to make them clear, to me at least. What's disconcerting
> > >is that the rest of the message appears to be mostly coherent English.
> >
> > My guess is that "clue point" = "key point" -- simple mental error or
> > perhaps somehow equivalent term (beats me).  And "redound" is probably a
> > synonym for "make redundant," perhaps the word even implies some special
> > method (such as having 3 redundant systems and a comparator).  I would
> > guess that nobody replied because nobody really knows what type of
> > standards he needs in terms of reliability so nobody is confident to say
> > "don't worry about it, just assume the FPGA won't break" or etc.  I
would
> > be very surprised if very many people who have the time to read Usenet
are
> > familiar enough with REALLY critical apps to have much to say to such a
> > general question.
> >
> > >EDM wrote:
> > >>
> > >> I've got a problem with a space mission payload system.  I want to
use a
> > >> FPGA as a clue point of a payload electronic unit. Can anybody
clarify me
> > >> how do I manage the concept of "single point failure tolerant" in the
> > >> system, If I cannot redound the board where this FPGA is included. Do
I
> > >> redound the FPGA itself inside the board? Is it possible? And is it
normally
> > >> foreseen? Or is there anything else that I have to take into account?
Or
> > >> other good solutions that you can suggest me?
> > >>
> > >> Thanks for any advice and suggestion you can give me
> > >>
> > >> --
> > >>
> > >> edemarchi@hotmail.com


Article: 21636
Subject: Communication FPGA & MII
From: Gerhard Griessnig <grie@sbox.tu-graz.ac.at>
Date: Mon, 27 Mar 2000 15:16:08 +0200
Links: << >>  << T >>  << A >>
Hello All !
I am a student and new in this group.
I would like to know, if anybody has already made experiances
with communication between  XILINX and  MII (Medium Independent
Interface ) ??
Does already exist a CORE for this problem ?
Where can i get it ?

Thanks for all informations !

Gerhard

Article: 21637
Subject: Re: FPGA & single point failure
From: Ray Andraka <randraka@ids.net>
Date: Mon, 27 Mar 2000 14:10:34 GMT
Links: << >>  << T >>  << A >>
Kate,

The configuration 'SRAM' in SRAM based FPGAs is not what you would normally
consider an SRAM cell, rather it is a D register that is considerably more
robust than the D registers in your design and orders of magnitude more robust
than the SRAM hanging off the microprocessor.  The readback capability can be
exploited to effect a continuous non-invasive health monitoring so that a reload
can be done when the configuration does get upset.  I've got a current Virtex
design that will be going into space in a year or two.

Kate Atkins wrote:

> surely you wouldn't use SRAM based FPGA on space equipment? SEU in the
> configuration RAM could completely change the operation of the design,
> an input buffer could turn into an output buffer!
>
> You could consider having two FPGAs, just one powered at any one time.
> Open collector buffers on outputs (eg LS05 powered off/on with associated
> FPGA), series resistors on inputs to limit current seen by input protection
> diodes of the powered off FPGA.
>
> If you also have to consider SEU Synplicity has an application note on "safe
> statemachines" and one on using Actels rad hard FPGAs.
>
> I believe Actel have one or two of the RT54SX family due with SEU hardened
> registers.
>
> Regards
>
> Tom Burgess <tom.burgess@home.com> wrote in message
> news:38DDDDED.6FF50630@home.com...
> > Yes, Greg's interpretation makes sense. One solution would be to wire 2
> > FPGAs in parallel, with independent configuration paths, leaving one
> > always unconfigured (tri-state). If the host could detect a fault, it
> could
> > configure the other one. Of course if any output becomes stuck active,
> this
> > doesn't work, so you could use CMOS bus switches, but if these break, you
> are
> > screwed. No wonder space shuttle toilets are so expensive ... but then
> they
> > have zip-lock baggies to fall back on. (ooof!)
> >
> > regards, tom
> >
> > Greg Alexander wrote:
> > >
> > > In article <38DC94F7.D2D0B8D6@home.com>, Tom Burgess wrote:
> > > >Seeing the lack of responses, I can guess that many were mystified by
> your
> > > >use of the unfamiliar terms "clue point" and "redound". The context is
> > > >not sufficient to make them clear, to me at least. What's disconcerting
> > > >is that the rest of the message appears to be mostly coherent English.
> > >
> > > My guess is that "clue point" = "key point" -- simple mental error or
> > > perhaps somehow equivalent term (beats me).  And "redound" is probably a
> > > synonym for "make redundant," perhaps the word even implies some special
> > > method (such as having 3 redundant systems and a comparator).  I would
> > > guess that nobody replied because nobody really knows what type of
> > > standards he needs in terms of reliability so nobody is confident to say
> > > "don't worry about it, just assume the FPGA won't break" or etc.  I
> would
> > > be very surprised if very many people who have the time to read Usenet
> are
> > > familiar enough with REALLY critical apps to have much to say to such a
> > > general question.
> > >
> > > >EDM wrote:
> > > >>
> > > >> I've got a problem with a space mission payload system.  I want to
> use a
> > > >> FPGA as a clue point of a payload electronic unit. Can anybody
> clarify me
> > > >> how do I manage the concept of "single point failure tolerant" in the
> > > >> system, If I cannot redound the board where this FPGA is included. Do
> I
> > > >> redound the FPGA itself inside the board? Is it possible? And is it
> normally
> > > >> foreseen? Or is there anything else that I have to take into account?
> Or
> > > >> other good solutions that you can suggest me?
> > > >>
> > > >> Thanks for any advice and suggestion you can give me
> > > >>
> > > >> --
> > > >>
> > > >> edemarchi@hotmail.com

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21638
Subject: Digital Filters
From: sramsden@my-deja.com
Date: Mon, 27 Mar 2000 14:38:05 GMT
Links: << >>  << T >>  << A >>
Anyone have any good sugestions on a good
book/internet site on information on Digital
filter design??
Thanks,

Stan Ramsden


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21639
Subject: Re: FPGA & single point failure
From: Greg Neff <gregneff@my-deja.com>
Date: Mon, 27 Mar 2000 14:54:56 GMT
Links: << >>  << T >>  << A >>
In article <38df064e.0@etsv0008>,
"EDM" <edemarchi@hotmail.com> wrote:
> Ok, I think I need to clarify:
>
> "clue point" stays for "key point" -- simple mental error, as Greg
> Alexander <galexand@sietch.bloomington.in.us> suggested.
>
> and "redound" stays for "make redundant".
>
> Sorry for English. I just translated from italian:-)
>
> I hope that now somebody could help me.
>
> edemarchi@hotmail.com
>
>

(begin paraphrase)

I've got a problem with a space mission payload system.  I want to use
a FPGA as a key point of a payload electronic unit. Can anybody clarify
how I manage the concept of "single point failure tolerant" in the
system, If I cannot make the board redundant where this FPGA is
included. Do I make the FPGA itself redundant inside the board? Is it
possible? And is it normally foreseen? Or is there anything else that I
have to take into account? Or other good solutions that you can suggest
to me?

Thanks for any advice and suggestion you can give me

(end paraphrase)


I'm not an expert in this area, but I do have some experience.  Mission
critical fly-by-wire avionics systems that I have been involved with
are triplicated (i.e. three identical systems), with 2 out of 3 voting
at the actuator level.

In my experience, single redundancy is not generally considered to be
acceptable, since you get into a situation where you don't know which
of the two systems to trust.  Also, you have to do a thorough FMEA
(failure modes and effects analysis) to understand what can happen, and
you have to identify and eliminate latent failure modes.

Again, my experience is with transportation and avionics, and not with
space systems.  I can imagine that the size, weight, and power
restrictions could make redundant systems impractical.  However, if
your spec says that you have to tolerate any one single point of
failure, then you may not have a choice.

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21640
Subject: Re: FPGA & single point failure
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Mon, 27 Mar 2000 08:42:55 -0700
Links: << >>  << T >>  << A >>
Greg Neff wrote:
 
> Again, my experience is with transportation and avionics, and not with
> space systems.  I can imagine that the size, weight, and power
> restrictions could make redundant systems impractical.  However, if
> your spec says that you have to tolerate any one single point of
> failure, then you may not have a choice.
>

My guess is that FPGA's have the spare space for redundancy,
how do you make sure that the voting circuits for 2 out 3
work 100% of the time? 

> --
> Greg Neff
> VP Engineering
> *Microsym* Computers Inc.
> greg@guesswhichwordgoeshere.com
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
The Lagging edge of technology:
http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.html
Article: 21641
Subject: Re: FPGA & single point failure
From: "Kate Atkins" <kate.atkins@siraeo.nospam.co.uk>
Date: Mon, 27 Mar 2000 17:00:40 +0100
Links: << >>  << T >>  << A >>
Ray

how is the continuous readback done? How long does it take to recognise that
an upset has occured? What sort of orbit (ie how nasty).


Ray Andraka <randraka@ids.net> wrote in message
news:38DF6BCD.28947E68@ids.net...
> Kate,
>
> The configuration 'SRAM' in SRAM based FPGAs is not what you would
normally
> consider an SRAM cell, rather it is a D register that is considerably more
> robust than the D registers in your design and orders of magnitude more
robust
> than the SRAM hanging off the microprocessor.  The readback capability can
be
> exploited to effect a continuous non-invasive health monitoring so that a
reload
> can be done when the configuration does get upset.  I've got a current
Virtex
> design that will be going into space in a year or two.
>
> Kate Atkins wrote:
>
> > surely you wouldn't use SRAM based FPGA on space equipment? SEU in the
> > configuration RAM could completely change the operation of the design,
> > an input buffer could turn into an output buffer!
> >
> > You could consider having two FPGAs, just one powered at any one time.
> > Open collector buffers on outputs (eg LS05 powered off/on with
associated
> > FPGA), series resistors on inputs to limit current seen by input
protection
> > diodes of the powered off FPGA.
> >
> > If you also have to consider SEU Synplicity has an application note on
"safe
> > statemachines" and one on using Actels rad hard FPGAs.
> >
> > I believe Actel have one or two of the RT54SX family due with SEU
hardened
> > registers.
> >
> > Regards
> >
> > Tom Burgess <tom.burgess@home.com> wrote in message
> > news:38DDDDED.6FF50630@home.com...
> > > Yes, Greg's interpretation makes sense. One solution would be to wire
2
> > > FPGAs in parallel, with independent configuration paths, leaving one
> > > always unconfigured (tri-state). If the host could detect a fault, it
> > could
> > > configure the other one. Of course if any output becomes stuck active,
> > this
> > > doesn't work, so you could use CMOS bus switches, but if these break,
you
> > are
> > > screwed. No wonder space shuttle toilets are so expensive ... but then
> > they
> > > have zip-lock baggies to fall back on. (ooof!)
> > >
> > > regards, tom
> > >
> > > Greg Alexander wrote:
> > > >
> > > > In article <38DC94F7.D2D0B8D6@home.com>, Tom Burgess wrote:
> > > > >Seeing the lack of responses, I can guess that many were mystified
by
> > your
> > > > >use of the unfamiliar terms "clue point" and "redound". The context
is
> > > > >not sufficient to make them clear, to me at least. What's
disconcerting
> > > > >is that the rest of the message appears to be mostly coherent
English.
> > > >
> > > > My guess is that "clue point" = "key point" -- simple mental error
or
> > > > perhaps somehow equivalent term (beats me).  And "redound" is
probably a
> > > > synonym for "make redundant," perhaps the word even implies some
special
> > > > method (such as having 3 redundant systems and a comparator).  I
would
> > > > guess that nobody replied because nobody really knows what type of
> > > > standards he needs in terms of reliability so nobody is confident to
say
> > > > "don't worry about it, just assume the FPGA won't break" or etc.  I
> > would
> > > > be very surprised if very many people who have the time to read
Usenet
> > are
> > > > familiar enough with REALLY critical apps to have much to say to
such a
> > > > general question.
> > > >
> > > > >EDM wrote:
> > > > >>
> > > > >> I've got a problem with a space mission payload system.  I want
to
> > use a
> > > > >> FPGA as a clue point of a payload electronic unit. Can anybody
> > clarify me
> > > > >> how do I manage the concept of "single point failure tolerant" in
the
> > > > >> system, If I cannot redound the board where this FPGA is
included. Do
> > I
> > > > >> redound the FPGA itself inside the board? Is it possible? And is
it
> > normally
> > > > >> foreseen? Or is there anything else that I have to take into
account?
> > Or
> > > > >> other good solutions that you can suggest me?
> > > > >>
> > > > >> Thanks for any advice and suggestion you can give me
> > > > >>
> > > > >> --
> > > > >>
> > > > >> edemarchi@hotmail.com
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka
>
>


Article: 21642
Subject: Re: Anyone using Philips (now Xilinx) Coolrunner PLDs?
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 27 Mar 2000 09:14:40 -0800
Links: << >>  << T >>  << A >>
It's Monday morning, and I have checked:

Xilinx now owns the CoolRunner family and will market, sell, and support that line
for many years to come. CoolRunner is here to stay.  And that includes the only PAL
in the CoolRunner family, the 22V10.  Programmable logic is all we do, and we do it
thoroughly.

As any parent of adopted children knows, there is only one way to treat an adopted
child: you love and treat it exactly like your own.

Peter Alfke, Xilinx Applications



Peter Alfke wrote:

> I will reply on Monday. Please give me a chance to get back to work and do some
> investigating.  CoolRunner is alive and well at Xilinx. We are happy, the
> ex-Philips developers in Albuq. are happy in the Xilinx camp, and I expect the
> user community will be happy...
> BTW, I would not call the smaller SpartanXL devices "high-priced", not even with
> their SPROM. But they are not a reasonable 22V10 substitute. I remember the
> 22V10 from 20 years ago at AMD...
>
> Peter Alfke, Xilinx Applications
> ====================================
> Peter wrote:
>
> > I wonder what would happen if Xilinx dropped the range, or just some
> > parts?
> >
> > What other "zero power" solutions are there? There are the static-CMOS
> > FPGAs, at quite high prices especially by the time you include the
> > serial EPROM etc.
> >
> > I do think someone else makes a "zero power" 22V10, though.
> >
> > It would be interesting to hear from Xilinx. Even a private email
> > would be interesting.
> >
> > >We have the PZ128C in a design and are having extreme difficulties. The
> > >problem is that Philips seem to have stopped making it, or at least declared
> > >it obsolete so that Philips dealers no longer have any stock, whereas Xilinx
> > >don't seem to have ramped up yet ... sigh!
> >
> > Peter.
> > --
> > Return address is invalid to help stop junk mail.
> > E-mail replies to zX80@digiYserve.com but remove the X and the Y.
> > Please do NOT copy usenet posts to email - it is NOT necessary.

Article: 21643
Subject: Re: FPGA & single point failure
From: Greg Neff <gregneff@my-deja.com>
Date: Mon, 27 Mar 2000 18:24:26 GMT
Links: << >>  << T >>  << A >>
In article <38DF817F.876BE674@jetnet.ab.ca>,
Ben Franchuk <bfranchuk@jetnet.ab.ca> wrote:
(snip)
> My guess is that FPGA's have the spare space for redundancy,

Space in the FPGA is not the issue.  There are failure modes which will
cause the entire FPGA to fail.  For example, power supply failure or
configuration PROM failure (these are single points) could cause the
entire FPGA to become inoperative.

> how do you make sure that the voting circuits for 2 out 3
> work 100% of the time?
(snip)

An actuator can be constructed with three actuating stepper motors.
Any one motor is powerful enough to perform the actuation.  If one
motor operates incorrectly, the other two motors will be powerful
enough to overpower the incorrect motor, and operate the actuator.  A
cross-coupled feedback system can be used to identify the faulty voter,
and attempt to take that voter offline.

Unfortunately, there is no such thing as 100%.  IMHO, The cardinal rule
of fault tolerant design is to keep it simple.  As soon as things get
complicated, it becomes extremely difficult to anticipate all possible
failure modes, and makes it very hard to validate and verify tolerance
of all possible single point failures.

BTW, diversity has not been used in systems that I have seen.  The
argument for diversity is that it compensates for latent failure modes,
such as software bugs.  The argument against diversity is that it is
more practical to design and thoroughly V&V one system, than to design
and V&V three diverse systems that have to work together in a redundant
configuration.

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21644
Subject: Re: Virtex DLL inoperability
From: winzker@aol.com (Winzker)
Date: 27 Mar 2000 19:46:37 GMT
Links: << >>  << T >>  << A >>
In article <8b9e8v$f18$1@jetsam.uits.indiana.edu>,
galexand@sietch.bloomington.in.us (Greg Alexander) writes:
> The whole thing stinks. :)

Thank you Greg for demonstrating us, why companies do NOT give informations
about problems, but let users find them on their own. It is no use insulting
anyone (or any"thing").

Regarding our DLL problem. Yes, we called the hotline (which told us about the 
application note, we already had.). But maybe the problem was not yet known 
at that particular time, so I can't blame them.

But, anyway, as Greg wrote in an later article, it is difficult to pinpoint
problems. 
You know that the DLL worked three weeks ago. But you fixed something
at the PCB and changed the source code. So you get the latest appl. note and
compare it with the version you had. Maybe there's a trick in getting it
locked? 
Maybe you have just been lucky three weeks ago and the design is not stable.
But in all this you forget, that you installed a new service pack 2 weeks ago. 
And you are not suspicious, because the last service pack's did run perfectly
and often brought improvements. (A compliment to Xilinx on that.)

So finally, there will always be bugs in the tools and we all earn our money
(some more, some less) by finding our ways to live with them. 

But apart from all this, in our case the SP3 disabled a perfectly running 
DLL design. I still wish, there would have been a note as soon as this 
was detected.


Regards,     Marco Winzker

Liesegang electronics GmbH, Germany
As always, speaking only for myself.

Article: 21645
Subject: Re: Difference between FPGA, PLD, CPLD ?
From: nospam@generalstandards.com (Michael Lee)
Date: Mon, 27 Mar 2000 20:18:05 GMT
Links: << >>  << T >>  << A >>
On Thu, 16 Mar 2000 13:42:02 -0800, Peter Alfke <peter@xilinx.com>
wrote:

>As usual, Ray gave a nice explanation.
>
>I disagree with his definition of a PLD.
>
>In my book , what Ray calls PLD,  is a PAL (as invented by John Birkner at MMI)
>with a programmable AND feeding a fixed OR.

MMI registered "PAL" as a trademark.  I think that is why "PLD" won
as a term for small PALs/PLDs.
--
Michael Lee

work                     play
Mike                     leem
@                        @
generalstandards         hiwaay
.com                    .net
Article: 21646
Subject: Re: RTL vs. gate level simulation
From: Richard Iachetta <iachetta@us.ibm.com>
Date: Mon, 27 Mar 2000 16:14:23 -0600
Links: << >>  << T >>  << A >>
In article <38DDBA69.4D428429@jps.net>, tzima1@jps.net says...
> In our design the result of Verilog RTL simulation does not agree with
> simulation of the gate level file. We are using Xilinx SpartanXL device
> and Modelsim Verilog simulator (Xilinx edition). We have registers with
> chip enable inputs and muxes generated by Xilinx Core Generator. The
> problem is that after writing to a register and then reading from it we
> are getting unknown values. We do not think that there is a timing
> problem here since in the test bench we provide planty of time between
> assigning values.
> Does any one out there have any similar problems? Any help will be
> appreciated.

There are many possible reasons that gatelevel code can go to X when RTL 
does not.  They usually have to do with IF or CASE constructs in the RTL 
where one of the inputs to the IF or CASE is X.  The RTL may not evaluate 
to X due to the way RTL is heirarchically evaluated, whereas the gatelevel 
sim will go to X because the gates are all evaluated in parallel.  A simple 
example:

if (a == 1)
   bus = y;
else
   bus = z;

Well, if a is equal to X, then it does not equal 1 so bus = z in the RTL 
sim, but bus = X in the gatelevel sim.  If bus = z is what was needed for 
that testcase, you won't see an X or a fail until gatelevel sim.

Another example:

if (a == 1)
   bus = y;
else if (b == 0)
   bus = z;
else bus = 0;

What if b=X whenever a = 1?  The RTL will always evaluate to bus = y 
because b is a don't care when a = 1.  But the gatelevel bus will most 
likely (depending upon which gates exactly create the logic) equal X.

-- 
Rich Iachetta
iachetta@us.ibm.com
I do not speak for IBM.
Article: 21647
Subject: Re: FPGA & single point failure
From: Ray Andraka <randraka@ids.net>
Date: Tue, 28 Mar 2000 00:30:25 GMT
Links: << >>  << T >>  << A >>
Its low earth orbit.  I'm not all that familiar with seu and where it is worst.
In this case, the customer came to me having already selected Virtex based on
radiation hardness testing that had previously been done.  You need to contact
Xilinx for the details, but from what I understand, Virtex has done very well in
the testing.

Continuous readback is done by scanning the configuration through the select map
interface.  It takes about as long as a full reconfiguration takes to do the
scan.

Kate Atkins wrote:

> Ray
>
> how is the continuous readback done? How long does it take to recognise that
> an upset has occured? What sort of orbit (ie how nasty).
>

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21648
Subject: Re: FPGA & single point failure
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 28 Mar 2000 13:16:52 +1200
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> Its low earth orbit.  I'm not all that familiar with seu and where it is worst.
> In this case, the customer came to me having already selected Virtex based on
> radiation hardness testing that had previously been done.  You need to contact
> Xilinx for the details, but from what I understand, Virtex has done very well in
> the testing.
> 
> Continuous readback is done by scanning the configuration through the select map
> interface.  It takes about as long as a full reconfiguration takes to do the
> scan.

 Interesting - What if this scanner / compare logic suffers a failure ?
Even if it works perfectly, can it Detect/ Re-boot fast enough to 
avoid self damage ?

-jg
Article: 21649
Subject: Re: FPGA & single point failure
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Mon, 27 Mar 2000 17:35:27 -0800
Links: << >>  << T >>  << A >>
Lots of info on the Xilinx rad-hard topic here:

 http://www.xilinx.com/products/hirel_qml.htm#Radiation_Hardened

regards, tom

Ray Andraka wrote:
> 
> Its low earth orbit.  I'm not all that familiar with seu and where it is worst.
> In this case, the customer came to me having already selected Virtex based on
> radiation hardness testing that had previously been done.  You need to contact
> Xilinx for the details, but from what I understand, Virtex has done very well in
> the testing.
> 

Tom Burgess
-- 
Digital Engineer
National Research Council of Canada
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3
Email:        tom.burgess@hia.nrc.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
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