This is for a Spartan-6, but I would think it might apply for all parts.
I know if you accidentally try to load the bitstream for the wrong device it will be detected and fail.
We are changing a board to using the same part (same die), but in a different package. What would happen if someone accidentally loaded the bitstream for the old package into the part on the new board? Would it allow the bitstream from the other package to be loaded into the new package and possibly cause damage?
There shouldn't be any way to damage it. Bitstreams contain a device IDCODE, and devices will refuse to configure themselves with a bitstream for a different device.
> There shouldn't be any way to damage it. Bitstreams contain a device IDCODE, and devices will refuse to configure themselves with a bitstream for a different device.
In this case I was thinking it's probably the same FPGA die in a different package. Is there any type of protection against accidently loading the bitstream for an Spartan-6 LX45 CSG324 package device into a LX45 in a CSG484 package?
This isn't really different than the case when you have different boards using the same part
in the same package. You need to control the code you load into the board. If this is something
that gets re-programmed in the field, you should probably have some sort of board ID that
prevents the update software from loading the wrong file.
If it's the same die it will have the same ID code, regardless of how that die is packaged. UG380 table 5-13 shows the ID code for each member of the S6 family - and it does not depend on package, only on die.
Your concern is well founded, a bitstream designed for a specific die and package combo will almost certainly wreak havoc when applied to the same die but in a different package.
The simplest solution is to carefully and clearly label each bitstream with the device and package that it is for, and provide clear warnings that applying an incorrect bitstream could result in damage to the device.
If you absolutely require a foolproof system then you could consider a multiple configuration boot, where the first configuration uses almost zero IOs, just enough to somehow identify what package it is living in and then use that information to load the appropriate package specific configuration. This approach would require careful analysis of which die IO sites map to which package balls, for each package of interest.
Silicon On Inspiration
$49 Spartan 6 board with 32MB DDR DRAM ?