Post by thread:[EE]: FPGA external program memory

Hi, On the subject of stealing your program it seems to me that it will be as easy/difficult with either method. On why to use it i guess is to do with the manufacturing processes, the fpga is ram based device and to add the flash to store the program is probably space consuming( chip wise) for something that will be used very infrequently to load the program. Not that Altera also have CPLDs that are flash based devices and do not need a config device. Best regards Luis On Jun 10, 2012 7:50 PM, "Andre Abelian" <spam_OUTabelian.andreTakeThisOuTyahoo.com> wrote: {Quote hidden}> Hi all, > > I noticed that altera uses external ic to hold the program memory is there > any advantage? > why use external some one can still the code. how come xilinx or lattice > program memory is internal. > > > any idea? > > thanks > > Andre >

On Sun, Jun 10, 2012 at 2:46 PM, Andre Abelian <.....abelian.andreKILLspam@spam@yahoo.com>wrote: > Hi all, > > I noticed that altera uses external ic to hold the program memory is there > any advantage? > why use external some one can still the code. how come xilinx or lattice > program memory is internal. > > > any idea? > Trying hard to ignore the inconsistently poor grammar. I'm pretty sure that most Xilinx FPGAs use external memory to load their configuration, as is with Altera FPGAs. The CPLDs, however, have on-chip flash. In terms of other people downloading your code, if they wanted to do that, they would find a way regardless of where it is stored. I think your best bet for protection is some kind of encryption

On 6/10/2012 9:01 PM, V G wrote: > In terms of other people downloading your code, if they wanted to do > that, they would find a way regardless of where it is stored. I think > your best bet for protection is some kind of encryption. Some of the FPGA have security features, like the one I am using that loads its code from sdcards. The FPGA has an internal module that handles all encryption/decryption and the user only has to set the key one time, the key is stored internally in the FPGA and is not retrievable, lose your key and you can never use the chip again. Mark

On Jun 10, 2012, at 6:35 PM, Mark Hanchey wrote: > Some of the FPGA have security features It was FPGA security features recently that were recently cracked, BTW. Basically, it seems that certain features were protected by locking them under a key (AES128 - nothing to sneeze at.) While this potentially means that the manufacturer had a back door to the commands, the big problem turned out to be that keys were "pretty easy" to extract from the chip via "side-channel attacks." http://erratasec.blogspot.com/2012/05/bogus-story-no-chinese-backdoor-in.html BillW

On 6/11/2012 2:23 AM, William "Chops" Westfield wrote: > It was FPGA security features recently that were recently cracked, > BTW. Basically, it seems that certain features were protected by > locking them under a key (AES128 - nothing to sneeze at.) While this > potentially means that the manufacturer had a back door to the > commands, the big problem turned out to be that keys were "pretty > easy" to extract from the chip via "side-channel attacks." http://erratasec.blogspot.com/2012/05/bogus-story-no-chinese-backdoor-in.html BillW http://www.altera.com/devices/fpga/cyclone3/overview/security/cy3-security.html It was a bad design to start with to allow programming accessible via jtag. That is why I like chips like the Cyclone III LS , the security part of the chip isn't accessible via jtag at all, it is constantly monitoring the traffic of the jtag bus and at the first sign of tampering it can be set to zero the device so that it gets really expensive to keep trying to hack the protection. Mark

Mark, good info.. thanks AA ________________________________ From: Mark Hanchey <markKILLspampixeltrickery.com> To: .....piclistKILLspam.....mit.edu Sent: Monday, June 11, 2012 4:45 AM Subject: Re: [EE]: FPGA external program memory On 6/11/2012 2:23 AM, William "Chops" Westfield wrote: > It was FPGA security features recently that were recently cracked, > BTW. Basically, it seems that certain features were protected by > locking them under a key (AES128 - nothing to sneeze at.) While this > potentially means that the manufacturer had a back door to the > commands, the big problem turned out to be that keys were "pretty > easy" to extract from the chip via "side-channel attacks." http://erratasec.blogspot.com/2012/05/bogus-story-no-chinese-backdoor-in.html BillW http://www.altera.com/devices/fpga/cyclone3/overview/security/cy3-security.html It was a bad design to start with to allow programming accessible via jtag. That is why I like chips like the Cyclone III LS , the security part of the chip isn't accessible via jtag at all, it is constantly monitoring the traffic of the jtag bus and at the first sign of tampering it can be set to zero the device so that it gets really expensive to keep trying to hack the protection. Mark

