Simple issue of Production Serialization

[Altera_Forum]

Hello, 

 I am new to FPGAs, my background is microcontrollers. This seems like it should be an easy question, but I can't seem to find any information on it.  What is the best way to serialize an FPGA for high volume production?  With microcontrollers, I would, at the time of programming, have the program house write a unique 4-byte number either to flash program memory space or to EEPROM and on boot-up, I would read this register and respond to communication messages with this unique 4-byte ID. I would think for an FPGA , one would do the same thing by writing to a location in the ROM used to house the FPGA program and at boot-up, the FPGA would read that memory location and use that value as a unique ID. However, I was just told by a commonly used programming house that they have NEVER had a request to have an FPGA ROM serialized. I'm still trying to get an answer from them, but I'm hoping someone here could point me in the right direction.  So again, what is the best way to serialize an FPGA for high volume production?  Thanks in advance.

[Altera_Forum]

The terminology you are using doesn't make sense here. "Serialization of FPGAs" could mean a lot of things. I think what you are trying to do is attach a unique ID of some kind to each FPGA or each board.  

 Presumably you've got some flash part that you are using to store the FPGA image that is loaded on bootup. Could you not just write a value into that flash. You could also add an eeprom to the board which you program with the unique ID during production which can then be read by the FPGA.  In several of our products we have to store a MAC address on the board. I typically write a little program that the production house uses which programs the MAC address into the board and increments it for the next board. The mechanisms I use to program the MAC address vary but basically I download a little test program into the FPGA which allows me to send the data to the FPGA either via JTAG or some other path.  Jake

[Altera_Forum]

--- Quote Start ---  Presumably you've got some flash part that you are using to store the FPGA image that is loaded on bootup. Could you not just write a value into that flash. You could also add an eeprom to the board which you program with the unique ID during production which can then be read by the FPGA.  --- Quote End ---  Thanks for the reply. The above is what I was attempting to describe in my previous email, but the programming house (major national company) said they've NEVER done this (but supposedly can), which spawned my question.  Is "JTAG or some other path" more typical for programming FPGAs in high volume production (I use JTAG for programming development stuff)? It seems that this is cumbersome and time consuming since it requires making a physical connection to a board. If you can program a batch of flash devices and then solder them onto the boards, it seems you can skip this whole JTAG etc. step. Am I wrong on this statement?  Finally, for your MAC example, is the test program part of the main program or loaded in addition to the main program?   Sorry for being so dense. I'm just trying to wrap my head around the whole process.

[Altera_Forum]

Unfortunately, you didn't mention the involved configuaration method and device. I suppose that there are options to insert a serial number to the configuration bitsream, e.g. in the Usercode field, but it must be also readable from the FPGA logic at runtime.  

 In case of AS configuration, you can e.g. store the SN in an unused block and read the AS memory from your code.

[Altera_Forum]

FvM, thanks for the reply. Sorry about the lack of info. The device is a Cyclone III and I'm not sure how to respond to the configuration method. In current development, we're using a .jic file programmed through a USB Blaster JTAG programmer using Quartis II as the application interface. There is also the option of using a .pof file if necessary.  

 So, I'm two for two on solutions that require a physical connection to the FPGA (If I understand you and jakobjones correctly). Isn't there a typical or best way of serializing FPGAs that don't require a physical connection? Do companies that produce 10k+ products a month program their devices through a physical connection? This seems tedious and error prone.

[Altera_Forum]

I'm guessing you are using active serial configuration. Well you need to answer the question of where you want to store the unique information on the board? If all you have is the configuration flash of the device then I suppose that's where it'll have to be. Now I can conceive of two options. 

 1 - Program the unique ID into the flash during manufacturing using JTAG. I know this is what you are trying to avoid. This is what we typically do for most designs now. However, our quantities are not really large and every one of our products has to go through a full test anyway at the assembly house. Adding the programming to the list of tests is a minor inconvenience.  2 - The AS device is truly just an SPI flash device. It can be programmed just like any serial flash device. So I suppose if you were truly doing massive quantities, you could arrange to have the values programmed into the flash devices before they are soldered onto the board. We have one product where the assembly house programs eeproms with MAC addresses before soldering them onto the board.  At some point you need a physical connection to the device you are trying to program.  Jake

[Altera_Forum]

Because FPGA don't have non-volatile memory to store a SN, it has to be stored in the configuration memory or another suitable location. I didn't yet understand where you want to store the information.

[Altera_Forum]

Thanks again. Having an external device that's programmed separately makes sense and I see your point about programming during testing is a minor issue. However, is it true that you need to make a physical connection? To FvM's point (thanks as well) I was thinking maybe the configuration memory would be programmed and serialized off board where a specific location of the config mem contained the unique serial number and would be read upon boot-up by the FPGA. I'm at a disadvantage because I don't know what data format is stored in the config memory and how the FPGA reads it out, so I don't know how easy it is to manipulate it or if it's even possible or if "the industry" frowns upon this approach. 

 FvM, I don't really care specifically where the information is stored. As you point out, the preferred location would probably be in the configuration memory since that already exists and then I wouldn't need another device.  I'm not necessarily looking for a specific solution to my specific problem. I'm mainly trying to get an ideal for what people commonly do in this situation since I'm very green on this subject. It sounds like Jake may have a point where the board is most likely going to be ICT and/or functionally tested and so just program/serialize it at that time via a connection. I can also look into getting the configuration memory programmed and serialized off board, but that's actually where I started and I just seem to get blank stares when I talk about this. I guess that's not actually common to do.  Thanks for the feedback.  Alex

[Altera_Forum]

As Jake said, the configuration memory used for AS (active serial) configuration of the FPGA is just a fairly standard SPI flash IC. In fact, it is even possible to use non Altera SPI flash for this purpose. 

 The FPGA will load it's configurtion starting from the begining of the flash. You can store whatever you want, including serial numbers, towards the end of the flash. Once the FPGA is configured, you can access the flash via the SPI interface.  The programming house does not necessarily even need to know that you are using an FGPA. Just give them the image for the SPI flash memory and tell them a location to program the serial number.

[Altera_Forum]

Thanks. This is what I've done in the past with microcontrollers and it seems to be the most efficient. I was told this has never been done, but it must have been bad information. Thanks for all the help.