Hey!
I am currently working on a project of using the XS1-L1-48tqfp for high definition USB audio conversion to I2S.
I was wondering if someone could indicate the pros and cons of using the on-chip programmable memory instead of adding the SPI flash peripheral.
Thanks!!
Choosing between OTP memory and SPI flash memory
OTP is a one-shot deal whereas external flash gives you some flexibility post release ( i.e. firmware updates ). On the other hand, if you're worried about protecting your IP, OTP would be a better choice as long as the critical code fits in 8k.
Another issue you may have to think about is how to program the OTP's in quantity as there currently isn't a good solution out there other than rolling your own...
-Y
Another issue you may have to think about is how to program the OTP's in quantity as there currently isn't a good solution out there other than rolling your own...
-Y
-
octal
- XCore Addict
- Posts: 228
- Joined: Thu Jan 27, 2011 3:30 pm
- Location: Argenteuil - France
- Contact:
@yzoer
protecting IP can also be done via the SPI flash. You can (in the project) setup the encryption/decryption key for your firmware. This decrypt key can be flashed into OTP, and each time you build your firmware, it will be automatically encrypted by the key you provided. This way, when the XMOS reads the firmware from SPI, it decrypts it on the fly and runs it from internal memory.
I think this is the best option for IP protection, as it let you upgrade or refash your firmware in a secure manner. Uless you want to reduce the BOM (an SPI EEprom chip economy), and you are absolutely sure of your firmware, I can't see why you should use OTP for full firmware.
protecting IP can also be done via the SPI flash. You can (in the project) setup the encryption/decryption key for your firmware. This decrypt key can be flashed into OTP, and each time you build your firmware, it will be automatically encrypted by the key you provided. This way, when the XMOS reads the firmware from SPI, it decrypts it on the fly and runs it from internal memory.
I think this is the best option for IP protection, as it let you upgrade or refash your firmware in a secure manner. Uless you want to reduce the BOM (an SPI EEprom chip economy), and you are absolutely sure of your firmware, I can't see why you should use OTP for full firmware.
@octal
Just read that you can actually encrypt your SPI data, which is nice :-) I take it I can just burn the binary image using an external (eprom) programmer?
-Yvo
Just read that you can actually encrypt your SPI data, which is nice :-) I take it I can just burn the binary image using an external (eprom) programmer?
-Yvo
I'll answer that last question myself...
Looking at the documentation (RTFM), there are numerous ways to program / reprogram your flash, which is awesome!
Considering you can encrypt data, run upgrades and what not, it looks like flash seems to be the way to go unless you build your own loader that say, boots from a FAT formatted SD card (tempting...) and you want to store that in OTP.
libflash takes up about 3k with just one device enabled, which is a fair chunk of memory. Having said that, an SD-card interface + FAT filesystem will probably take up more...
-Yvo
Looking at the documentation (RTFM), there are numerous ways to program / reprogram your flash, which is awesome!
Considering you can encrypt data, run upgrades and what not, it looks like flash seems to be the way to go unless you build your own loader that say, boots from a FAT formatted SD card (tempting...) and you want to store that in OTP.
libflash takes up about 3k with just one device enabled, which is a fair chunk of memory. Having said that, an SD-card interface + FAT filesystem will probably take up more...
-Yvo