JTAG-SMT3-NC fail FPGA eFUSE programming

[sgk]

In beginning of 2021 we replaced some of our Xilinx DLC10 programmers with JTAG-SMT3-NC in our production setup.
We have over the past months seen eFUSE programming failures but only in the systems with the JTAG-SMT3-NC programmer.
We only see failures Vitex-7 and with the JTAG-SMT3-NC.
There are no failures doing FPGA image programming nor FPGA DNA read, so we have full confidence the issue is not related to signal integrity.
Failure rate is low, about 1%, but the boards are scrap when the eFUSE programming fail, as it programming some of the bits.
We use Vivado 2018.2 on Linux and we only see the issue with JTAG-SMT3-NC.
Do you have known issues with JTAG-SMT3-NC eFUSE programming on Vitex-7?

[JColvin]

Hi @sgk,

I asked one of our design engineers about this, but they have not heard of any eFUSE failures with the JTAG SMT3 NC, with a Virtex 7 based FPGA or otherwise.

Could you let us know some more details about your setup and how the JTAG SMT3 is integrated? I was informed that this is an issue with the JTAG SMT3 NC correctly eFUSE programming, we'll likely be needing to work with Xilinx to help determine the root cause.

Thanks,
JColvin

[sgk]

Hi
The JTAG SMT3 is on an add-on board in the production jig, we are sure there is no signal integrity issue as we have thoroughly validated the setup and never see other failure than eFUSE programming failures.
The productions setup has programmed thousands of systems without any failures under FPGA image load.
We used several Xilinx FPGA families, but only see issue with the Vitex-7 and JTAG-SMT3-NC combination.
Please notice we never see failures with the Xilinx DLC10 programmer.

[sgk]

It seems like there is a mismatch in your documentation, the documentation for both JTAG-HS2 and JTAG-SMT3-NC state both eFUSE programming is supported and not supported.
Is eFUSE programming supported by both JTAG-HS2 and JTAG-SMT3-NC?

[JColvin]

Hi @sgk,

