Virtex® Family FPGAs

[cedille1989]

Hi all,
Could you please give us some advice about JTAG configuration?

We are developing a new FPGA board using XC6VHX380T, and have a problem.
In the iMPACT tool, after the configuration gauge reached to 100%, "Configuration Failed" is shown in the Boundary Scan Window, and actually the FPGA is not configured.
We checked the status registers by clicking [Debug] -> [Read Status Register], got the following messages:

[0] VALID_0 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         0
[1] FALLBACK_0 - FALLBACK TRIGGERED RECONFIGURATION                        :         0
[2] IPROG_0 - INTERNAL WARMBOOT (IPROG) TRIGGERED RECONFIGURATION          :         0
[3] WTO_ERROR_0 - WATCHDOG TIME OUT ERROR                                  :         0
[4] ID_ERROR_0 - FPGA DEVICE IDCODE ERROR                                  :         0
[5] CRC_ERROR_0 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                      :         0
[6] WRAP_ERROR_0 - BPI FLASH ADDRESS COUNTER WRAP AROUND ERROR             :         0
[7] HMAC_ERROR_0 - HMAC ERROR                                              :         0
[8] VALID_1 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         0
[9] FALLBACK_1 - FALLBACK TRIGGERED RECONFIGURATION                        :         0
[10] IPROG_1 - INTERNAL WARMBOOT (IPROG) TRIGGERED RECONFIGURATION         :         0
[11] WTO_ERROR_1 - WATCHDOG TIME OUT ERROR                                 :         0
[12] ID_ERROR_1 - FPGA DEVICE IDCODE ERROR                                 :         0
[13] CRC_ERROR_1 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                     :         0
[14] WRAP_ERROR_1 - BPI FLASH ADDRESS COUNTER WRAP AROUND ERROR            :         0
[15] HMAC_ERROR_1 - HMAC ERROR                                             :         0
'1': Reading status register contents...
[0] CRC ERROR                                                              :         0
[1] DECRYPTOR ERROR                                                        :         0
[2] PLL LOCK STATUS                                                        :         1
[3] DCI MATCH STATUS                                                       :         1
[4] END OF STARTUP (EOS) STATUS                                            :         0
[5] GTS_CFG_B STATUS                                                       :         0
[6] GWE STATUS                                                             :         0
[7] GHIGH STATUS                                                           :         1
[8] MODE PIN M[0]                                                          :         1
[9] MODE PIN M[1]                                                          :         0
[10] MODE PIN M[2]                                                         :         1
[11] INIT_B INTERNAL SIGNAL STATUS                                         :         1
[12] INIT_B PIN                                                            :         0
[13] DONE INTERNAL SIGNAL STATUS                                           :         0
[14] DONE PIN                                                              :         0
[15] IDCODE ERROR                                                          :         0
[16] SECURITY ERROR                                                        :         0
[17] SYSTEM MONITOR OVER-TEMP ALARM STATUS                                 :         0
[18] CFG STARTUP STATE MACHINE PHASE                                       :         0
[19] CFG STARTUP STATE MACHINE PHASE                                       :         0
[20] CFG STARTUP STATE MACHINE PHASE                                       :         0
[21] RESERVED                                                              :         0
[22] SPI FLASH SELECT PIN FS[0]                                            :         1
[23] SPI FLASH SELECT PIN FS[1]                                            :         1
[24] SPI FLASH SELECT PIN FS[2]                                            :         1
[25] CFG BUS WIDTH DETECTION                                               :         0
[26] CFG BUS WIDTH DETECTION                                               :         0
[27] RESERVED                                                              :         0
[28] HSWAPEN PIN                                                           :         0
[29] BAD PACKET ERROR                                                      :         1
[30] RESERVED                                                              :         0
[31] EFUSE BUSY STATUS                                                     :         0

First, we suspected the JTAG line, but JTAG integrity check has been passed.
Also, the phenomenon was not changed under TCK = 0.75MHz, which is lowest frequency in impact tool.

We then suspected the power line, because bit [18]-[20] indicates that the configuration state is not progressed from the step 1, which can be passed when the powers are correctly supplied (datasheet ug360, p92 - p93).
We measured the voltage of Vccint (1.0V) and Vccaux = Vcco_0 (2.5V), only to find both of them are in the range of the recommended condition.
Also, in the configuration window, voltages are shown before the configuration, which have no problem.

The third hypothesis is that as soon as the FPGA is successfully configured it then restarts.
Because of a miss of the board design, a part of the I/O power supply drop to 0.65V, which is not supported in Virtex-6.
We considered this causes the FPGA restart.

Our question is whether the configuration fails when the I/O power is incorrect.
If not, there must be another problem, and we need your advice.

Now we are going to re-mount the trim register of the DC-DC converter whose output is inproper.
We want to know other reason (if any) before the re-mount completes.

Thanks.

--
OS: Ubuntu11.10 and WindowsVista(64bit) (We tested in both of them, but the results are the same.)
ISE: Ver13.4
Device: XC6VHX380T-FFG1923

[austin]

INIT =1,

And, there is a packet error.

