Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,034 Views

Query FPGA device ID from Linux

We have a board that accepts both an Cyclone V SX or ST part, and also one with more or less logic. Given device availability varies considerably, we have some boards built with one part and some with another. Before getting it to update it's own firmware, we would therefore need to know what FPGA part is on the board, so that it can get the correct flavour build for that board. Is there any way within Linux to query the FPGA ID code or similar? I've had a look through the FPGA Manager but none of the registers suggest they report the device ID. Does the HPS have access to the JTAG port, and if so, is there a Linux driver to access it to run a simple IDCODE query? 

 

Cheers, 

Simon
0 Kudos
4 Replies
Altera_Forum
Honored Contributor I
128 Views

I think you're looking for the Scan Manager ? 

 

 

--- Quote Start ---  

 

The scan manager is used to configure and manage the HPS I/O pins, and communicate with the FPGA JTAG test access port (TAP) controller. The scan manager drives the HPS I/O scan chains to configure the I/O bank properties before the pins are used by the peripherals in HPS. The scan manager can also optionally communicate with the FPGA JTAG TAP controller to send commands for purposes such as managing cyclic redundancy check (CRC) errors detected by the FPGA control block. When the scan manager communicates with the FPGA JTAG TAP controller, input on the FPGA JTAG pins is ignored. 

 

--- Quote End ---  

Altera_Forum
Honored Contributor I
128 Views

If the device (SX vs ST) have the same logic density, then their IDCODE will be the same: 

https://documentation.altera.com/#/00005773-AA$NT00080225 

 

Now if the density is different, when you use FPGA manager to program the FPGA image, you can code in such a way that the FPGA manager returns error to the program if the attempt to program the FPGA is unsuccessful (which is the case when you program a part with mismatch image). Presumably then you can load the second image which is correct for the aforementioned device. I know this is not pretty... but could be something :)
Altera_Forum
Honored Contributor I
128 Views

 

--- Quote Start ---  

If the device (SX vs ST) have the same logic density, then their IDCODE will be the same: 

https://documentation.altera.com/#/00005773-AA$NT00080225 

 

Now if the density is different, when you use FPGA manager to program the FPGA image, you can code in such a way that the FPGA manager returns error to the program if the attempt to program the FPGA is unsuccessful (which is the case when you program a part with mismatch image). Presumably then you can load the second image which is correct for the aforementioned device. I know this is not pretty... but could be something :) 

--- Quote End ---  

 

 

Thank you. I had feared something like this because when I use "auto detect" for devices using Quartus Programmer it gives me an option for which device to use. That's just plain silly that Altera can't put different device IDs in each chip. 

 

Or is the implication that a build for the ST D5 would run on the SX C5? 

 

Final question - is there a Linux driver to run the Scan Manager? Or am I going to have to write some code myself if I use this method? The other option is to embed the device type in my FPGA build, so that the ARM can query my register. At least I can then make the builds have a unique code for each different chip!
Altera_Forum
Honored Contributor I
128 Views

Since SX has slower xcvrs, my guess is that the transceiver portion will/may not work when you program it with the ST image.... 

 

If unique code for each chip is your choice, perhaps you can consider this: 

https://www.altera.com/en_us/pdfs/literature/ug/altchipid.pdf 

 

But it will be really hard to maintain.... 

 

I don't think there is any Linux driver for scan manager... you can try to look in the uboot code but I doubt there is anything useful from there. Reason being, once the HPS I/Os are set up during the initial booting, there is no reason to go back and change them anymore.
Reply