Unable to read FPGA Device-ID sometimes

[NikunjTarsariya]

Hi there,

We are using the Intel MAX10 FPGA and are programming the FPGA using the Altera-developed Jam STAPL file format. Although most of the time it works fine, we are facing issues sometimes when power cycle regression testing is performed. In that test, the board is powered ON and OFF multiple times. 

In Jam STAPL, Initially, we are trying to read the FPGA Device-ID which is 0x0318A0DD but we are getting the 0xFFFFFFFF(TDO line of JTAG is driven high). When this issue occurs, retrying doesn't help. Once it is failed for an unknown reason, we have only one option which is to power cycle the FPGA device. This issue is mainly seen with a probability of 0.1%. So, Do you know the reason behind this issue? If so, kindly share it with us.

Your help/suggestion is highly appreciated. Thanks in advance.

Thanks,
Nikunj Tarsariya

[YuanLi_S_Intel]

Just would like to understand that the issue of getting FPGA Device-ID = 0xFFFFFFFF is happening right after restart or after sometime of command sending?

[NikunjTarsariya]

Hi YuanLi_S_Intel,

The issue is happening right after the restart process. A JAM STAPL first try to find out whether the device is connected or not at the same time but we could not get the FPGA device ID. 

Do you have a proper justification for this? Your help would be highly appreciated.

Thanks in advance.

Nikunj.

[YuanLi_S_Intel]

I see. It sounds to me that it is due to issue in the jtagchain. Did you try to calibrate the delay on JAM? You may take a look at document below:

https://www.intel.com/programmable/technical-pdfs/654049.pdf

[NikunjTarsariya]

We have already calibrated delay so we are getting the correct Device-ID value every time except in failure cases. In failure cases, the same code is used but we are facing this issue intermittently over 100's AC cycle.

[YuanLi_S_Intel]

Ok understand. Seems like the issue is happening after 100 AC cycle but not right after restart and the failure rate is about 0.1%. We have not seen this issue in the past and i am not able to duplicate it.

My guess is that it could be the script or any command executed before this causing "dead lock" and thus a power cycle is needed to solve this.

[NikunjTarsariya]

Max 10 FPGA configuration schemes and features chapter from its handbook contains the following. See attached image(cnfg_sequence.jpg) for this. It also states that the nSTATUS pin will be released after the internal reset operation completes. The same chapter also contains one caution note for unsupported JTAG instructions. See attached image(note.jpg) for this.

Previously, we were not monitoring the nSTATUS pin before initiating the configuration process. To monitor this nSTATUS pin, we have also updated our code. So, what we found is we are not getting the nSTATUS pin high in the failure cases.

What would be the possible reason for this nSTATUS pin issue?? If anyone has any information related to this issue, kindly share it.

Thanks in advance.