The design engineer let me know that originally the Digilent JTAG programmers (HS2, SMT3, etc.) were not able to do Xilinx eFUSE programming, but then Xilinx did some work on their end (no hardware changes on Digilent's end as far as I understand) to make it such that the programmers are able to do eFUSE programming.

The design engineer reached out a Xilinx contact to see what their thoughts on what you're describing; I'll let you know what I learn.

Thanks,
JColvin

[malexander]

@sgk

Can you tell me the full part number for the Virtex 7 device that you are targeting?

Thanks,
Michael

[sgk]

We see the issue with Virtex-7 P/N XC7VX330T.

[malexander]

@sgkXilinx is investigating this. Can you please tell me approximately how many units passed and how many failed programming?

Thanks,
Michael

[sgk]

I can’t share exact production data, but we have used the JTAG-SMT3-NC on more than thousand systems this year in production.

Edited August 12, 2021 by sgk

[sgk]

What is the status on this issue and are there any news?

[malexander]

@sgk

It's being investigated by Xilinx but there's no update.

[sgk]

Is it possible to downgrade the firmware in Digilent SMT3 to something similar to a Xilinx DLC10 programmer?

Do you have multiple firmware versions for the Digilent SMT3 probe and how can I see the  firmware version?

[malexander]

@sgk

No, the SMT3 and DLC10 use different USB controllers and run completely different pieces of software so it's not possible to downgrade or upgrade to the DLC10 firmware.

The firmware images are included alongside the Vivado installation. You can check to see which version you have by searching the Vivado installation directory for "FTDIFW_57*":

find /opt/Xilinx/Vivado/2019.1/data -iname FTDIFW_57*
/opt/Xilinx/Vivado/2019.1/data/xicom/cable_data/digilent/lnx64/firmware/FTDIFW_57_00000001_00000000_010A-64bit.so

The naming scheme is as follows:

FTDIFW_<fwid>_<public_capabilities>_<private_capabilities>_<firmware_version_number>-<architecture>.so

The <firmware_version_number> field is a 16-bit hexadecimal field where the MSB is the major version and the LSB is the minor revision. The build number isn't included in the filename and the minor or major version number is bumped any time a change is made to the firmware's source code. The version number associated with the above example is 1.10, which is the most recent version. We haven't made any changes for several years so any recent version of Vivado should included 1.10

[sgk]

Thanks for the firmware version explanation, our Vivado version 2018.2 has "FTDIFW_57_00000001_00000000_010A-64bit.so" so thereby firmware version 1.10.
Can you please check which firmware version was qualified by Xilinx?
Would it be possible to get at firmware version with additional timing margin under eFuse programming?
If not, it seems like we are forced to shift our productions setup to Xilinx DLC10 programmers as we never see issue with the DLC10 programmer.

 

[sgk]

Do you have any news on which firmware version was qualified by Xilinx?
Are there any options for a firmware version with additional timing margin under eFuse programming?

[malexander]

@sgk

Xilinx is still investigating the issue but the feedback I received is that this should be working with 2018.2 of Vivado. You can try a newer version of Vivado, but I'm unaware of any additional firmware versions or timing margin adjustments for eFuse programming.

 

[sgk]

Is there any news from Xilinx?

[JColvin]

Hello,

malexander is out of office on vacation at the moment, but should be back in the office this coming Monday. I'm not on the email chain, but I have not heard anything in the way of an update.

Thanks,
JColvin

[malexander]

@sgk

I asked for a status update and will let you know when I hear something.

Thanks,
Michael

[malexander]

@sgk

From my contact:

"We did not come up with any reasonable explanation other than there may have been some signal integrity issue  (ex glitch)  that occurred during the efuse programming.  Given that the ramp on the edges of the dlc10 cable are quite slow, we have observed that this cable ends up being more immune to ringing or other signal integrity related issues. So our hypothesis is that there may be some marginal case where their JTAG signals is more sensitive due to board load or other PCB related issues that may make the JTAG signals more sensitive when programming their efueses with the digilent cable. Thought it is hard to say definitively this is the case, one thing they could try is to take a failing board and then scope out the jtag signals when connected with a digilent cable and compare them to what they see with a platform cable."

[sgk]

We know the signal integrity is perfect with the JTAG-SMT3-NC and we have intensively tested the read/write stability on a eFuse failed board, so we know it is not a signal integrity issue and it is too easy just to blame signal integrity.
Do you have a read/write test which we can perform to prove whether there is a signal integrity or not?

[sgk]

To elaborate on the signal integrity performance.
Before each efuse programming, the production script read the FPGA DNA and the eFuse CNTL register to insure stable supply and good connection.
We have not seen any issue with the DNA nor eFuse CNTL register read. We have no issue in the production with the FPGA image load which is substantial larger than the eFuse key.
On a board which failed eFuse program, we have programmed the eFuse CNTL register over 10,000 times without issue.
We will really appreciate if you have a TCL script which perform a read/write test sufficient to determine the signal integrity performance.

[malexander]

@sgk

I think Xilinx's suggestion to scope the JTAG signals is reasonable - it's good to look at the rise and fall times, setup time, hold time, and the AC overshoot/undershoot. That's something I always do as part of the board bring up/validation process.

From a software testing perspective I would do the following with fTCK = 30 MHz:

1. Navigate through test logic reset to Shift-DR (the IDCODE instruction is loaded)

2. Generate N bits of random data, where N is a large number

3. shift N + 32 bits of data

4. compare the first 32 bits against the known IDCODE of the device

5. compare the N bits of received TDO data against the N bits of TDI data that you shifted out

6. repeat the above steps X times, where X is a very large number.

If you want to be even more thorough you could first navigate to shift IR and manually shift in the IDCODE instruction, then navigate to shift-dr and perform the remaining steps.

I don't think there's a public application that does this type of thorough testing... you'd have to write one use the Adept 2 SDK DMGR and DJTG libraries.

 

I don't know how to perform this type of testing through TCL scripts or the Xilinx tools.