some infos from Antti about ID system
Mr. Edmund Humenberger
1) the ID is absolutely part of the ecosystem, and one of the uses would
be that "gateway" or local processing FPGA bitstreams are either
selected from pre-compiled pool, or generated on the fly either locally
or in the cloud
the ID system may have to be hierarchical -
FPGA ID for the primary boot partition if multiboot capable FPGA
ID for the FPGA application image that is currently loaded
lots of work, for later, but initially only some board-id part is
relevant as it "hardened" while the rest is kinda soft..
so the concept so far:
1) all modules with the high speed connector fitted are pretty much forced to include ID EEPROM, also the I2C bus on the HS connector is really pretty much mandatory as well.
2) all modules with Low speed connectors SHOULD also always when possible include the ID EEPROM, but here it is is a bit more relaxed, some ad-on as example could may have 8 LED's only and eeprom..would be not needed
current concept for LS module, use EEPROM in small package:
this package has 2 address pins (A2=GND), address for ID EEPROM should be set then 011 - it would be I2C addres 0x53 (or 0xA6 depend on shift)
this eeprom has unique ID (MAC ID) this may already be used to identify the module, there is small portion of EEPROM writeable, should be enough to write the minimal meta data
(TOFE.IO has similar option for small eeprom)
This is SPI Flash adapter for 6x8 mm BGA packages, SOT23-6 EEPROM with ID is added. While on this like adapter the EEPROM may not see as needed, if it has say CORRECT SPI flash device name in it, and maybe link to vendor datasheet, it would be nice benefit.
* I2C addresses scan order?
* meta-data itself - not first priority as it does not change the hardware design
there may be a need to recognize the mdoules by SHORT ID, one example would be where Lattice XO2 has the hardened I2C on the "ID I2C" bus - in that case we can read the TRACE ID (what can be set to identify the board) but we can not add the meta data into XO2, so question is if the additional EEPROM in parallel is mandatory in that case.. ok its corner case
HS modules - PCB space should in most case be more available so larger EEPROM can be use to store lots of meta-data?
I can imagine a computer BIOS-like management tool for reading/writing the ID-s as well as for performing some rudimentary testing should the meta-data contain a HW description.