Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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.comArticle: 21626
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/~randrakaArticle: 21627
--------------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> <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> </blockquote> 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. <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. 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. <br> <p>-- <br>-Ray Andraka, P.E. <br>President, the Andraka Consulting Group, Inc. <br>401/884-7930 Fax 401/884-7950 <br>email randraka@ids.net <br><A HREF="http://users.ids.net/~randraka">http://users.ids.net/~randraka</A> <br> </html> --------------623E5D40A1E87FF3B25363BF--Article: 21628
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/~randrakaArticle: 21629
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.nzArticle: 21630
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.comArticle: 21631
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.comArticle: 21632
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.orgArticle: 21633
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
<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
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.comArticle: 21636
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 ! GerhardArticle: 21637
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/~randrakaArticle: 21638
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
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
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.htmlArticle: 21641
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
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
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
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
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 .netArticle: 21646
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
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/~randrakaArticle: 21648
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 ? -jgArticle: 21649
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:
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