Answers Database
FPGA Configuration: DONE Pin does not go HIGH...
Record #3684
Product Family: Documentation
Product Line: FPGA Apps.
Product Part: Configuring FPGAs/Processorbus
Problem Title:
FPGA Configuration: DONE Pin does not go HIGH...
Problem Description:
Urgency: Standard
General Description:
What are the causes that make the DONE pin to stay low?
Solution 1:
DONE goes high when the LCA configuration memory is full, and the FPGA has received a LENGTH_COUNT n
umber of CCLKs. If Done does not go high, this usually means that the device either has not filled i
ts configuration memory, or has not received sufficient CCLKs, and you need to check the following:
Is INIT valid (HIGH) but DONE still LOW?
This implies that there is problem with the physical loading of the data.
a) Is there data appearing at DIN? If configuring in a master serial mode, check to see that the PRO
M is actually enabled, and that it is outputing data on its data pin.
b) The FPGA may not have received enough CCLK cycles. This is a common problem in peripheral mode an
d slave mode, as well as in daisy chain arrangements. In peripheral mode, the last two bits of each
byte do not get clocked out-until the next byte is written to the FPGA. In both slave and pheriphera
l modes, you can rerun Makebits with the -lc = aligned_lc option to use in both slave and peripheral
modes, you can rerun Makebits with -lc = aligned_lc option to use the aligned to length count lengt
h count calculation method. The length count alignment method will adjust length count so that lengt
h count is met on the first bit of the last byte in the bitstream. Using this method will ensure tha
t you get enough configuration clocks to make the device complete the configuration process.
If you are configuring in slave mode and CCLK can be controlled, you can also try sending clocks unt
il DONE goes high instead of sending some fixed number of clocks based on the default length count c
alculation method.
If you are configuring in pheripheral mode, the fact that the last two bits of each byte do not get
clocked through the FPGA until the next byte is written to the device can be overcome by writing an
additional byte (11111111) to the device.
c) Do the first 40 bits out of DOUT match the first bits of DIN, starting with the preamble?
(The preamble will be FF20 for the .bit files, and FF04 for PROM files. In both cases, DOUT should a
ppear as FF20.)
If there any mismatch of bits between DIN and DOUT, check CCLK and DIN on an oscilloscope for noise,
as this may corrupt the actual length count value. Noise on CCLK may cause double clocking of data
bits. If a "1" in length count is double clocked, it may give you a length count that is up to 2^23
times the actual value.
d) If configuring in slave mode and CCLK can be controlled, keep sending clocks until DONE goes high
instead of counting the number of clocks being sent. Sending additional configuration clocks after
length count is met or DONE goes high does not harm the device. If you are using the XChecker cable,
the number of CCLKs sent by the cable cannot be controled; however the cable always sends 25 additi
onal clocks in excess of any given length by default.
e) Sometimes the Xchecker gives the following message:
"DONE pin did not go high."
Check the following:
1. Mismatch part specified in .bit file and device under test
2. D/P pin needs to have a 10-50K pull-up resistor.
3. Data contention w/PROM device.
End of Record #3684 - Last Modified: 11/17/98 10:38 |
