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
Recently Xilinx has changed process for XC900 series from 0.6u to 0.5u, see also http://www.xilinx.com/partinfo/notify/pcn9803.htm . Since that, some 30% of chips of a certain design work, other designs work on 70% of chips, and some don‘t work at all. Has anybody the same problem? Are those chips suffering from ESD? Or do they have some problem with powersupply or do they latch up more easily? Do failiures affect 9572-15, or also other types? Jedec‘s are not under suspect anymore: Failiures are seen also in designs without any asynchronous path at all. Any hints appreciated. BR GenioArticle: 19551
Thanks for the information. :-) I will try to find the book you mentioned. from Joe Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19552
From the message posted by Steen Larsen, it seems that it is very difficult for OpenCore project to work on latest version of PCI right from the start. So maybe we can just concentrate on PCI 2.x using 33MHz and 32 bit? :-) In article <84e8da$1ae2$1@noao.edu>, "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> wrote: > Magnus Homann wrote in message ... > >"Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> writes: > > > >> mcjy@my-deja.com wrote in message <84cs87$k4m$1@nnrp1.deja.com>... > >> > >> >For PCI core, now the market is moving > >> >to PCI-133. But prototyping (for testing) > >> >can be a big problem. Most FPGAs/CPLDs only > >> >support up to PCI 66. In addition, I think > >> >that we need to "buy" PCI specification > >> >document. Is it still true? > >> > >> Methinks you're confusing the PC-133 memory standard with PCI. The > fastest > >> PCI standard is 66 MHz and a 64-bit-wide data/address bus. > > > >He might be talking about PCI-X. I've heard rumours that FPGA vendors > >are looking into it. > > I just checked the web site Joe referred to. I stand corrected! > > I have the Mindshare book but I haven't had a chance to do much more than > glance at it. > > -- > ----------------------------------------- > Andy Peters > Sr Electrical Engineer > National Optical Astronomy Observatories > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) noao \dot\ edu > > The secret of Slurm is on a need-to-know basis. > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19553
mcjy@my-deja.com writes: > From the message posted by Steen Larsen, > it seems that it is very difficult for OpenCore > project to work on latest version of PCI > right from the start. So maybe we can > just concentrate on PCI 2.x using 33MHz > and 32 bit? :-) The PCI 2.2 spec _replaces_ the PCI 2.1. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 19554
Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid> writes >Hi friends, >I have now got CD from Actel with actel software, veribest and synplify >But I can't make it working. After Actel dectop run it says: "Error >reading licens file"! >Have to get extra licens? >(I have found nothing about this in Documentation) Extract from win95.htm in root on Actel Desktop CD V1.1, March 1999, (305922R1) "Obtaining a License Use the following procedure to obtain a license to run the Actel DeskTOP software: 1. Click the "License Registration" button from the CD start-up browser screen. 2. Fill in the information requested by the licensing application. 3. Paste the information from the clipboard into an e-mail and send to desktop@actel.com. Do not send the information as an attachment to the email. 4. License requests must be sent as the text of an email. Your license will be e-mailed to you in about 1 day. " -- dmacArticle: 19555
Thanks for the response, but I'm afraid that this isn't the problem either because we are doing exactly what you suggested that we do. We have also tried configuring it in slave-serial mode (yes, m2..m0 are set correctly) and it also says the download was successful. I have even tried running this with and without I/O parameters set (lvttl, 2ma, 4ma). Only once did it actually output something. Ever since then it has been dead as a doornail. A small test design was downloaded into a XC4005E and functioned properly. When it was retargeted for the XCV1000 we did not see any output. If you can help us with this, we would greatly appreciate it. Thanks. In article <84e47m$h0s$1@bgtnsc01.worldnet.att.net>, "peter dudley" <padudle@worldnet.att.net> wrote: > Timothy > > The JTAG configuration interface is a bit misleading. It will say it > configured just fine even though it has not gone through startup. Nicolas > helped me with this one in an earlier post if you have the same problem that > I had. > > You need to go into the design->options menu. Click on edit options next to > configuration and select the startup tab. For the startup clock source > select JTAG. > > Hope that's it. > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19556
Magnus Homann <d0asta@licia.dtek.chalmers.se> wrote in article <lt7lhwpzna.fsf@licia.dtek.chalmers.se>... > "Austin Franklin" <austin@darkroo99m.com> writes: > > > As you said, per the PCI spec (contrary to the original posters ascertain) > > in a 5V signaling environment, the system board manufacturer is not > > required to provide 3.3V to the connectors. > > They are required to put in 3.3V in PCI 2.2. The old PCI 2.1 didn't > require the 3.3V power rail in a 5V environment, though. > > [...] > > > As was stated, if you want to make a 33MHz PCI card, and you require 3.3V > > on your board, you have to provide the regulator on board and make 3.3V > > from the +12 or the +5... > > Unless the motherboard is PCI 2.2 compliant. I think making the 3.3V > optional was a big mistake. If I was making a PCI card, I would not count on the 3.3V being there, since there are hundreds of MILLIONS of system boards without the 3.3V there....so if you want to sell cards, which is what I believe most manufacturers goal is, use an on board regulator.... Just my opinion...Article: 19557
Dear All. I never programm ALTERA's MAX7000 before. What will do with EPM7064SLC (for exemple) if I programm it with mistaked data and after programm plug card with that chip to computer's slot. (I programm it by ISP) MAX will crash? When I programm GAL20V10 with mistaked data, that the computer would not started, but GAL and computer were alive. Does everyone has some experience? Thanks. Alexandr Kouchtch Entry Ltd. http://ic.book.kiev.uaArticle: 19558
I noticed they've added the option to encode state machines Zero-Hot in the latest Foundation release... what's the advantage if any to this? Does it just remove a level of logic if your state machine drives negative logic outputs? Does it make state transitions faster or anything like that? thx m Matt Billenstein http://w3.one.net/~mbillens/ REMOVEmbillens@one.netArticle: 19559
Hi ! I'm writing VHDL codes to be run on Altera Flex 10K100E. Currently using Altera's Maxplus2 9.3. From the specs, it has a total RAM of 49152 bits. My question is: how can i make use of the RAM? whenever i define an array, variable or signal in VHDL , I realize that the RAM is not being used. What should I do to force it to use the RAM? Thank you! MKYapArticle: 19560
You need to use the LPM library components. On your on-line help in Maxplus 2, you can see items like lpm_ram_dq and some other RAM components. To use these components, you also need to include the LPM libraries. (There are examples in the help.) from Joe In article <84hclo$ob8$1@clematis.singnet.com.sg>, "MK Yap" <mkyap@ieee.org> wrote: > Hi ! > > I'm writing VHDL codes to be run on Altera Flex 10K100E. Currently using > Altera's Maxplus2 9.3. From the specs, it has a total RAM of 49152 bits. > > My question is: how can i make use of the RAM? whenever i define an array, > variable or signal in VHDL , I realize that the RAM is not being used. What > should I do to force it to use the RAM? > > Thank you! > > MKYap > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19561
Hallo all whoever knows how to explain me that type of error is the following (Active [vhdl]): Error: ELBWRITE_0001: combfiltvht.vhd : (88, 0): INTERNAL ERROR: mbeflib.cpp(6691). found while I built the library for the Coregen. Thanks Claudio Casagrande DSP lab. Univ. of Perugia Italy mariotto@libero.itArticle: 19562
"Austin Franklin" <austin@d33arkroom.com> writes: > Magnus Homann <d0asta@licia.dtek.chalmers.se> wrote in article > <lt7lhwpzna.fsf@licia.dtek.chalmers.se>... > > "Austin Franklin" <austin@darkroo99m.com> writes: > > > > > As you said, per the PCI spec (contrary to the original posters > ascertain) > > > in a 5V signaling environment, the system board manufacturer is not > > > required to provide 3.3V to the connectors. > > > > They are required to put in 3.3V in PCI 2.2. The old PCI 2.1 didn't > > require the 3.3V power rail in a 5V environment, though. > > > > [...] > > > > > As was stated, if you want to make a 33MHz PCI card, and you require > 3.3V > > > on your board, you have to provide the regulator on board and make 3.3V > > > from the +12 or the +5... > > > > Unless the motherboard is PCI 2.2 compliant. I think making the 3.3V > > optional was a big mistake. > > If I was making a PCI card, I would not count on the 3.3V being there, > since there are hundreds of MILLIONS of system boards without the 3.3V > there....so if you want to sell cards, which is what I believe most > manufacturers goal is, use an on board regulator.... Sure, I agree. And that is the problem with making the 3.3V optional. You can't gurantee that there is 3.3V, so you have to make your own, even if there is 3.3V available.qq As a side note, a board manufacturer, who shall remain nameless, made the 3.3V optional by using a regular jumper to connect the 3.3V from the motherboard power plane to the slot. That had the effect that the voltage went down to 3.15V at the dauhgter board. Which happens to be the lower limit for certain devices... Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 19563
I'm looking at an FPGA for project I'm working on and am concerned about security. CPLD's and ASIC's I'm familiar with but FPGA's are a new trick for me. I'm looking at Altera and Xilinx. It appears that most FPGA's are programmed with a serial eeprom. I'm concerned about the security the data in the eeprom. What keeps someone from simply copying your eeprom to duplicate your FPGA's programming? Maybe this is a stupid question but I'm still learning about FPGA's. Since I will have some encryption / decryption functions in the FPGA, this is a big concern for me. What do you need to do to protect your design when using FPGA's ? thanks, Larry E. Remove Spam_me_not to reply via email.Article: 19564
In article <RB5b4.1138$B9.1418518@feed.centuryinter.net>, Larry Edington <larryeSpam.Me.Not@centuryinter.net> wrote: >I'm looking at an FPGA for project I'm working on and am concerned about >security. CPLD's and ASIC's I'm familiar with but FPGA's are a new trick for >me. > >I'm looking at Altera and Xilinx. > >It appears that most FPGA's are programmed with a serial eeprom. I'm >concerned about the security the data in the eeprom. What keeps someone from >simply copying your eeprom to duplicate your FPGA's programming? Nothing. It really depends on how security paranoid you are. If you want to eliminate unsophisticated copying and all but the most sophisticated copying (taking apart the chip), use an eeprom based programmable device. If you REALLY want protection, use an sram based FPGA with a continual battery backup, so the device is always on. Any disturbance to the power will erase the device. >Maybe this is a stupid question but I'm still learning about FPGA's. Since I >will have some encryption / decryption functions in the FPGA, this is a big >concern for me. What do you need to do to protect your design when using >FPGA's ? I really wouldn't be paranoid about the functions. A good security system's security rests in the key/secret DATA, not in the algorithm. So I'd be paranoid about the data. This would suggest an always on device with battery backup. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 19565
Larry,
depending on the total gate count you could
consider using Actel's ProAsic SX... family (100k gates) or
Lattice's 2000/5000/8000 family (42k)
These offer 100% IP protection (if the security bit is on ...).
Things depend upon whether you are talking about 100 pieces
or 100k pieces, the latter I would return to an Asic approach.
look at: www.optimagic.com
www.actel.com
www.latticesemi.com (Lattice Semi Corp & Vantis Corp.)
regards,
Michel HEUTS
WMU Belgium
Article: 19566Larry Edington wrote: > It appears that most FPGA's are programmed with a serial eeprom. I'm > concerned about the security the data in the eeprom. What keeps someone from > simply copying your eeprom to duplicate your FPGA's programming? An alternative might be to program the FPGA from the host computer. What prevents someone from copying your software and using it somewhere else? There are several means (like putting an unique numbers generated by the program into RAM) to customize the bitstream in the host computer to make sure that the FPGA will not function without the host software. BTW, this just moves the problem. How do you protect the software? This has another advantage: you can change the encryption / decryption function by just updating the software for your authorized users. > Maybe this is a stupid question but I'm still learning about FPGA's. Since I > will have some encryption / decryption functions in the FPGA, this is a big > concern for me. What do you need to do to protect your design when using > FPGA's ? It isn't easy to reverse engineer the configuration bit stream. Some parts of the configuration are "public", like the initial contents of RAM locations, making them easy to customize for each download. Some parts are not, such as the interconnect programing. Picture your design as a pile of logic gates with the wires gone. To fill in the wires would take a large and determined effort. Who are you trying to protect against, and why, and for how long? This is going to determine the levels and kinds of protection you need. -- Phil Hays "Irritatingly, science claims to set limits on what we can do, even in principle." Carl SaganArticle: 19567
I agree. I wrote an app note (XAPP092, page 14-40...43 in the 99 Xilinx data book) that describes the alternatives in a bit more detail. Happy New Year! Peter Alfke, Xilinx Applications =================================================== "Nicholas C. Weaver" wrote: > In article <RB5b4.1138$B9.1418518@feed.centuryinter.net>, > Larry Edington <larryeSpam.Me.Not@centuryinter.net> wrote: > >I'm looking at an FPGA for project I'm working on and am concerned about > >security. CPLD's and ASIC's I'm familiar with but FPGA's are a new trick for > >me. > > > >I'm looking at Altera and Xilinx. > > > >It appears that most FPGA's are programmed with a serial eeprom. I'm > >concerned about the security the data in the eeprom. What keeps someone from > >simply copying your eeprom to duplicate your FPGA's programming? > > Nothing. > > It really depends on how security paranoid you are. If you > want to eliminate unsophisticated copying and all but the most > sophisticated copying (taking apart the chip), use an eeprom based > programmable device. > > If you REALLY want protection, use an sram based FPGA with a > continual battery backup, so the device is always on. Any disturbance > to the power will erase the device. > > >Maybe this is a stupid question but I'm still learning about FPGA's. Since I > >will have some encryption / decryption functions in the FPGA, this is a big > >concern for me. What do you need to do to protect your design when using > >FPGA's ? > > I really wouldn't be paranoid about the functions. A good > security system's security rests in the key/secret DATA, not in the > algorithm. So I'd be paranoid about the data. This would suggest an > always on device with battery backup. > > -- > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 19568
Joe had suggested using LPMs. Which is a nice choice. In order to use the RAMs, you need to use the EABs. As a side note, the EABs may also be used for decode logic. At least last year MaxPlus2 was not capable of synthesizing EABs (i.e.: If you had a decoder that would fit into an EAB it would not place it in the EAB automatically, unless you explicitly instantiated it.) I suspect this had not changed. Other than using LPMs, Altera offers some type of macro generator that allows you to instantiate logic into the EABs. Sorry I can't recall off the top of my head how its done, but it does take a few steps to set up. The process incolves generating VHDL for simulation, and some form of netlist for synthesis. Take a look in their bin directory for the executable that does it, and of course look in the Altera documentation. I've never tried the LPM solution, but it is probably closer to a "technology independent solution", so it may be more attractive. Good luck, Michael MK Yap <mkyap@ieee.org> wrote in message news:84hclo$ob8$1@clematis.singnet.com.sg... > Hi ! > > I'm writing VHDL codes to be run on Altera Flex 10K100E. Currently using > Altera's Maxplus2 9.3. From the specs, it has a total RAM of 49152 bits. > > My question is: how can i make use of the RAM? whenever i define an array, > variable or signal in VHDL , I realize that the RAM is not being used. What > should I do to force it to use the RAM? > > Thank you! > > > MKYap > >Article: 19569
Terje Mathisen wrote: > Kelly Hall wrote: > > > > On Wed, 29 Dec 1999 15:45:20 -0000, J.R. <j_robby@hotmail.com> wrote: > > >Does anybody know where I can find an algorithm for Radix-2 online division > > >(Radix-2 serial Signed Digit arithmetic) with a constant divisor. I need > > >such a unit for a hardware implementation onXC4000 FPGA. I had a look at > > >Ercegovac's book entitled " Digit Recurrence algorithms and implementations" > > >but have not found a special algorithm for constant divisor. If someone can > > >point me directly to an FPGA implementation, that would be great! :-) > > > > If you are dividing by a constant, can't you just multiply by the > > reciprocal instead? Implementing a constant multiplier boils > > down into some adder trees with various shifts of the input word. > > Right. > > It can be proven that any N-bit / N-bit -> N-bit division can be > emulated exactly with a truncated/scaled multiplication by a reciprocal > constant with at the most N+1 significant bits. > > The simplest algorithm to locate this constant is to first locate the > nearest power of two which is smaller than the divisor, shift this > number left by N bits and then divide by the divisor. > > If the remainder is greater than half the divisor, then simply increment > the N-bit division result for and N-bit reciprocal. > > Otherwise, you need to add an extra 1 bit at the end, giving a (N+1) bit > reciprocal. > > To use this, simply multiply by the reciprocal and shift right to > correct for the initial scaling of the reciprocal. > > Terje > > -- > - <Terje.Mathisen@hda.hydro.com> > Using self-discipline, see http://www.eiffel.com/discipline > "almost all programming can be viewed as an exercise in caching" Any chance of a simple example or reference to the proof Terje ? Thanks, RussArticle: 19570
I'm not concerned about a hacker obtaining the contents of the 'logic' in the FPGA. That I know would be very difficult and those with the resources to do so would spend those resources designing a new device from scratch. My biggest concern is simple copying. If an FPGA is programmed with a configuration eeprom, then won't simply copying that configuration eeprom allow you to put a blank XYZ FPGA on a board with your copy of the eeprom, and thus duplicate my programming on my board? Or am I not understanding the basics of FPGA programming? I realize a device that doesn't use a configuration eeprom that is programmed strictly internally with a security bit set is sufficient for my security needs. Just like an old PLD and it's programming fuse. But, I'm still unclear what that external eeprom devices opens up to a hacker. I did notice an app note on the Xilinx page where a security bit can be set on a config eeprom that prevents reading from the jtag port. If a device programmer couldn't read it as well then this would be sufficient for my design. Thanks for all the replys so far! Larry E. Larry Edington <larryeSpam.Me.Not@centuryinter.net> wrote in message news:RB5b4.1138$B9.1418518@feed.centuryinter.net... > I'm looking at an FPGA for project I'm working on and am concerned about > security. CPLD's and ASIC's I'm familiar with but FPGA's are a new trick for > me. > > I'm looking at Altera and Xilinx. > > It appears that most FPGA's are programmed with a serial eeprom. I'm > concerned about the security the data in the eeprom. What keeps someone from > simply copying your eeprom to duplicate your FPGA's programming? > > Maybe this is a stupid question but I'm still learning about FPGA's. Since I > will have some encryption / decryption functions in the FPGA, this is a big > concern for me. What do you need to do to protect your design when using > FPGA's ? > > thanks, > Larry E. > Remove Spam_me_not to reply via email. > > > >Article: 19571
Larry Edington wrote: > > I'm not concerned about a hacker obtaining the contents of the 'logic' in > the FPGA. That I know would be very difficult and those with the resources > to do so would spend those resources designing a new device from scratch. I agree. > My biggest concern is simple copying. > If an FPGA is programmed with a configuration eeprom, then won't simply > copying that configuration eeprom allow you to put a blank XYZ FPGA on a > board with your copy of the eeprom, and thus duplicate my programming on my > board? Or am I not understanding the basics of FPGA programming? Yes, you are entirely correct. OTOH a clone of your programmed FPGA is likely useless without either your documentation, or the board (and its host software) on which your FPGA resides. So one possible approach is to protect the design and/or software of everything *except* the FPGA, and make sure the FPGA has a reasonably arcane interface so it's very difficult to reverse engineer its *behaviour*. In this way, you're putting yourself in the same position as if you had just discovered that some manufacturer's wonder-IC did exactly what you need. So you design a killer product around that wonder-IC. But once the pirates have opened your box they can easily buy a new copy of the wonder-IC. How do you protect your product investment? Answer: code-protected microcontrollers, tricksy hidden wiring, all the usual stuff. > If a device programmer > couldn't read it as well then this would be sufficient for my design. I doubt it. If the FPGA can read the bitstream during config, then anyone else can do likewise. Indeed, it is always possible to tap in to the bitstream *during* configuration and read it that way, so you don't need to pull the EPROM from the circuit. It's probably been mentioned already in this thread, but I'll mention it anyway: the *only* way to protect an SRAM FPGA effectively is to download config to it at a secure site, then rely on battery backup to keep it alive. Used by the military for one-shot devices (cruise missiles etc). Or go for an antifuse solution. Jonathan BromleyArticle: 19572
Austin Franklin <austin@darkroo99m.com> wrote in message news:01bf5281$f4c73ce0$207079c0@drt1... > > A 5V card will not work in a slot keyed for 3.3V, nor will a 3.3V card work > in a slot keyed for 5V. A universal card will work in either, but as I > said, I don't believe there are any 'main stream' cards being made to be a > PCI universal card... Actually, not too long ago at work we had occasion to dig around and try to find some universal cards. The only two we found were both Ethernet cards... an Intel EtherExpress and a NetGear FA310TX. I would say that I've never seen a 3.3V-only card! > 66MHz does require 3.3V signaling though...and does not support 5V > signaling. A lot of the potential power of 66MHz PCI seems to be wasted due to what appear to currently only be point to point connections (chipset to one, and only one, 66MHz PCI slot). Hopefully this will change in a future revision of PCI (PCIx?). > As was stated, if you want to make a 33MHz PCI card, and you require 3.3V > on your board, you have to provide the regulator on board and make 3.3V > from the +12 or the +5... LT1587s (and clones thereof) seem very popular for this task. ---Joel KolstadArticle: 19573
Mariotto <mariotto@libero.it> wrote in message news:B2%a4.1910$Oo1.29441@news.infostrada.it... > Hallo all > > whoever knows how to explain me that type of error is the following (Active > [vhdl]): You'll probably need to send us (or Aldec) your code. In my experience, Internal Errors in ActiveHDL are caused when ActiveHDL thinks you're trying to be excessively clever about something, when in reality you probably just have a syntax error. I've also seen it bomb if you've been compiling things out of order, and it runs off and tries to bind, say, a more recently compiled file with a newer component declaration to an older actual component. In this case, go over to the library manager, empty the library, and re-compile everything in the proper order. ---Joel KolstadArticle: 19574
Larry,
apart from using large (deterministic and fast) 42k - 100k gates
CPLDs with internal configuration memory
(Cypress Delta 39k - Actel ProAsic - Lattice 5000/8000 - Xilinx XPLA -
Vantis 'Godfather family') you could ask yourself
if an additional 0.50$ US Microchip or XC76041 Xicor secure E²PROM could
give you the utmost security.
You could place an algorithm/state machine in your CPLD/FPGA communicating
with the secure Microchip PIC12Cxxx or
Xicor device - the addition of a random communication scheme could enhance
security. (depending on what the micro
sends the state machine could answer encrypted) that way wecurity is burned
in your CPLD and microcontroller sensing the
right CPLD/FPGA. (The User Encryption Signature is not part of the protected
region and is public accessible).
One secure microchip of 0.50 US $ could be a very big advantage against
expensive SRAM devices ...
Also note that configuration memory is sold (too) expensively.
regards,
Michel HEUTS
WMU Belgium
http://www.optimagic.com
"John Cain" <jjcain@goodnet.com> wrote in message
news:vLsb4.499$197.49682@news.goodnet.com...
> Larry,
>
> You concern is real. I do embedded design for a wide range of customers.
> I use a variety of FPGA & EPLD devices and I have yet to get an SRAM
device
> into production.
>
> Once the "SUITS" figure out that the SRAM device offers no IP security,
> management directs a different solution requiring either a hard version
for
> the SRAM part (such as offered by Xilinx or Altera/etc) or an ISP version
> with a security bit. For your application you should check if your
customer
> will accept an SRAM based FPGA as part of your design. For example, SRAM
> parts are not allowed in some military or high reliability applications.
>
> An ISP solution with a security bit is available from many vendors and
> certainly raises the bar of IP
> security in an FPGA, but is not totally secure.
>
> For example, one of my clients had a problem with an HR-1 eNGINEER who
liked
> the design so well that the one day he took it home and left nothing, but,
> the secured ISP test prototype. Contacting the mfg and 1st world
resources
> were of no help; everyone claimed the design was secure and the company
was
> screwed.
>
> In the third world, it cost a few thousand dollars and a couple of weeks
to
> reverse the ISP parts.
>
>
> John Cain, Power Processing, Inc.
> jjcain@goodnet.com, 602 549 6604V, 480 759 4675V/F
>
>
>
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