04-14-2013 11:37 PM
I am trying to program KC705 evalution kit(Kintex7) using Slave serial mode. I have connected program_b, Init_b and done pin with processor's GPIO. Flash_D0 pin and CCLK lines are connected to Processor's SPI lines(i.e. MOSI and CLK). I am sending .bit continuesly through SPI. I have also tried to probe FLASH_D0 line and I found that BItstream goes to FPGA in 8-bit mode continue. But the Done signal does not get high.
Could anyone please let me know what could be the reason?
04-15-2013 10:41 AM
There are quite a few reasons for DONE not to go high. Basically everything has to go right
or it won't go high.
1) Make sure you have a pull-up resistor on DONE, or set the "Drive DONE high" attribute when
you generate the .bit file.
2) Monitor the INIT_B line to see if it ever goes low during programming. This would indicate
that there was a CRC error, and might mean that you aren't shifting the bits in the correct order
(MSB first unless you had a bit swap when you configured the file for the microprocessor). It
could also indicate a signal integrity problem on the CCLK input of the FPGA.
3) If you have a JTAG connector, hook up a USB cable II or other compatible JTAG cable and
run Impact. You can use debug commands in Impact to read out the status register after
configuration fails. This may give more hints as to what went wrong.
04-16-2013 02:47 AM
Thanks for your input. We are able to get DONE pin high, but I found that DONE pin does not stay at high logic, it frequeantly goes low after programming. I belive that it happens may be because I am not sending 8 clock pulses after done get HIGH logic.
I also found that Done pin goes high only for less than 5MHz serial clock. Could you please let me know what is the maximum frequency Kintex7 support for slave serail mode?
04-16-2013 06:21 AM
"We are able to get DONE pin high, but I found that DONE pin does not stay at high logic, it frequeantly goes low after programming. I belive that it happens may be because I am not sending 8 clock pulses after done get HIGH logic."
Actually DONE should always stay high unless you re-program the device. Additional clocks may be needed to
start up the design (release global set/reset and enable I/O drivers). However failure to finish the startup should
not cause DONE to go back low. I would check two things:
1: Is something else is driving DONE low?
2: Is the part losing its program? i.e. all outputs go back to tristate, perhaps with weak pullups.
#2 could mean that either you are re-asserting PROGRAM_B low for some reason, or it could indicate
that some power supply has dropped below the startup threshold. This can happen if your design's
dynamic power exceeds the power supply current, or if there is not adequate output capacitance on
the supply to hold up the voltage through the initial step up of current draw.
"I also found that Done pin goes high only for less than 5MHz serial clock. Could you please let me know what is the maximum frequency Kintex7 support for slave serail mode?"
You should be able to find this in the device data sheet (the one with electrical characteristics,
but I'd be surprised if it were much less than 100 MHz. If a slower clock helps, it could mean
that you aren't providing enough setup time on the D0/DIN input, or it could also be related to
05-15-2013 10:30 PM
No mater about your configuration frequency, as per the datasheet suggession, provide the addional clock cycles nearly 15 cycles after the bitstream loading, then you can find that Done pin will be high continuesly, I also faced the similar problem with Kintex-7 FPGA & my CCLK is 16MHz it is working fine after 15 cycles.
08-26-2013 11:40 PM
I am able to load bit file in slave serial mode, but now the issue is that my small bit file(size is 15MB code logic inside bit file is D-flip flop only) loads successfully, but when I try to load proper bit file which contains more logic is not loading and done pin does not get high.
Could anyone please let me know which should be the issue?
08-27-2013 06:09 AM
The first thing I'd check is that the full design has all of its output pins located properly so that you're not running into drive contention on the board.
The next thing to look at is your power supplies. The dynamic current drawn by the larger design might be enough to overload your power supplies. Or even if your supplies can handle this much (constant) load, they may not have good response to the large current transient when the design starts up. Often adding more bulk filter capacitors can help this sort of problem. The first supply to check would be Vccint, since this is likely to have the largest dynamic current change and it must remain above the minimum required voltage level to prevent an internal brown-out reset.
Again, if you can access the JTAG port, use Impact to debug the issue. You can read the device status with Impact, and that can give clues as to what happened.
08-27-2013 07:23 AM
Thanks for your imediate reply.
I have found following observation with bit file having more design logic.
Bit file is size of 15MB, so if I load more chunk i.e. 128Byte or higher at freq 5MHz then it fails to load, but the same bit file loads successfully if I transfer it ini chunk of 64Byte.
So what could be the reason for that?
Thanks & Regards,
08-27-2013 08:42 AM
The size of the bitsream is always the same (unless you compress), but the content is not. So the simple bitstream likely clocks tons of zeros while the real bitstream clocks more realistic data of alternating zeros and ones. So it sounds like you have a signal integrity issue on the board. Check your clock for double clocking or data line reflections. Is INIT going high when the bitstream doesn't load?
08-27-2013 08:53 AM
I think you meant "is INIT_B going low when the bitstream doesn't load."
This would be a good thing to check. However the fact that breaking up the bitstream into smaller chunks makes a difference does not seem to point to a signal integrity issue. I'm wondering if there is a bug in the code that sends the bitstream that only occurs at larger buffer sizes. When there are a lot of zeroes in the bitstream, it's possible that the bug gets masked because there is no change in the data.
12-19-2018 06:03 AM
I think that Flash_D1 (not D0) is the correct line to be connected to Processor's SPI MOSI.
01-20-2019 09:45 PM - edited 01-20-2019 09:48 PM
We have the same problem, DONE bit remains low after transferring bit file . On checking INIT_B ,do not show any errors.
Could anyone please let me know what could be the reason?