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
I've found these preliminary specifications in the Xilinx site: http://direct.xilinx.com/bvdocs/publications/ds123.pdf Do you know if these devices are already in production? If not, when will they be (hopefully :))? -- LorenzoArticle: 55426
I know the radiation hardened Xilinx FPGA has already been applied in the australian earth orbit application. But I am wondering besides the radiation effect, is there any other concern about the extreme environment in space like extreme temperatures, corrosive environments, thermal cycling and so on. Because from the latest reliability report of Xilinx Device, it seems most of the faults like oxide defect occurred in the high temperature life test. Does that mean the extreme thermal conditions will be the major factor (assume radiation effect can be controlled effectively) which will influence the reliability of device in the space? Because the failure rate will goes up with higher temperature. Austin Lesea wrote: > Weifeng, > > We took a device, (actually a number of them) and placed them in > contention purposely. Current densities of 10-15 million amperes per cm > squared. Far over any electromigration limits. > > We then took readings every month. > > That started over four years ago. > > No problems whatsoever. > > When we say these parts are tough, we mean it. We have no idea what the > customer will do, and sometimes the static stress of contention is less > than the operating stress a typical customer may require! > > Some anit-fuse FPGA vendor(s) have a lot of foolish FUD (fear, > uncertainty, doubt) out there which is totally wrong, false, and > intentionally mis-leading. We have countered that with the "1000 years > between single event upsets" tech exclusive on the public website. > > This tech exclusive by Peter and myself has been a best seller, as > evidenced by doing a search in Google. It is #1 on the "hit" list for a > few months now. Never been #1 on Google before....... > > (search for: 1000 years between single event upsets) > > Austin > > Weifeng Xu wrote: > > > > > > > > Austin Lesea wrote: > > > > > Michael, > > > > > > Faults are things like oxide break down, or junction breakdown. > > > > > > They are most likely from weak or originally defective oxides or > > > junctions > > > that eventually broke from eventual overstress (due to their > > > original weak > > > nature). > > > > > > These kinds of defects can not be totally avoided. One can burn in > > > devices, > > > one can overstress devices, but lately there is a lot of data that > > > shows > > > that doing so actually increases field failure rates (if you stress > > > too > > > much, if you stress not much at all, it does very little for the > > > long term > > > failure rate). > > > > > > > I am wondering whether the soft errors (if it does occur) in > > configuration memeory cell will > > destroy the device and bring in some permanent faults. From above > > discussion, it seems even > > even contension won't break the device easily. > > For example, what if a bidirectional hex line is driven by two > > drivers because one tri-buffer > > was opened due to SEU effect. Can the virtex device still tolerate > > that, if so, for how long? > > Thanks! > > > > > > > > This whole subject has nothing to do with FPGAs, so you should > > > research > > > semiconductor reliability. > > > > > > Soft fails are another issue, and the following link covers that: > > > > > > http://www.xilinx.com/support/techxclusives/1000-techX35.htm > > > > > > Austin > > > > > > Michael Garvie wrote: > > > > > > > Given your FIT rates for high temperature, high moisture, > > > electrical > > > > overstress, or purely random; what is the fault mode induced? Are > > > these > > > > localized and permanent? Or do they go away with scrubbing? Or > > > are > > > > they at the FPGA subsystem level? > > > > Regards, > > > > Miguel > > > > > > > > Austin Lesea wrote: > > > > > > > > > I suggest that if you have suddenly experienced a failure, that > > > is the > > > > > kind of failure known as "random" and fits well within our FIT > > > rate > > > > > predictions. > > > > > > > > > > As everyone knows, failures do happen, and if the designers, > > > industry > > > > > and foundries could prevent that from happening, we would all be > > > > > > > > happier when we have to design fail-safe systems. > > > > > > > > > > So, until then, fail safe systems fail, by failing to fail > > > safely. > > > > > > > > > > AustinArticle: 55427
"CB" <charleybrant@hotmail.com> ha scritto nel messaggio news:3eb80fac.6296804@news.compuserve.com... > > Sounds like a very interesting project .. could you tell us a little > about the application ? I'm always interested to know where these > cool projects are used. CB > > > >Just finished a very similar project. Digitize video composite, store in > >memory (4 frames), and real-time playback of live video or stored images. I > >had also to overlay a color graphic layer. That was for a dental intraoral camera. It's nothing special per se, many many "video" related designs are much similar to this... Nevertheless, I really learnt and enjoyed a lot. Especially synchronizing video streams and playing with "video mixing" in YUV space to do a kind of poor-man "alpha" channel for blending of video with graphic data (a requirement for control menus, and so on).Article: 55428
works well with ISE 5.2 ! Amontec Team www.amontec.com Ondrej Zoubek wrote: > Hi all, > I have problem with erasing XCR3064XL. > > I'm programming it from .svf file created with iMPACT. I have read, there > was a problem with it, but in 5.1 SP3 it should be fixed. I have that > version. > I'm using .xsvf file, conversion utility svf2xsvf.exe, attached with > xapp058. > > In the .svf file, there is one line (in the erase procedure) > STATE DRCAPTURE DRPAUSE; > which the utility svf2xsvf don't understand. I don't know why, because it > knows STATE commands with multiple parameters. > It must understand it badly, because it says error, 'DRCAPTURE invalid > stable state'. > > I rewrite it to STATE DRPAUSE; and see how the states changes. > It's going in that way: PauseIR -> Exit2IR -> UpdateIR -> SelectDR -> > CaptureDR -> Exit1DR -> PauseDR. > > Does anybody know what's going wrong? > Can be somewhere found newer version of the utility svf2xsvf? (I have 5.00) > > I'm programming it using playxsvf, with rewritten ports.c > > > Thanks for answers > > >Article: 55429
The most reliable answer would come from the italian distributor, e.g. Avnet. They have every reason to give you the proper answer. Peter Alfke ============================== Lorenzo Lutti wrote: > > I've found these preliminary specifications in the Xilinx site: > > http://direct.xilinx.com/bvdocs/publications/ds123.pdf > > Do you know if these devices are already in production? If not, when > will they be (hopefully :))? > > -- > LorenzoArticle: 55430
> It shouldn't take you more than a week or so worth of nights and weekends to > get a netlist and layout package together for a board house to produce it. I'm not single any more. I don't get weekends and nights :-) -- TorqueArticle: 55431
Hi Ian, That makes good sense to split it up, from a fitting standpoint. I tried it, and unfortunately, it did the same thing with 8-bit words. I've been corresponding with an Altera cust support person, and when she compiled my test design, it worked. She sent me her compilation and I recompiled it with no changes to the settings, and it was still bad. She told me to upgrade to the latest version (I'm using 10.12; the latest is 10.22). From what I could tell on their download site, you can't upgrade to 10.22 from 10.12. But I did anyway, and it trashed the installation :-( I had to do a complete reinstall... and no, it still didn't work. So if I get this figured out, I'll post the results. Thanks, Dan Vincent "Ian McCrum, MI5AFL" <IJ.McCrum@ulst.ac.uk> wrote in message news:3eb8c52d.1434342@news.ntlworld.com... > On Sun, 04 May 2003 18:26:28 GMT, "FPGA user" <nospam@aol.com> wrote: > > >Hi, > > > >Has anyone used LPM_ROM megafunctions in an EP1K50? They do NOT seem to > >work in simulation. However, an EP1K30 or an EP1K100 DOES work. > > > >I'm using the latest version of MaxPlus II, and created a design with only > >that megafunction, unclocked, with addr in/data out ports, and an > >initialization file. I organized the part as 64 16 bit words. > > > >Compilling and changing nothing but the device shows up the problem. > > > > > >Thanks! > > > > > I have used LPM_ROM for a large(wide) microcode design, I recall it > fitted/worked better if I split the ROMs into 8 bit chunks, so two > 64x8 roms may be better. I think I retrospectively read something in > the altera literature to do this ... YMMV > > Email me if still having probs as I probably have old code on my > website www.eej.ulst.ac.uk try IJ.McCrum as my email username and > ulster.ac.uk ad my email domain. > > Regards > Ian McCrum, MI5AFLArticle: 55432
Weifeng, Space is actually much more forgiving that being under the hood of a car near the engine. No corrosion (you are in a vacuum), no thermal cycling or temperature problems (if you have a good thermal designer to control the environment balancing heat in vs. being able to radiate it out). I would look at the amsat.org website, and all related links. The world's amateur radio community has launched more than 45 satellites into orbit, and many of them (most) are still operational. All of what you need to know is freely available, and often quite more advanced than the commercial space industry which basically never takes any chances, so never (OK, hardly ever) innovates as a result. A great example of that is magnetorqueing to keep a satellite's antennas pointed at the earth (use of the earth's magnetic field, and pulsing a field coil about the satellite to orient it). Amateurs have used this for mopre than a dozen years now, but it is considered "unproven" in commercial applications..... Austin Weifeng Xu wrote: > > I know the radiation hardened Xilinx FPGA has already been applied in the > australian earth orbit application. But I am wondering besides the radiation > effect, is there any other concern about the extreme environment in space > like extreme temperatures, corrosive environments, thermal cycling and so > on. > Because from the latest reliability report of Xilinx Device, it seems > most of the faults like oxide defect occurred in the high temperature life > test. Does that mean the extreme thermal conditions will be the major factor > (assume radiation effect can be controlled effectively) which will influence > the reliability of device in the space? Because the failure rate will goes > up with higher temperature. > > Austin Lesea wrote: > > > Weifeng, > > > > We took a device, (actually a number of them) and placed them in > > contention purposely. Current densities of 10-15 million amperes per cm > > squared. Far over any electromigration limits. > > > > We then took readings every month. > > > > That started over four years ago. > > > > No problems whatsoever. > > > > When we say these parts are tough, we mean it. We have no idea what the > > customer will do, and sometimes the static stress of contention is less > > than the operating stress a typical customer may require! > > > > Some anit-fuse FPGA vendor(s) have a lot of foolish FUD (fear, > > uncertainty, doubt) out there which is totally wrong, false, and > > intentionally mis-leading. We have countered that with the "1000 years > > between single event upsets" tech exclusive on the public website. > > > > This tech exclusive by Peter and myself has been a best seller, as > > evidenced by doing a search in Google. It is #1 on the "hit" list for a > > few months now. Never been #1 on Google before....... > > > > (search for: 1000 years between single event upsets) > > > > Austin > > > > Weifeng Xu wrote: > > > > > > > > > > > > Austin Lesea wrote: > > > > > > > Michael, > > > > > > > > Faults are things like oxide break down, or junction breakdown. > > > > > > > > They are most likely from weak or originally defective oxides or > > > > junctions > > > > that eventually broke from eventual overstress (due to their > > > > original weak > > > > nature). > > > > > > > > These kinds of defects can not be totally avoided. One can burn in > > > > devices, > > > > one can overstress devices, but lately there is a lot of data that > > > > shows > > > > that doing so actually increases field failure rates (if you stress > > > > too > > > > much, if you stress not much at all, it does very little for the > > > > long term > > > > failure rate). > > > > > > > > > > I am wondering whether the soft errors (if it does occur) in > > > configuration memeory cell will > > > destroy the device and bring in some permanent faults. From above > > > discussion, it seems even > > > even contension won't break the device easily. > > > For example, what if a bidirectional hex line is driven by two > > > drivers because one tri-buffer > > > was opened due to SEU effect. Can the virtex device still tolerate > > > that, if so, for how long? > > > Thanks! > > > > > > > > > > > This whole subject has nothing to do with FPGAs, so you should > > > > research > > > > semiconductor reliability. > > > > > > > > Soft fails are another issue, and the following link covers that: > > > > > > > > http://www.xilinx.com/support/techxclusives/1000-techX35.htm > > > > > > > > Austin > > > > > > > > Michael Garvie wrote: > > > > > > > > > Given your FIT rates for high temperature, high moisture, > > > > electrical > > > > > overstress, or purely random; what is the fault mode induced? Are > > > > these > > > > > localized and permanent? Or do they go away with scrubbing? Or > > > > are > > > > > they at the FPGA subsystem level? > > > > > Regards, > > > > > Miguel > > > > > > > > > > Austin Lesea wrote: > > > > > > > > > > > I suggest that if you have suddenly experienced a failure, that > > > > is the > > > > > > kind of failure known as "random" and fits well within our FIT > > > > rate > > > > > > predictions. > > > > > > > > > > > > As everyone knows, failures do happen, and if the designers, > > > > industry > > > > > > and foundries could prevent that from happening, we would all be > > > > > > > > > > happier when we have to design fail-safe systems. > > > > > > > > > > > > So, until then, fail safe systems fail, by failing to fail > > > > safely. > > > > > > > > > > > > AustinArticle: 55433
So why are you worried about getting an FPGA in a Dip40 package then anyway???
Torquemada wrote:
> > It shouldn't take you more than a week or so worth of nights and weekends
> to
> > get a netlist and layout package together for a board house to produce it.
>
> I'm not single any more. I don't get weekends and nights :-)
> --
> Torque
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 55434Hi Folks, Using FPGA Advantage V5.4 on my WinXP SP1 system, I am having some problems with the integrated modelsim (v5.6d) component. After a succesful compilation, I try to simulate the model, But with many models I get this error ** Fatal: (SIGSEGV) Bad pointer access. I searched using Google and it took me to the GNU C Library, where this error was explained; From this point my guess is that maybe Modelsim is not suitable for WinXP yet. I have tried all the compatibilty modes (i.e. win95, win98/winME, winNT4 SP5, win2k) but neither of these modes prevented modelsim from generating this error. I have also tested a very simple model, which COULD be simulated, but unfortunately Modelsim collapsed (program exits without further notice) when I wanted to add signals to the wave-table. I guess maybe this has someway the same cause as the 'Bad Pointer Access'-error. Beside this behavior, I have no other clue that my installation version is corrupted Does any of you have experienced likewise problems with this tool, and/or know how to solve these problems? I would be glad to hear it! Best Regards, Dennis MaasbommelArticle: 55435
Jim Granville wrote: <snip> > Sounds like an opening for a module - there is a company doing this > with ProASIC Flash FPGAs, they also sell Softcore uC, and programmers. > IIRC they mount the BGA onto a DIP28 compatible PCB, and that > module is then 'project deployed' A couple have asked, so I've dug for the link : www.quickcores.com I see they also have just released their Soft 80C51, to go with their other, simpler soft-cores. What they are doing looks good for Education, and hobbyist use, and even for development labs. It also forms a good 'reality check' for point silicon offerings like the Triscend ES5, or the Atmel FPslic. For volume deployment, you do have to need some of the FPGA features, as 99c will get you a 3mm package, 25 MIPS 80C51 with similar 2KB core resources, but more std peripherals. ( see www.cygnal.com ) -jgArticle: 55436
See www.m-sys.com for another popular line of disks. You can even use Compact Flash cards as disks, with just a physical adapter, but you can wear them out with excessive writes, due to lack of wear leveling. Struggling a bit to understand the relevance to this NG, however. "Mikhail" <kostkin@asicdesign.ru> wrote in message news:b9b300$gev$1@news.wplus.spb.ru... > I mean that disk have to work in hard conditions (vibration, hits etc.) > > "Michael Condon" <michael.condon@nrl.navy.mil> сообщил/сообщила в новостях > следующее: news:b98e94$662$1@ra.nrl.navy.mil... > > did you mean external ?!? > > "Mikhail" <kostkin@asicdesign.ru> wrote in message > > news:b983v1$al2$1@news.wplus.spb.ru... > > > Could anyone recommend me flash-disk with IDE/ATA for "extremal" > > > application? > > > > > > I found BiTMICRO (www.bitmicro.com) but few of thier technical > > > characteristic seems strange ... > > > > > > > > > > > > > > >Article: 55437
Hi Josh, the grey hairs were only caused by setting some attributes wrong and then wondering that it didn't work as I expected it. Just the normal user-error. 8o) Regarding the power: the figure you state is a little bit high for below 1Gig and would apply for about 2.5 Gig. At 1 Gig you can probably expect something in the size of ~200 mW/channel. Have a look at the data-book, there are more accurate figures there. Cheers, Martin Josh Model wrote: > I was just getting started playing with these guys, and I was wondering > about the "grey hairs" you mention. From the documentation I was looking > at, it seemed that realatively low speed rocketIO block-- e.g. < 1 GB/sec-- > consumed in the hundreds of milliWatts (~300 if I remember correctly). is > this figure way off in one direction or another? > > --Josh > > "Martin Kellermann" <martin.kellermann@nospam.xilinx.com> wrote in message > news:3EB79679.4060904@nospam.xilinx.com... > >>Hello Andreas, >> >>the easisiest way to start working with the Rocket-IOs is to make the >>simplest design you can imaginge: just transmitting 1s and 0s. From >>there you can playing with the more sophisticated things like >>clock-correction, comma-detection etc. >> >>If you want to get VHDL-code, the easiest way is to use the Architecture >>Wizard that comes with the ISE-software to roughly configure the macros >>to your like. After that you can get the VHDL-code for that >>configuration which you can directly use in ISE. If you want to change >>anything you can do it directly in the VHDL. BTW: that's the way I >>normally do it as it is way too much work to write the complete >>MGT-instantiation for yourself (and error-prone, been down that road >>myself....) >> >>Apart from that, what do you need to consider: >>- a very good clock, the higher your speed, the better your clock needs >>to be >>- a good power-supply, if you just want to play at the beginning use a >>nice big lab power-supply that will avoid a couple of grey hairs. >> >>Cheers, >> >>Martin >> >> >>Andreas Wortmann wrote: >> >> >>>hi, >>> >>>i start using the rocket-io transceiver macro on the xilinx virtex-II >>> > pro > >>>device. does anybody have >>>- or know of - some simple sample vhdl-code to start out with ? at this >>>stage i do not aim at a specific >>>transmission protocol, but i want to prove the device working. are there >>>other important things i have >>>to account for ? >>> >>>thanks, >>>andreas >>> >>> >>> >>> > >Article: 55438
Hi, Is there a way to protect the bitstream file contained in the configuration-ROM from piracy? I'm using XC2S50 and WebPack5.2i SP2. Thanks for ideas Gerald.Article: 55439
Hello, We are using a PCI-Card with Virtex-300E FPGA and have both C and VHDL Code for the whole system. We fancy switching to systemC but I am not yet sure that a direct conversion of our VHDL Code to SystemC is possible. We would do it manually but only if we can be sure that the whole system of software and hardware is then implemented in systemC. But what about the hardware-part of the system? Is there a way to compile / synthesize RTL-SystemC Code directly to a bitstream that can be downloaded to the FPGA just liek we are used to it with VHDL? Is it possible for Virtex-II only or also the older FPGAs? Thanky you for your help, JoachimArticle: 55440
Thanks - I had tried putting an 'if false then ... end if;' around all my log-to-file stuff, but I'll try putting a deallocate() after each writeline() instead. "Allan Herriman" <allan_herriman.hates.spam@agilent.com> wrote in message news:pdg2bvsvd6i56176ta0lnvde5rr40o66vm@4ax.com... > On Thu, 1 May 2003 16:07:08 +0100, "Michael Attenborough" > <michael_aht_brainboxes_doht_com@say.it> wrote: > > >I've got a testbench that takes a long time to run, and as it runs the > >memory usage of ModelSim slowly ramps up. After about 5 million simulated > >clock cycles, I'm out of memory. > It is quite possible to have a memory leak in your VHDL, particularly > if you are using 'write' to generate strings. > > http://groups.google.com/groups?as_q=memory%20leak&as_ugroup=comp.lang.vhdl > > I have observed memory leaks in modelsim itself as well, mostly in the > GUIArticle: 55441
Russell Shaw wrote: > http://pcworld.idg.com.au/index.php?id=1074796437&eid=-108 > > Install linux. Go open-source. Avoid chip makers > getting in cahoots with an inferior OS. That's another thing... But sometimes it appears to me that the big bosses of media industry are being blinded by some "smart" guys. They are telling them: "Hey, we can build up an infrastructure that makes it impossible to copy anything AS IT IS." Of course, they might be able to do that and receive lots of money. Unfortunately, some of us (i.e. the developers) are also living from that money. But what they mostly forget is the fact that finally an audio stream has to leave the speaker uncoded and a video stream has to leave a display uncoded. At least at this point everything can be captured and copied. Today, this could be done at a lower level (i.e. sampling a line audio signal), but even this might change in future. Some do not forget this fact and as an argument they bring up the quality aspect. I.e.: "Ok, you can copy it, but not without loss of quality." However, when almost everybody is happy with MP3, this argument becomes virtually unusable in reality. And even more worse, we are pushing our technology more and more. At some day we will probably have speakers, displays, micros, and cameras with such a good performance, that one really can make high-quality copies even in the case when the contend is highly crypted (from carrier to the displays). Regards, MarioArticle: 55442
On Thu, 8 May 2003 11:28:37 +0100, "Michael Attenborough" <michael_aht_brainboxes_doht_com@say.it> wrote: >Thanks - I had tried putting an 'if false then ... end if;' around all my >log-to-file stuff, but I'll try putting a deallocate() after each >writeline() instead. I believe writeline() already contains a deallocate(). You might like to move this thread to news:comp.lang.vhdl Regards, Allan.Article: 55443
Hi Dennis, I logged a SIGSEGV bug some time ago (could have been for the 5.6d release) which was fixed in a later released. I would suggest you download the latest 5.7c released. Regards, Hans. www.ht-lab.com "Dennis Maasbommel" <aabbccdd00@hotmail.com> wrote in message news:n0iua.1371478$sj7.57488504@Flipper... > Hi Folks, > > Using FPGA Advantage V5.4 on my WinXP SP1 system, > I am having some problems with the integrated modelsim (v5.6d) > component. > > After a succesful compilation, I try to simulate the model, > But with many models I get this error > > ** Fatal: (SIGSEGV) Bad pointer access. > > > I searched using Google and it took me to the GNU C Library, > where this error was explained; From this point my guess is > that maybe Modelsim is not suitable for WinXP yet. > > I have tried all the compatibilty modes > (i.e. win95, win98/winME, winNT4 SP5, win2k) > but neither of these modes prevented modelsim from > generating this error. > > I have also tested a very simple model, which COULD be simulated, > but unfortunately Modelsim collapsed (program exits without further notice) > when I wanted to add signals to the wave-table. I guess maybe this has > someway the same cause as the 'Bad Pointer Access'-error. > > Beside this behavior, I have no other clue that my installation > version is corrupted > > Does any of you have experienced likewise problems with this tool, > and/or know how to solve these problems? I would be glad to hear it! > > Best Regards, > Dennis Maasbommel > >Article: 55444
In article <D6bua.99171$iy5.3041077@twister2.libero.it>, lorenzo.lutti@DOHtiscalinet.it says... > I've found these preliminary specifications in the Xilinx site: > > http://direct.xilinx.com/bvdocs/publications/ds123.pdf > > Do you know if these devices are already in production? If not, when > will they be (hopefully :))? I've heard the 4 meg parts will start sampling soon, then be avaiable in June. The other parts will show up in Q3/03 and Q4/03. I'd use XC18Vx parts if you need something now... -- Greg Deuerling Fermi National Accelerator Laboratory P.O.Box 500 MS368 Batavia, IL 60510 (630)840-4629 FAX (630)840-5406 Electronic Systems Engineering Group Work: egads_AT_fnal.gov, remove '_AT_'Article: 55445
Looking at the app. note, I notice that I have the delayed data sort of implemented already. I tried using the clock as a CE and got my application to fail all the time rather than intermittantly. At least it confirmed my problem. However, I had a fast clock which I'm now using to latch my slower clock and although they are asynchonous, the problem appears to have been solved. Thank you for all your help on this.Article: 55446
I will start my first FPGA Design. We have a software named Protel DXP von Altium. Have anybody experience with this Software? Thanks. HaraldArticle: 55447
FUT set to comp.os.linux > "Michael A. Covington" <Michael@CovingtonInnovations.com> wrote in message > news:8LCcnXVv-5oYwCejXTWcog@speedfactory.net... >> I know that was a troll, but: >> >> (1) Rapid progress (or at least rapid change) >> (2) Multiplicity of sources >> (3) Standardization (4) Full Control for the user (5) Ease of use >> >> Choose any two. two's not enough to get a clear picture. >> >> The Windows crowd chooses (1) and (3). and (5) >> The Linux crowd chooses (2) and (3). and (1) and (4) and are working on (5) >> Microcontrollers have (1) and (2). No comment since I don't know that much about microcontrollers. regards NPVArticle: 55448
In article <a94f6476.0305080150.32401838@posting.google.com>, Gerald Bretschneider <gerald.bretschneider@dresden-elektronik.de> wrote: >Hi, >Is there a way to protect the bitstream file contained in the >configuration-ROM from piracy? I'm using XC2S50 and WebPack5.2i SP2. Not on a Spartan, sorry. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 55449
Russell Shaw wrote: > http://pcworld.idg.com.au/index.php?id=1074796437&eid=-108 > > Install linux. Go open-source. Avoid chip makers > getting in cahoots with an inferior OS. And crossposting flamebait to 10 newsgroups is better?
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