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
On Fri, 31 Dec 1999 17:32:35, nweaver@boom.CS.Berkeley.EDU (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. Depending on the level of security you're after, even this may not be "secure" unless you can secure the physical environment that it will be in. I did crypto key storage/management design (not classified) a few years ago. One of the scenarios we dealt with was an X-Ray attack on the key storage SRAM. SRAMs tend to harden in the state they're in when exposed to X-Rays. That is, they tend to prefer that state for subsequent power-on cycles. It sounds like a rather obscure attack (no I didn't test it ;-), but don't assume a powered SRAM is safe from all attacks. > >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. I'm in the camp that says (at least for commercial use) a known algorithm is better than an unknown one. The better it's known the more likely that someone has at least spent time trying to shoot it full of holes. However, a powered circuit isn't perfect - nothing is. Just like locking your house, the point is to expend enough effort on the defense to make the offender look elsewhere. This effort varies depending on what's at risk. ---- KeithArticle: 19576
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/FArticle: 19577
So it looks like I do understand after all. What I still don't understand is why Altera and Xilinx, who I think are the top 2 vendors of these parts, don't have ISP FPGA's with security bits. Or maybe they do and I just missed it. Next week I'll try to run down an Altera and Xilinx FE for a discussion of my needs. Antifuse won't work for me nor will SRAM battery backup methods. I need in field reprogrammability and I don't want a dead device due to dead batteries. It's not a military device and doesn't have to be super spook secure. I just wanted to make it hard for casual copying. I know it can be reverse engineered just like a 20L8 PLD can. But at least with a 20L8 you can't just pop it in a programmer and copy it if you set the security bit. Yea, you can pay to have it copied 'overseas' but at least you gotta pay. Thanks for all the help. Larry E. 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 > > >Article: 19578
On Sat, 1 Jan 2000 09:28:36 -0600, "Larry Edington" <larryeSpam.Me.Not@centuryinter.net> 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. > >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. >> ============================================================ If you have IP that's worth anything and particularly if you're using a BIG FPGA and little else on your circuit board (common, these days) and then having your first 100K boards made in Taiwan or Korea, you'd best consider that within a week of when production of your boards begins, someone will be collecting the junk boards from the PCB house. Next, they'll find your product and attach a logic analyzer to the data feed to your FPGA from the config rom, and within minutes have a copy of your config rom. Now they faithfully copy your documentation, then the cover of your boxes. Now they can build the complete product. Next, they sell the defective boards with counterfeit boxes and documents to unsuspecting distributors (with a blind eye turned to these risks!) and they then sell the boards to your potential customers. They, in turn, find out your product doesn't work, and you end up with twice as many RMA's out there as you've sold product. You replace the counterfeits with good product, and, soon, go out of business having lost your shirt, your house, your kid's bicycle, etc. Dick >Article: 19579
> If you have IP that's worth anything and particularly if you're using > a BIG FPGA and little else on your circuit board (common, these days) My FPGA will just replace a few other chips and contain some encryption routines. > and then having your first 100K boards made in Taiwan or Korea, you'd > best consider that within a week of when production of your boards > begins, someone will be collecting the junk boards from the PCB house. Which is why I'll not be going to Taiwan for the first 100K. ( I hope anyway ) > Next, they sell the defective boards with counterfeit boxes and > documents to unsuspecting distributors Since this is a corporate device, and won't be going to distributors for resale, but direct to the corporate end users, I'm not worried about that scenario. Now if I had done the latest and greatest kids toy, then yea, that'll probably all happen. IP theft is a BIG problem. That's why I just can't understand why the FPGA vendors haven't done something more about it. later, Larry E.Article: 19580
> What I still don't understand is why Altera and Xilinx, who I think are the > top 2 vendors of these parts, don't have ISP FPGA's with security bits. Or > maybe they do and I just missed it. Next week I'll try to run down an Altera > and Xilinx FE for a discussion of my needs. I think you may have missed a key point. There is nothing significantly different between "ISP" and loading via an EPROM. The configuration bits are on the pins where a logic anlayzer can grab them. As far as I can tell, there isn't any easy answer to this problem. -- These are my opinions, not necessarily my employers.Article: 19581
Actually, the software from VANTIS, now owned by LATTICE, is, indeed, free. Unfortunately, most of the smaller devices, and this applies not only to Lattice/Vantis, but to most others as well, require a relatively complex programmer which implements the programming algorithims that the component manufacturers won't give you and the larger parts are so pin-rich that you have little choice but to program them in-situ, which is inconvenient, since you can't socket them without spending more than what a programmer for the small devices would cost, and such large-pin-count packages are not very friendly to the hobbyist, particularly since you have to build them into a PCB. Dick On Tue, 07 Dec 1999 12:57:09 +0000, Tim Forcer <tmf@ecs.soton.ac.uk.nojunk> wrote: >Dan Rymarz wrote: >> >> Hello all, >> >> I am looking for a programmable logic technology I can use that >> also has a free+permanant (not 30 day trial) compiler available, >> that uses JTAG or similar few-wire (4 for jtag etc.) programming >> mode. I don't need a large gate count. ... > >Have a look at Lattice. They do an isp version of the trusty 22V10. >The starter pack software to handle this is based on ABEL - again a >trusty "standard". Software isn't free, but the deal on the starter >pack is normally pretty good, and includes some devices and a download >cable. Info at ><http://www.latticesemi.com/products/destools/ispstarter.html>. Lattice >also now incorporate Vantis (was AMD not that long ago), and there's a >similar starter kit for Vantis MACH parts ><http://www.latticesemi.com/products/destools/mstarter.html>. > >Best deals of all, in my experience, come when you go along to a >company's introductory "seminar" presentation. You pay for the day or >half-day, but get a free intro kit, plus manuals, plus several sessions >which are half-way between sales talk and "how-to" instruction. There's >a fair amount of opportunity for some hands-on evaluation of the >software. You sometimes get vouchers to use should you decide to buy >more of the stuff or to upgrade from starter kit to a higher level. >Look up the main distributors of Lattice, and try to find out when the >next "roadshow" comes somewhere near you. > >Usual warning I give to anyone getting into isp devices: take great care >with your power supply. ispICs incorporate an on-chip voltage >multiplier. If this sees a Vcc spike outside the absolute maximum >rating, it will turn the whole chip into an expensive multi-terminal one >Ohm resistor. Check the Vcc for spikes BEFORE fitting the isp stuff - >don't rely on the fact that you've used this for years with all manner >of 74 series and stick-it-in-the-programmer PLDs - those devices will >take up to 100% overload spikes and (most of the time) not even go into >a reset or malfunction mode, certainly won't suicide. > >-- >Tim Forcer tmf@ecs.soton.ac.uk >The University of Southampton, UK > >The University is not responsible for my opinionsArticle: 19582
Larry Edington <larryeSpam.Me.Not@centuryinter.net> wrote in message news:AAyb4.1186$B9.1484255@feed.centuryinter.net... > Antifuse won't work for me nor will SRAM battery backup methods. I need in > field reprogrammability and I don't want a dead device due to dead > batteries. So if you're going to be re-programming the devices in the field, what prevents anyone from capturing your ISP bitstream at that point? > It's not a military device and doesn't have to be super spook secure. I just > wanted to make it hard for casual copying. I know it can be reverse > engineered just like a 20L8 PLD can. But at least with a 20L8 you can't just > pop it in a programmer and copy it if you set the security bit. Yea, you can > pay to have it copied 'overseas' but at least you gotta pay. I think there's a significant difference between simply being able to copy a device and being able to reverse engineer it and obtain its IP. In the former case, it's seems to me that it's much easier to demonstrate that some law has been broken, and take the appropriate legal action. In the later case, if you have some system on a chip that has some nice PCI core, say an MPEG encoder/decoder, etc., and "they" got ahold of that and start using it in their own designs, you're probably completely out of luck trying to prove that any law was broken -- unless perhaps you can claim patent infringement, somehow. Can anyone name some commercial product that was counterfeited where the counterfeit products actually started eating (significantly) into the bottom line of the company that engineered the device? I've often felt that the IP piracy threat has been a little overblown at times, but I work for a relatively small company where the equipment we make is so specialized (and expensive) that it's pretty unconceivable that anyone would run off and attempt to replicate it -- hence I may have a warped perspective on this. ---Joel KolstadArticle: 19583
Larry, You are right. Better forms of FPGA protection are necessary. Currently, the only reasonable cost secured protected devices are UPs from Philips & Dallas. SRAM FPGAs could easily be made secure by the addition of a fixed DES Cell as part of the cmos FPGA circuit with a 56bit key OTP programmed. Now you can OTP the FPGA device key & encript the external configuration eeprom and everything remains protected. A DES cell would not be that big with current FPGAs based on <0.25u CMOS processes. Better FPGA protection is definitely necessary as digital embedded products become a single chip system based on an FPGA. John Cain, Power Processing, Inc., Phoenix, AZ jjcain@goodnet.comArticle: 19584
> So if you're going to be re-programming the devices in the field, what > prevents anyone from capturing your ISP bitstream at that point? More work to figure it out than to design it themselves from scratch. Plus several 'traps' are in the device that will render it inoperable. If a particular company keeps coming up with an unusual number of tampered units, then we know we have a problem. > Can anyone name some commercial product that was counterfeited where the > counterfeit products actually started eating (significantly) into the bottom > line of the company that engineered the device? IBM PC for one. later, Larry E.Article: 19585
Larry Edington <larryeSpam.Me.Not@centuryinter.net> wrote in message news:jVQb4.1213$B9.1529941@feed.centuryinter.net... > > So if you're going to be re-programming the devices in the field, what > > prevents anyone from capturing your ISP bitstream at that point? > > More work to figure it out than to design it themselves from scratch. I'm not following how... usually the in-circuit programming signals are very well defined by the device manufacturer, and turning them back into a bitstream seems very straightforward to me. > Plus > several 'traps' are in the device that will render it inoperable. Traps based on trying to detect reverse engineering, huh? Interesting. I have heard of approaches where there's a counter inside of a device that keeps track of how many, say, bus reads have occurred since the last access to a particular register. Every tenth thousandth read, or thereabouts, the device purposely "breaks" the standard bus protocol (e.g., runs off and flips a few of the data bits for the returned result); the software talking to the device has to be aware of how the break occurs and "correct" the "break." Somebody who sits down and attempts to reverse-engineer the design will hook the thing up to a logic analyzer and (presumably) never notice the broken access cycles, so their copy won't function correctly if they simply copy the original software as well. > > Can anyone name some commercial product that was counterfeited where the > > counterfeit products actually started eating (significantly) into the > bottom > > line of the company that engineered the device? > > IBM PC for one. I'm not so sure that's a good example. Arguably the original IBM PC didn't really contain much IP; it was not particularly different than an Intel reference design. The valuable thing about the PC, I would imagine, was in DOS 1.0 -- and that was already legally protected. ---Joel KolstadArticle: 19586
I only have the old 8.2 version of max here so I can't garantee that the paths will be the same but if you look in your maxplus2 directory you should find the "\vhdl93\altera\" directory. Inside this directory is the file maxplus2.vhd which is a vhdl package. The package contains common 74 series functions. You should be able to find components to do your business there. I only have the old cycle shared single port memory functions in mine but this is because the software I have was released before the part you are using. You should find VHDL components for all of the device specific functions in there. Merry new millennium. Andy. 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: 19587
Yep, I got bit by this too.. Gigabyte provides 3.5V to the 3.3V PCI power pins, this really messes with MAX7000A's , Soyo brings 3.3V ATX power to the PCI. I have a board that uses the 5V supply to run a 15W cpu, there's not enough margin left to run all the 3.3V logic, CPU I/O, and DIMMs. Rev2 will get its 3.3V Regulated From 5V using an extra floppy power connector, most ATX systems have 2. Still using the PCI 5V to get the 2.0 CPU CoreV. Am I asking for ground loop problems? On 31 Dec 1999 11:08:34 +0100, Magnus Homann <d0asta@mis.dtek.chalmers.se> wrote: >"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... > >HomannArticle: 19588
The problem with putting an OTP key in the device, is that the non-volatile cells can't be fabricated without additional process steps. The FPGA process is essentially the same as DRAM, which lets it be done with bleeding edge process. Put PROM cells on there, and you lose the speed. John Cain wrote: > Larry, > > You are right. Better forms of FPGA protection are necessary. > Currently, the only reasonable cost secured protected devices > are UPs from Philips & Dallas. > > SRAM FPGAs could easily be made secure by the addition of a fixed DES > Cell as part of the cmos FPGA circuit with a 56bit key OTP programmed. > Now you can OTP the FPGA device key & encript the external configuration > eeprom and everything remains protected. > > A DES cell would not be that big with current FPGAs based on <0.25u CMOS > processes. Better FPGA protection is definitely necessary as digital > embedded > products become a single chip system based on an FPGA. > > John Cain, Power Processing, Inc., Phoenix, AZ > jjcain@goodnet.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: 19589
Might help if you posted your small test design. Are you using the CLKDLLs for the virtex design? ALso, have your pins been assigned correctly? As a first step, you might open the design under the FPGA editor (formerly epic) and browse around to make sure it is what you though it was as far as clocks, resets, and io locations. Timothy Miller wrote: > 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. -- -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: 19590
These pins have a little extra logic associated with them for driving the clock enables on the output registers in the IOBs along the edge they are on. You can see the logic block and it's connections if you look at the middle of the edge in the FPGA editor. So what makes these pins special is that they provide a very fast clock enable to the outputs. Xilinx's position is that this function is unsupported except for use with their PCI interface macro. peter dudley wrote: > Hello All > > I was looking at my .pad report file for a new Virtex design and I noticed > something new. > > Under the "Dedicated or Special Pin Name" section, pins called IRDY and TRDY > are each listed twice. On the TQ144 package they are on pins 53 and 56 but > then they are repeated on pins 130 and 127. > > IRDY and TRDY are signal names in the PCI standard. Are these pins special > in any way on the Virtex chip? Do they have special drive strengths to meet > PCI requirements? > > Any insight would be appreciated. > > Pete > > -- > Pete Dudley > > Arroyo Grande Systems Incorporated -- -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: 19591
I'm not sure I understand your question. The FG and H function generators are a part of the CLB. Each 4K CLB contains two FG generators (4 input look-up tables) and one H generator (3 input LUT). Read the data sheet to understand the structure. You really should have at least a basic understanding of the structure before doing a design in the part. wannarat wrote: > Dear All > after I synthesis the design I found that FG and H function in FPGA > are very big. > They used about nearly 300 % of the resource while used CLB only 30%. > How can reduce or optimize or .. suggest me? > > Best REgard > Wannarat > > -- > Wannarat Suntiamorntut > Computer System Design Laboratory (CSDL) > Computer Engineering Department > Prince of Songkla University, Hatyai, Songkla 90112 Thailand > Tel. 66-074-212895 ext.311 Fax. 66-074-212895 > -- -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: 19592
On Sun, 2 Jan 2000 13:44:13 -0800, "John Cain" <jjcain@goodnet.com> wrote: >Larry, > >You are right. Better forms of FPGA protection are necessary. >Currently, the only reasonable cost secured protected devices >are UPs from Philips & Dallas. > >SRAM FPGAs could easily be made secure by the addition of a fixed DES >Cell as part of the cmos FPGA circuit with a 56bit key OTP programmed. >Now you can OTP the FPGA device key & encript the external configuration >eeprom and everything remains protected. > >A DES cell would not be that big with current FPGAs based on <0.25u CMOS >processes. Better FPGA protection is definitely necessary as digital >embedded >products become a single chip system based on an FPGA. 56-bit keys aren't much use these days. if you have secure information, you should probably be encrypting with 1000-bit keys, which should give security for the next few years. A 512-bit key was recently cracked (RSA-155) - IIRC, this took about 35 CPU years, including time on a cray, but this will probably become commonplace over the next couple of years. i don't think putting encryption hardware on the silicon is necessary. at the minimum, all the silicon needs is 1024 bits of 'secure' OTP memory, and some mechanism to drive the configuration process from an existing configuration (ie. divide the chip into 2 separate configuration areas, and drive the JTAG chain internally). you could then load your uncoded decryption engine from PROM, and use your unique OTP'd key to decode the rest of the bitstream, and program the remainder of the device. evanArticle: 19593
From article <84da08$nne$1@news.qub.ac.uk>, by "J.R." <j_robby@hotmail.com>:
>
> Does anybody know where I can find an algorithm for Radix-2 online division
> (Radix-2 serial Signed Digit arithmetic) with a constant divisor.
See http://www.cs.uiowa.edu/bcd/divide.html
for a tutorial on division by reciprocal multiplication. The
tutorial uses the example of division by 10 to 16 bits precision,
but the method generalizes to other divisors. Here is the solution
that the tutorial gives at the end. This code has been exhaustively
tested:
unsigned int A;
unsigned int Q; /* the quotient */
Q = ((A >> 2) + A) >> 1; /* Q = A*0.101 */
Q = ((Q ) + A) >> 1; /* Q = A*0.1101 */
Q = ((Q >> 2) + A) >> 1; /* Q = A*0.1001101 */
Q = ((Q ) + A) >> 1; /* Q = A*0.11001101 */
Q = ((Q >> 2) + A) >> 1; /* Q = A*0.10011001101 */
Q = ((Q ) + A) >> 1; /* Q = A*0.110011001101 */
Q = ((Q >> 2) + A) >> 1; /* Q = A*0.100110011001101 */
Q = ((Q ) + A) >> 4; /* Q = A*0.0001100110011001101 */
/* Q = A/10 exactly */
Doug Jones
jones@cs.uiowa.edu
Article: 19594MK Yap wrote: > 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? There are three options, two of which have already been mentioned (instantiate LPM library components, and their macro generator). But there is a third choice... The Free-IP Project has the Free-RAM core (http://www.free-ip.com). This core is a portable RAM library for use with Altera and Xilinx FPGA's as well as simulators such as ModelSIM. The way Altera did RAM in Max II+, it is fairly easy to use. Using the Free-RAM core is about as easy. The difference is that the Free-RAM core is portable and gives you many more options when finalizing your design since you can then easily try your design in different FPGA's without significant work. Hope that helps! David Kessner davidk@free-ip.comArticle: 19595
In article <RB5b4.1138$B9.1418518@feed.centuryinter.net>, Larry Edington <larryeSpam.Me.Not@centuryinter.net> writes >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? > One option that does not appear to have been suggested is to prototype using Altera chips and then go to Clear Logic's identical laser programmed parts for production. Best check which Altera parts Clear Logic support, though. -- Steve DeweyArticle: 19596
In article <r34a4.968$B9.1198772@feed.centuryinter.net>, Larry Edington <larryeSpam.Me.Not@centuryinter.net> writes >Would anyone know of a VGA controller I could license for a FPGA? Nothing >fancy needed. In fact, >640 x 480 would be fine. DAC of course would be external. Hoping to use >Altera Flex. > >thanks, >Larry E. > > > If I Recall Correctly, There is a VGA timing generator in AHDL at www.freecore.com. Might get you started. -- Steve DeweyArticle: 19597
In article <3870B679.D84288FD@ids.net>, Ray Andraka <randraka@ids.net> writes: > The problem with putting an OTP key in the device, is that the non-volatile > cells can't be fabricated without additional process steps. The FPGA > process is essentially the same as DRAM, which lets it be done with bleeding > edge process. Put PROM cells on there, and you lose the speed. I'm not a silicon guru. This case is different from a normal PROM in that we don't need a lot of bits. Is there any fabrication method that can build non-volatile storage without sacrificing speed/cost for the rest of the chip if I don't care much about how much space each bit takes up? I think a write-once corner would be good enough. -- These are my opinions, not necessarily my employers.Article: 19598
On Mon, 03 Jan 2000 15:18:47 GMT, eml@riverside-machines.com.NOSPAM wrote: >56-bit keys aren't much use these days. if you have secure >information, you should probably be encrypting with 1000-bit keys, >which should give security for the next few years. A 512-bit key was >recently cracked (RSA-155) - IIRC, this took about 35 CPU years, >including time on a cray, but this will probably become commonplace >over the next couple of years. Depends on the encryption algorithm used. RSA relies on factoring prime numbers and so is nowhere near so secure for the same key length. It's also "quite" laborious in hardware or software because of the modulo arithmetic. Your configuration time would be rather extended, to say the least. You could safely use a symmetrical key cryptosystem as programming the "key" into the FPGA is a secure transmission in the factory. Hence no need for public-key crypto. A 56-bit key in DES would be quite strong, and while a 56-bit DES key has been recovered in around 2 hours, you have to remember that that was a "known plain text" attack (as the RSA ones have been as well, AFAIK). While the headers of a bit-stream would be in the clear (no valuable info), the actual encrypted payload of programming bits would not be known ASCII text or regular known patterns particularly, and therefore would not be prone to more common crypto attempts such as known header or dictionary attacks. I wouldn't use ECB mode of DES though as it leaves plain-text repeat-patterns visible (just in case the bitstream is filled with a long string of zero's or 1's which they may well be). I suspect that some of the reasons the vendors have not put crypto into FPGA's are (in no particular order): 1 - Performance and cost due to additional mask layers on the process 2 - Government restrictions regarding crypto import/export 3 - Lack of "real" user interest i.e. people who will actually "Pay" for the feature in a standard product. 4 - Lack of alternative product. i.e. none of the big 3 offer reprogrammable, secure devices using encryption. If one did, I suspect all would. >i don't think putting encryption hardware on the silicon is necessary. >at the minimum, all the silicon needs is 1024 bits of 'secure' OTP >memory, and some mechanism to drive the configuration process from an >existing configuration (ie. divide the chip into 2 separate >configuration areas, and drive the JTAG chain internally). you could >then load your uncoded decryption engine from PROM, and use your >unique OTP'd key to decode the rest of the bitstream, and program the >remainder of the device. hmmm, sounds damn messy to me, and brings this nasty partial configuration stuff into the equation. In an ideal world, a vendor would offer a core with triple-DES crypto by default where the delivered (unprogrammed) state was a key of all-zero. Devices would be OTP (with no key recovery of course) and the bit-stream generator would have a tick-box and key value selector for the user to generate an encrypted bitstream to throw into the regular configuration mechanism. Sounds like a feasible idea doesn't it? Cheers Stuart For Email remove "NOSPAM" from the addressArticle: 19599
Ray, Your right about the added mask & process steps. However, they do not represent a serious cost issue. CMOS masks are $1-2k per layer for >0.5um, and several times that for <0.5um. Worst case thats $15-30k as part of the large custom cmos chip that implements the FPGA device. I was thinking of an added 56bit onchip eeprom for the DES key as part of the FPGA device. This leaves the SRAM CMOS device as is. Many <0.5um processes offer an eeprom or eprom option. It bumps the total chip cost about 10%. John Cain, Power Processing, Inc., Phoenix, AZ jjcain@goodnet.com >Ray Andraka wrote in message <3870B679.D84288FD@ids.net>... >The problem with putting an OTP key in the device, is that the non-volatile >cells can't be fabricated without additional process steps. The FPGA >process is essentially the same as DRAM, which lets it be done with bleeding >edge process. Put PROM cells on there, and you lose the speed. >-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
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