Just because you change the frequency does not mean that you do not have a signal integrity problem:  you still might have such a problem.

Since INIT_b is high, that implies you did not even get to checking the CRC, so the error must have occurred right away in the very first part of the download of the bitstream.

So, check the signals:  the rising and falling edgews of the clock must be absolutely clean:  no ringing, no glitches, no overshoot, no undershoot.

Data should look just as wonderful.

[eteam00]

Please clarify,

• When configuring FPGA directly from iMPACT, does configuration succeed or fail?
• When configuring FPGA from configuration memory on the board, does (self-)configuration succeed or fail?

Configuration from JTAG and configuration from on-board memory involve different interfaces and separate sets of connections.

Austin wrote:  Data should look just as wonderful [as clock].

Actually, the data line can look quite ratty and horrible, as long as it 'settles' to the correct state when clock edges occur.  Clocks (e.g. CCLK and TCLK), unlike data signals, must have clean edges.  As long as clock edges are 'clean', you should be able to drop the clock frequency low enough to allow (even) ratty data signals enough time to 'settle out' to valid and correct signal levels.

-- Bob Elkind

[cedille1989]

Thank you for your advice.

From impact tool, we tested the "Chain Integrity Test" and "IDCODE looping", and both of them successfully completed.
This is why we concluded the JTAG line is clean, but we checked again the TCK signal with our oscilloscope.

The schematic of the TCK is as follows:
BoxConnector(20 pin) - CDCV304 (fan-out buffer, 2.5V) - FPGA and other devices.

We checked the signal at the output of the fan-out buffer (CDCV304), the result is as shown in the figure.
Is the signal not clean enough?

Thanks.

[cedille1989]

Thank you for your advice.

> When configuring FPGA directly from iMPACT, does configuration succeed or fail?
Yes, it shows "Configuration Failed" after the gauge reached to 100%.

> When configuring FPGA from configuration memory on the board, does (self-)configuration succeed or fail?
We tried to configure PROM (We use Master BPI Mode), but the impact tool halts with unexpected error when the progress bar reached at about 10%.
Thus we can not test the configuration using PROM so far, but this is another problem.

> Clocks (e.g. CCLK and TCLK), unlike data signals, must have clean edges.
The result is as above. How do you think of the signal integrity?

Thanks.

[eteam00]

> Clocks (e.g. CCLK and TCLK), unlike data signals, must have clean edges.
The result is as above. How do you think of the signal integrity?

The scope waveform display is fine for showing signal swing and logic levels, but is not useful for inspection of

signal shape for edges.

You must 'zoom in' on the clock edges, if you wish to verify the signal waveform with an oscilloscope.

Here is an example:

-- Bob Elkind

[gszakacs]

We checked the signal at the output of the fan-out buffer

You need to probe as close as possible to the FPGA pin - perhaps at the breakout via.

Still, IDcode looping should show issues normally if there is a signal integrity problem

unless you happen to have a problem on a line other than TCK, and in that case I would expect

lowering the clock frequency to help.

You might want to check the power supply integrity.  Sometimes an insufficient supply current

or insufficient bypassing can cause this sort of error as the chip will draw more power during

configuration.  IDcode looping does not cause any significant power draw.

-- Gabor

[cedille1989]

Thank you for your advice, and sorry to late my answer.

Again, we see the wave form at the output of the fan-out buffer, and the detail is as below.

Of cause, we want to see the wave form at the FPGA via, but it was too hard for us becausethe via was covered by thesolder mask.

We can see some reflections, but this is because the test point is at the fan-out buffer, and "chain integrity test" and "IDCODE looping" has successfully passed.

Again we checked the voltage of the power supply only to find these are stable. (Vccint = 0.97V, Vccaux = 2.44V at the minimum)

We are still at a loss what to check next and need your help.

Thank you.

[eteam00]

The latest scope waveform display is much better -- much more useful.  It looks clean enough to work reliably.  Have you looked at the rising edge as well?

What signal were you probing?  Have you posted a schematic which includes the signal (and probe point) of the 'scope waveform, including the fanout buffer you mention?

-- Bob Elkind

[austin]

You are going to have to look at the signal, at the input pins of the device....

Looking at the output driver is like looking for your lost car keys at night under the streetlight, when they were thrown into the dark (away from the light).

The only place that matters, is at the input.  What you need to realize is that the TCLK, and TDI (clock and data) input signals need to be clean (as described previously).

You should also have a signal integrity tool where you did a simulation, so that you are able to confirm that what you designed it to do, it did.

If you tell us what the schematic looks like:  driver part number, length and impedance of the pcb traces, how the signals are connected to the inputs, I will run a Hyperlynx simulation, and post the results.

For example:

TCLK comes from a CMOS driver (generic 74HC component) thru to a ribbon cable with TCK adjacent to a ground wire, to a connector for TCK and ground, onto the pcb to a 68 ohm trace, for 10 cm, to the first FPGA TCK pin, and then onto the second FPGA TCK pin thru 6cm of 68 ohm trace....

The attached picture (png file screen capture shows how the TCK in the middle has a terrible glitch in the rising edge....

What is your board doing?