On Sun, 10 Jun 2012 11:46:24 -0700 (PDT), Andre Abelian wrote: > ... > > I noticed that altera uses external ic to hold the program memory is > there any advantage? > ?why use external some one can still the code. ?how come xilinx or > lattice program memory is internal. > > ... Most FPGAs load their bitstream from an external source (ie. non-volatile memory, JTAG controller, a microcontroller, etc.) as they lose configuration when power drops below a given threshold (ie. turned off). Out of these options, it tends to be Flash based memory for lower cost devices, since they're cheap (ie. about 60p in singles for a W25Q16CV 16Mbit SPI device) - SD cards also tend to be incompatible, too (although I dare say there are devices out there capable of loading directly off them). For example, the Xilinx Spartan 6 initial clock rate for configuration is about 1MHz, higher than the SD card interface's initial (pre-negotiation) 400kHz clock requirement. There are some technologies (eFuse I believe Xilinx call it) that allow you to stick the bitstream internal to the device, but these tend to be higher-end devices. These same devices also tend to have battery backups to store AES keys and encrypted bitstreams, too. That handles the IP theft to an extent - all (encrypted) IP is inside the device, and the AES key / decrypted bitstream is non-readable by any of the loaded firmware. As for the technical (or historical ?) reasons behind FPGA volatility vs. CPLD non-volatility, I have no idea - that would be enlightening if somebody in the know could comment on it. Hope this helps. Regards, Pete Restal

On Jun 11, 2012 12:50 PM, "Pete Restall" <EraseMEpetespam_OUTTakeThisOuTrestall.net> wrote: > > > > As for the technical (or historical ?) reasons behind FPGA volatility > vs. CPLD non-volatility, I have no idea - that would be enlightening if > somebody in the know could comment on it. > > Hope this helps. > > Regards, > > Pete Restall > -- > Pete, they're RAM based devices last I checked, which would explain the volatility and inability to put flash on the same chip inexpensively

>> As for the technical (or historical ?) reasons behind FPGA volatility >> vs. CPLD non-volatility, I have no idea - that would be enlightening if >> somebody in the know could comment on it. >> >> Hope this helps. >> >> Regards, >> >> Pete Restall >> -- >> > > Pete, they're RAM based devices last I checked, which would explain the > volatility and inability to put flash on the same chip inexpensively. I have often heard this. If it is difficult to mix RAM and Flash on the same chip how does Microchip do it? -- Bob Ammerman RAm Systems

Em 12/6/2012 10:18, Bob Ammerman escreveu: >>> As for the technical (or historical ?) reasons behind FPGA volatility >>> vs. CPLD non-volatility, I have no idea - that would be enlightening if >>> somebody in the know could comment on it. >>> >>> Hope this helps. >>> >>> Regards, >>> >>> Pete Restall >>> -- >>> >> Pete, they're RAM based devices last I checked, which would explain the >> volatility and inability to put flash on the same chip inexpensively. > I have often heard this. If it is difficult to mix RAM and Flash on the same > chip how does Microchip do it? > > -- Bob Ammerman > RAm Systems Atmel, Freescale, Texas, etc. also. Years ago, it was difficult to mix analog with digital, bipolar with CMOS, RAM with FLASH, etc with etc. Nowadays, the manufacturing processes are much improved. Nearly every manufacturer have MCUs with large RAM and FLASH on the same die. Perhaps they can do better without the mixing, but it is economically feasible now. Isaac

On Sun, 2012-06-10 at 21:01 -0400, V G wrote: > I'm pretty sure that most Xilinx FPGAs use external memory to load their > configuration, as is with Altera FPGAs. The CPLDs, however, have on-chip > flash. True, there are other FPGA manus that do flash for PGM memory. > In terms of other people downloading your code, if they wanted to do that, > they would find a way regardless of where it is stored. I think your best > bet for protection is some kind of encryption. This unfortunately doesn't make sense. The FPGA bit stream is very specific to the FPGA in question. You can't just encrypt it yourself any qay you want, otherwise the FPGA reading those bits won't understand a bloody thing. You COULD find a way to perhaps encrypt say static data, put it in an EEPROM and them have the FPGA decrypt it, but that wouldn't be that much harder to crack for someone really good if the regular bitstream is in the clear. The good news however is bitstream encryption is a pretty standard feature in most FPGA families. A quick google for the FPGA the op is interested in will tell them whether or not it's an option for them. TTYL