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
Well, the FPGA on MGS altimeter worked fine (knock on wood, that one was mine), was done 100% in schematic, and the scientists were quite happy with the results. Interestingly, most failures involve a series of things going wrong or things that could have prevented it. And most of them you can figure out exactly what went wrong, or narrow it down quite well, even without retrieving the device. That is a pretty surprising result. The one with the cover blowing off was neither act of God or VHDL. Or Verilog. A design oops with the FPGA application, a design oops with the crystal oscillator application, a test oops, system design oops, test equipment oops, test results analysis oops, another test equipment oops, a paperwork oops, a review oops, another review oops, and perhaps a few more oopses all tied in together. But that many oopses isn't as hard to have come together as one might think. These are not forgiving applications which make many of us paranoided. And I agree, much of the reliability of FPGA devices as seen by the system is out of the hands and control of the manufacturer (one manufacturer did a nice paper on exactly that about two years ago). But the manufacturer can do things to influence how their parts are used and used successfully. Publish metastable state numbers. Over temperature and voltage. Good, predictable, controlled turn-on sequences. Clear documentation that is not confusing. No power squencing restrictions. Easy to meet power-on slew rate requirements. Reasonable input signal slew rate requirements. Good noise margin on the inputs, perhaps with a bit more hysteresis. Good static timing analysis tools that give trusted bounded answers (both min and max) with adequate margin. Eliminate quirks and other gotchas that result in many users making common errors. Control ground bounce. Good control on outputs for good signal integrity. ... Just a few of the things that I consider important. Cheers, -- rk Austin Lesea wrote: > rk, > > One thing that one manufacturer learned the hard way awhile ago was > that if you brag about having your part on the spacecraft before > the mission, and the mission does not go well (ie the hatches blow > off too soon, it goes out of control, and the payload is lost), you > might suddenly not want a lot of attention on whose part it was > that was controlling the hatches..... > > The problem may have nothing to do with the part. It may have been > an "act of God" or a design flaw (so who reviewed the VHDL?). The > problem might have been present before launch, and no one > understood what the test results meant. (Oh, those little lights > mean that the hatches blow off now?) Who is to say? It isn't like > you have anything left that you can do failure analysis on.....or > you can get an RMA. > > So, when it lands (flys, images, etc) then the bragging might > start. Before that, we are all a little gun shy after some > spectacularly bad goofs.....that may, or may not have had anything > to do with the underlying technology that we provide. > > A successful mission depends on a massive amount of stuff going > right, and absolutely nothing going wrong. Very little of which > actually falls under the manufacturers control at all. > > Austin > > rk wrote: > >> Mike Butts wrote: >> >> > The May 2003 issue of IEEE Spectrum has a nifty and >> > detailed article on the exciting British Beagle 2 >> > lander hitching a ride on ESA's Mars Express orbiter, set to >> > launch soon and arrive in December. >> > >> > Its robotic arm carries a bunch of instruments and >> > other devices. "Discrete electronic interfaces >> > between each instrument and the lander would have >> > been complex to build and heavy as well. So the >> > PAW uses a single interface with a field-programmable >> > gate array that can reconfigure itself to match each >> > instrument's needs." >> > >> > Excellent! One of you must be able to tell us more. >> > Who's the clever designer? Who's the lucky vendor? >> > What device? Rad-hard? Fault-tolerant? Designed >> > in what language? Verified how? Bitstreams stored >> > where and loaded by what? Can they upload new >> > bitstreams from Earth? (Now that's an UPload!) >> > What if DONE doesn't go high? >> > >> > Will this be the first FPGA in Mars space? >> >> I don't recall if there were any on Mars Pathfinder but there was >> definitely an FPGA on Mars Global Survey on the laser altimeter. >> The FPGA got put onto the instrument as it was upgraded; the >> original laser altimeter was on the ill-fated Mars Explorer. >> >> There are also FPGAs on the way to Saturn on the Cassini >> spacecraft. >> >> >> > Most important of all, will they send a paper to >> > FPL 2003 or FPGA 2004 or FCCM 2004? >> >> MAPLD 2003? ;-) >> >> -- >> rk, Citizen, Noooo Yawk >> "Sometimes when you connect the dots you get a picture. Other >> times you just have a bunch of dots." -- rk, January 23, 2003 > >Article: 56476
Thanks Rickman and kumaran for your suggestions. Rickman, i looked through that website, and found some interesting topics. Let me know if u have some other websites too. Thanks, PriyalArticle: 56477
Hello,
I am looking at a possible design where I need many small FIFOs or
possibly BRAMs to hold data temporarily. In particular this device has many
(up to 32) channels. for reasons of simplicity, it would be nice if the
data from each cahnnel could go into its own FIFO. The data would then be
sent via USB to a main PC where the data could be directly sent to an array
for the correct channel rather that being parsed out to the various arrays.
By the way, the data being sent is coming in to the FIFOs from different
channels at different rates. That is why I need 32 different FIFOs. The
data bus is 16 bits wide if that is of importance. The prefered chip is a
Spartan2e or possibly a Spartan3. I need to avoid any BGA type packages to
allow for small production runs with reliable assembly. (no toaster ovens,
etc.) Production date is early Fall, '03. Prototypes to start immediately.
Thanks,
Theron Hicks
Article: 56478Peter Alfke wrote: > "parity bit" is just a name, suggesting one possible application. We > might have called it "extra bit", or "Xilinx Ninth"... > Use to store parity must be very rare. > > Peter Alfke > Why not call them data bit(s). E.g. D[31:0], DP[3:0] => D[35:0]. This should make it much easier for synthesis tools to use the 'parity' bits which e.g. synplify doesn't do today. If you try to use a 33 bits wide and 512 entries deep memory today the synthesis will end up with two BRAMs instead of one. This is waist of memory! Of course you could manually instantiate the RAM primitives but why should you do the work that the tools should do? /Patrik -- Patrik Eriksson | patrik.eriksson@netinsight.net Net Insight AB | phone: +46 8 685 04 89 Västberga Allé 9 | fax: +46 8 685 04 20 SE-126 30 STOCKHOLM, Sweden | http://www.netinsight.netArticle: 56479
Hallo, I have a clock e.g.: s_asck and a delayed clock: s_asck_delay s_asck_delay <= s_asck after 50ns; q1<=s_asck; q2<=s_asck_delay; When I simulate it with Quartus II the two graphs show the same characteristics. But the Output q2 should be delayed 50 ns to q1. How can I show it in Quartus II correctly? best regardsArticle: 56480
Quartus simulator only deals with synthesised code. You cannot synthesise such time delays (they are ignored) hence the problem. Use the Mentor Modelsim provided with Quartus if you need to simulate testbenches or other non-synthesisable code. Paul "Jens Nowack" <its.me.hates-spam@uni.de> wrote in message news:bbpi2g$c80fu$1@ID-192450.news.dfncis.de... > Hallo, > > I have a clock e.g.: s_asck and a delayed clock: s_asck_delay > > s_asck_delay <= s_asck after 50ns; > > q1<=s_asck; > q2<=s_asck_delay; > > When I simulate it with Quartus II the two graphs show the same > characteristics. But the Output q2 should be delayed 50 ns to q1. > How can I show it in Quartus II correctly? > > best regards > >Article: 56481
Have you checked the XV2DDR board from CESYS (approx. 995,- Euro) ? Short facts: XC2V1000-5FG456C, Micron MT46V16M16-75 DDR-SDRAM XC18V04 ISP Conf. Prom, 219 I/O Pins wired to two 140-pin small-pitch connectors, Eval-board with mating connectors available. Datasheet: http://www.cesys.com/english/resources/SPEC01.pdf A free "light-version" of the DDR SDRAM controller can be downloaded from www.opencores.org/projects/ddr_sdr. This free version reaches 130 Mbytes/s with 100MHz system-clock. It consumes about 180 Slices in a Virtex II device. The controller is tested on the XV2DDR board. UCF-file is available. -Manfred Kraus, cesys gmbhArticle: 56482
Check this: http://www.idt.com/products/pages/Bus_Switches-QS316245.html QuickSwitch® Products QS316245 FEATURES/BENEFITS . Enhanced N channel FET with no inherent diode to VCC . 5W bidirectional switches connect inputs to outputs . Pin compatible with FCT16245 . Flowthrough pinout for easy layout . Zero propagation delay, zero ground bounce . Undershoot clamp diodes on all switch and control inputs . TTL-compatible control inputs . Available in 48-pin SSOP (PV) APPLICATIONS . Hot-docking, hot-swapping (Application Note AN-13) . Voltage translation (5V to 3.3V; Application Note AN-11) . Bus switching, isolation . Power conservation, clock gating . Logic replacement - Manfred KrausArticle: 56483
muthu_nano@yahoo.co.in (Muthu) writes: > In all Xilinx block RAM Primitives, they have allocated Parity bits (1 > per byte) for each locations. If we see the 32bits with RAM, > additional 4 bits being provided for the Parity. As has been said already, this is just a name suggesting a possible usage. > In most of the cases, we are not using this. This is because, all our > RAM is internal, there is not possibility of data corruption. You might want to be careful here. If this RAM stores data that is rarely refreshed, over the course of several days or weeks, it could still be that your data is corrupted due to environmental influences like radiation. Be pessimistic. Cheers, ColinArticle: 56484
In article <BwzDa.4269$IR1.488918@news20.bellglobal.com>, warpawn@sympatico.ca says... > So I'd say try simulating for a longer time as a start. you should also > take a look at where nios is fetching from. I finally solved it, I didn't saw that reset was activated with a low level, so I was resetting the cpu most of the time (a very stupid error). When I fixed it, I had to rebuild the cpu in order to set the internal rom (where I put my program) base address to 0, then all started working. Thanks for your response -- Jesus Jimenez jesjimenez@NOSPAMtelefonica.netArticle: 56485
... er ... that should have said ...AND the quite static CLOCK ENABLE input. BTW, what I find odd is that this particular instance behaves differently than the other two in the circuit. Richard Erlacher "Richard Erlacher" <richard_no_junk_mail_4_me at idcomm.com> wrote in message news:3edfd43f$1@mindmeld.idcomm.com... > I've run into an odd problem with the third stage of a 12-bit synchronous > binary counter simulation. This circuit consists of an FTRSE driving the CE > inputs of each of three CB4RE counters, concatenated in the obvious way. An > the FTRSE and the three counters are all clocked with a common clock, and > the counters' enable is driven from the output of the FTRSE which is set > from an external start strobe two clocks long, and cleared when the last > stage generates its CEO (count enable out). Unfortunately this output, > clearly an entire clock cycle long (not one of the infamous glitches these > can generate) occurs when the LSB of the third stage is false, which is not > what one would expect, since this output is not registered, but is gated > from the synchronous outputs AND the quite static input. > > Has anyone else encountered this apparent anomaly? > > thanks, > > Richard Erlacher > >Article: 56487
>Now I want to write a linux driver for this device. > >Do I write the driver from scratch or I can modify an existing driver? >Which files Do I need to modify? Most drivers are written by taking the closest driver you can find and editing (hacking?) it until it work. It helps if you had that in mind when you designed your hardware - that is make your hardware as close to an existing design as you can. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 56488
Theron Hicks wrote: > Hello, > I am looking at a possible design where I need many small FIFOs or > possibly BRAMs to hold data temporarily. In particular this device has many > (up to 32) channels. for reasons of simplicity, it would be nice if the > data from each cahnnel could go into its own FIFO. The data would then be > sent via USB to a main PC where the data could be directly sent to an array > for the correct channel rather that being parsed out to the various arrays. > By the way, the data being sent is coming in to the FIFOs from different > channels at different rates. That is why I need 32 different FIFOs. The > data bus is 16 bits wide if that is of importance. The prefered chip is a > Spartan2e or possibly a Spartan3. I need to avoid any BGA type packages to > allow for small production runs with reliable assembly. (no toaster ovens, > etc.) Production date is early Fall, '03. Prototypes to start immediately. > Thanks, > Theron Hicks > > Hi, Which USB device do you have? Do you need external memories? Since we are finalizing a similar product based USB, we can help, or do your project in a rapid time. Actually, we have a proto board with a low cost USB solution ($8) connected directly to a SPartan2 (150k)device. We are able to POWER / CONFIG THE FPGA / DIALOG WITH FPGA over USB. (your JTAG emulation can program the SPROM for the FPGA). This solution allows to save power input, to save external Xilinx Parallel POD -> to save money and time. We are doing a final product with that ... will be ChameleonII (we just are waiting on SPARTAN3) Contact laurent.gauch@amontec Amontec Team www.amontec.comArticle: 56489
Glenn, this is from the newsgroup. Something for "our" board? Peter Quoate from comp.arch.fpga: Which USB device do you have? Do you need external memories? Since we are finalizing a similar product based USB, we can help, or do your project in a rapid time. Actually, we have a proto board with a low cost USB solution ($8) connected directly to a SPartan2 (150k)device. We are able to POWER / CONFIG THE FPGA / DIALOG WITH FPGA over USB. (your JTAG emulation can program the SPROM for the FPGA). This solution allows to save power input, to save external Xilinx Parallel POD -> to save money and time.Article: 56490
Sorry, this was not meant for public consumption. Just for a friend... Shows my appreciation for a nifty USB interface. Peter Alfke ============ Peter Alfke wrote: > > Glenn, this is from the newsgroup. > Something for "our" board? > Peter > > Quoate from comp.arch.fpga: > > Which USB device do you have? > Do you need external memories? > > Since we are finalizing a similar product based USB, we can help, or do > your project in a rapid time. > > Actually, we have a proto board with a low cost USB solution ($8) > connected directly to a SPartan2 (150k)device. > We are able to POWER / CONFIG THE FPGA / DIALOG WITH FPGA over USB. > (your JTAG emulation can program the SPROM for the FPGA). > > This solution allows to save power input, to save external Xilinx > Parallel POD -> to save money and time.Article: 56491
Peter Alfke wrote: > Glenn, this is from the newsgroup. > Something for "our" board? > Peter > > Quoate from comp.arch.fpga: > > Which USB device do you have? > Do you need external memories? > > Since we are finalizing a similar product based USB, we can help, or do > your project in a rapid time. > > Actually, we have a proto board with a low cost USB solution ($8) > connected directly to a SPartan2 (150k)device. > We are able to POWER / CONFIG THE FPGA / DIALOG WITH FPGA over USB. > (your JTAG emulation can program the SPROM for the FPGA). > > This solution allows to save power input, to save external Xilinx > Parallel POD -> to save money and time. which board?Article: 56492
"Theron Hicks" <hicksthe@egr.msu.edu> schrieb im Newsbeitrag news:bbqght$bi7$1@msunews.cl.msu.edu... > Hello, > I am looking at a possible design where I need many small FIFOs or > possibly BRAMs to hold data temporarily. In particular this device has many > (up to 32) channels. for reasons of simplicity, it would be nice if the > data from each cahnnel could go into its own FIFO. The data would then be So how deep must the FIFOs be? 16 words? 100 ? 1000 ? A BRAM in Spartan2E is 4kbits, so it can hold 256 16 bit words. Spartan3 is derived from Virtex-II so a BRAM is 18 kbits. The rest can be easyly looked up in the datasheets. If you need (much) smaller FIFOs, you can use distributed RAM. -- MfG FalkArticle: 56493
Jake Janovetz wrote: >Is anyone out there using a third-party schematic entry tool (or even >HDL tool) for Xilinx FPGAs? I'll exclude Synplicity from my poking >and prodding because I know it's used a lot. > >There are several situations where schematic entry would be a nice >alternative to HDL for building an RPM. ECS is a waste of bits in my >opinion and Viewlogic isn't so hot anymore. I know Protel offers >schematic entry with Xilinx primitives and I assume OrCAD has >something similar. Are they worth using? > > I tried doing this some time ago, and ran into several layers of bugs. First, the FPGA libraries are extremely old and out of date for modern devices, like Spartan. I got some more modern libraries from older (how odd!) versions of Protel Advanced Schematic, but they were FULL of bugs. Obviously machine translated in some fashion, which missed a buch of connection dots on clock lines, so that many of the counter blocks flip flops had no clock. I hand edited a few, but then really hit the wall. The Xilinx compatible output file (.xnf) was reported to have invalid syntax by the Xilinx tools! I sent this info to Protel 2 years ago, there has been no response from them. Protel will not do any Xilinx FPGAs by itself, I was trying to use Protel only as a schematic front end to Xilinx Foundation, as the schematic package before ECS was even worse! I still feel that ECS is pretty awful, and the rest of ISE is just a bit cumbersome, non-intuitive, etc. The above all applies to Protel 99SE, I have no idea what they have fixed, or broken, with the move to DXP. But, to hear comments in the mailing lists, DXP support for programmable logic is less, if anything, than with 99SE. JonArticle: 56494
Falk Brunner wrote: >"David Kinsell" <kinsell@poboxyz.com> schrieb im Newsbeitrag >news:Z9eDa.62966$M01.39756@sccrnsc02... > > > >>Those aren't classic low pass filters, the caps should be on the other >>side of the resistors. I've used 470 pf on the other side of the TCK >>resistor and gotten much better results programming an original Spartan >>part. >> >> > >Those filters are just nonsense, IMHO. It has been said a few times, that >the TCK line is VERY sensitive to glitches, since it is as fast as all other >IOs. So it is a good idea to put RC-filter (330 Ohm, 1nF) followed by a >schmitt-trigger (74HC14) in front of the TCK line (before the tristate >driver). A second schmitt-trigger reveres the polarity to the original >level, so from the software view its identical. In my download cable, I also >removed the diode feeding VCC. > > I've found the Parallel cable III to be totally reliable on certain computers, and anywhere from marinal to totally nonfunctional on some others. I haven't tried hacking the unit to find the specific signal that was the problem. But, it clearly was associated with specific characteristics of the parallel port chip on the motherboard. Probably some pull-ups to a real +5 V on the computer end would help a lot, but there is no +5 available on the DB-25 connector. Did you actually make the 74HC14 and RC change on a cable, and see it work reliably on the same computer where it was marginal before? JonArticle: 56495
I have the following verilog code which gets flagged as an error in
quartus, but not in Icarus --
{{shift{yi[bitwidth-1]}},yi[bitwidth-1:shift]}
"shift" is a parameter, and the error gets flagged only when it is
equal to zero. Quartus says "replication multiplier must be positive.
I'm pretty sure this is legal verilog.
Matt
Article: 56496??????? Tests show that the rate of upsets (soft errors) in a 2V1000 BRAM is one every 800 years at sea level in San Jose..... Weeks? Days? come on! Do you have a nuclear reactor door open somewhere? Austin Colin Marquardt wrote: -snip- > > You might want to be careful here. If this RAM stores data that is > rarely refreshed, over the course of several days or weeks, it could > still be that your data is corrupted due to environmental influences > like radiation. Be pessimistic. > > Cheers, > ColinArticle: 56497
Hi people, I just started to worked with those funny FPGA's as a sudent a few weeks ago. I'm doing some image processing with FPGA but, I've lack of experience in those stuff and so i'd like to grabb a book related to the subject. for exemple: I want to take care about the boundaries of the image when i aplly a kernel, is there a trick to manage this ( I mean the architecture in the whole vhdl design)? Or, how to resize the image, is there some technics in hardware design? To sum up: is there a book which talks about signal processing (or better image processing) which talk about tricks and architecture for vhdl and more generally hardware architecture for image processing ??Article: 56498
rickman <spamgoeshere4@yahoo.com> writes: > If even the BaseX system does not support devices beyond 3S200, I guess > we can expect Webpack support to be pretty short for a long time to > come, no? > > I really don't understand the idea behind not supporting the full > Spartan3 line in the *paid for* tools. I know BaseX is not expensive, > but what is the rational behind *NOT* supporting any devices in the paid > for tools? To encourage you to pay *more*.Article: 56499
Colin Marquardt <c.marquardt@alcatel.de> writes: > You might want to be careful here. If this RAM stores data that is > rarely refreshed, over the course of several days or weeks, it could > still be that your data is corrupted due to environmental influences > like radiation. Be pessimistic. If you've using a small number of BRAMs and a lot of logic cells, I'd expect there to be a higher probability of an SEU in a logic cell, for which parity is not, in general, going to help.
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