FAILED to lock JTAG using JTAG primitive on Cyclone V

[edianannink]

Dear FPGA engineers,

We are trying to lock the JTAG using the Cyclone V JTAG primitive using the following guide: https://www.intel.com/content/www/us/en/docs/programmable/683269/current/lock-and-unlock-jtag-instructions.html. The PULSE_NCONFIG opcode and other opcodes are verified and work using the USB Blaster I/II. However, after trying to lock the JTAG using the code provided by Intel and changing the primitive to cyclonev_jtag, the JTAG is not being locked as PULSE_NCONFIG is executed successfully after "locking" the JTAG internally. We simulated the logic before integrating it into our project. We noticed a few interesting things:

1. There is an always block without any sensitivity list which makes it impossible to simulate. Was this code simulated before it was released?
2. The counter is missing in the sensitivity list of the state machine which results in the state machine sticking in one state infinitely as the next state is not triggered when the counter is updated.
3. The code is very dependent on the start_lock and start_unlock signals. We noticed that the start_lock and start_unlock signals must remain high for a certain amount of clock cycles to properly traverse through all the states. The signal must also become low otherwise the state machine will keep corectl high and will not go to the reset state which makes it impossible to use the external JTAG until the signal becomes low.

After fixing the mentioned issues, we successfully simulated the logic and verified that the state machine traverses through the states successfully and conforms with the Altera IEEE 1149.1 JTAG BST specification https://cdrdv2-public.intel.com/654590/an039.pdf. After many failed attempts to lock the JTAG internally, we started debugging using a logic analyzer and we captured the signals from the USB Blaster and the internal tck_core, tdi_core, tms_core, and tdo_core. We noticed two interesting differences:

1. There are 4 extra bits "1111" appended after the 10-bit opcode when sending JTAG commands using the USB Blaster. We assume that this is the POSTIR 4 JTAG JAM command. After adding these four bits to our internal JTAG locking opcode, the JTAG still doesn't lock. We need the POSTIR 4 command instead of PREIR 4 for most JTAG commands otherwise nothing is happening. Why?
2. After matching the internal JTAG core signals EXACTLY with the external JTAG signals, the JTAG still didn't lock. We noticed a difference in the tdo and tdo_core signals (see the provided screenshot). Does this matter? What does this mean?

After debugging and many attempts we are not able to lock/unlock the JTAG internally with the JTAG primitive. We tried sending many JTAG commands internally but none worked while the USB Blaster kept working without any problems. The Cyclone V that we tested on is programmed with a non-volatile key (I assume this doesn't matter but you never know). Are we missing something? Why is our code not working while it is functionally the same as the code provided by Intel and conforms to the JTAG specification? Please help us as we need the JTAG lock/unlock functionality!!

[NurAiman_M_Intel]

Hi,

As this forum post is similar to the IPS case you have created, I will continue to provide support through IPS and close this forum case.

Please refer to the IPS for further support.

Thank you.

Regards,

Aiman