Testing on unprogrammed blank FPGAs?

--- Quote Start ---

I dont quite understand why you would? FPGAs are volatile so lose their configuration when you power them off. They need to be configured at power on.

--- Quote End ---

"I wanna check for the default I/O values of an unprogrammed device irrespective of the memory type"

--- Quote Start ---

as a non-destructive testing, if we want to analyse the un-programmed blank devices for their default output values and also to verify their electrical characteristics as per the data sheet, do any of altera's commercial fpga boards support such facilities??? do altera follow such test practices on any fpgas/ socs to ensure against hardware trojan attacks??

--- Quote End ---

Unprogrammed FPGAs will have their general purpose I/Os all set as tristate outputs, and in the 'off' state. A very weak pullup to VCCIO is generally enabled to keep the input from floating and drawing any significant current. Basically all the FPGA general purpose I/Os will look like inputs. This behavior is specifically present to allow for 'hot plugging' of devices where they are plugged into an active, powered circuit, configured, and then begin operation.

Other dedicated output signals (like configuration done, etc) will be in the states that represent an unconfigured device. Most of these are open drain and require external pullups to function.

Most commercial development boards will bring many pins to uncommitted connectors, so you can observer the behavior on these pins.

As to 'test practices to ensure against trojan attacks' not sure what you mean by this, you will need to explain. As indicated earlier most FPGAs are volatile so will lose all their programming on a power cycle. Some CPLDs (like MAX series) have internal flash that survives power cycling, but it can be reprogrammed at will. There is no place for a trojan to hide ...

--- Quote Start ---

A hardware trojan can be implemented by the ASIC designer team of each part. In this case, you cannot verify whether there is a hardware trojan inside your FPGA or not. You could have verified this if you had designed the FPGA (instead of Altera). A hardware trojan may not need any external device for any thing.

--- Quote End ---

Well, if one is that paranoid then the only solution is to design the part yourself from the transistor level up using your own libraries. Then generate the masks in your own facility, fabricate the parts in your own fab, and package the parts yourself.

Oh and of course you will have to write all your own place and route tools as well for your custom FPGA design, as you can't trust a vendor to not insert some malicious bits into the programming bitstream.

--- Quote Start ---

Yes, but there are some methods to GUESS if your fabricated device has something inside that is not yours. There are also some methods to prevent another team (the fabrication foundry team for instance) from changing or adding something new to your design. This is a field of research. Different approaches may use delay, temperature, power, parasitics, etc to detect a trojan. Nonetheless these methods can be applied if YOU have designed (even with third party tools) your chip.

--- Quote End ---

But here, Altera design the chip, and the bad guy with the trojan would have no way of knowing the intended board layout or design so a trojan would be rather useless. It would be spotted rather quickly as chips are used by 100s of different customers on 100s of different boards all with different pinouts.