We are programming an FPGA (Spartan2E) via a CPLD in Slave-Serial-Mode. The CPLD loads the bitfile from FLASH and writes it to the FPGA.
When we are programming a bitfile into an FPGA without "MicroBlaze" via CPLD, the programming is always successful, after programming the DONE-Pin goes high and the application is running.
Now our problem: when programming a bitfile including "MicroBlaze" via CPLD, the DONE-Pin fails to go high after programming. The INIT-Pin is always HIGH, after switching on or after releasing the PROG-Pin.
In both cases we use the same process properties. Btw: when programming the same bitfile via JTAG (CCLK is changed to JTAG-Clock), no problems occur.
Did anybody else had this problem before?
Did anybody else programmed a bitfile (containing a "MicroBlaze") to the FPGA without using JTAG?
"C.Jesko" schrieb im Newsbeitrag news: snipped-for-privacy@webx.sUNCHnE...
The CPLD loads the bitfile from FLASH and writes it to the FPGA.
CPLD, the programming is always successful, after programming the DONE-Pin goes high and the application is running.
CPLD, the DONE-Pin fails to go high after programming. The INIT-Pin is always HIGH, after switching on or after releasing the PROG-Pin.
the same bitfile via JTAG (CCLK is changed to JTAG-Clock), no problems occur.
the only thing that can be the issue is that there are some different bitgen options for the designs, the "microblaze" in your design can not cause any problems there must be some other thing that is configured differently in the bitstream
FPGA without using JTAG? sure, on many different boards
CPLD loads the bitfile from FLASH and writes it to the FPGA.
the programming is always successful, after programming the DONE-Pin goes high and the application is running.
the DONE-Pin fails to go high after programming. The INIT-Pin is always HIGH, after switching on or after releasing the PROG-Pin.
same bitfile via JTAG (CCLK is changed to JTAG-Clock), no problems occur.
without using JTAG?
I don't think the problem is Microblaze, since you were successful programming via JTAG. Very good that you did this test.
My guess is that the two bitstreams are different lengths. You are probably writing data to the FPGA from your CPLD in multiples of the width of your FLASH. For the succesful bitstream, the bitstream actually ends 4 or more bits from the end of the last word of the FLASH, so you are generating 4 or more extra clocks beyond the last actual data bit. Your failing bistream ends much closer to the end of whatever the last word from the FLASH is.
There is a requirement that you supply about 4 more clocks after the end of the bitstream tosequence the startup state machine. One of your bitstreams is doing this (by luck), and the other isn't (less lucky). I assume you have something in the FLASH that tells the CPLD howmany words to fetch and serialize. The simple solution is to add 1 more word of all '1' bits to the end of the bitstream, and tell the CPLD to send 1 more word worth of data.
Please write back with the following info:
The length of the two bitstreams. The width of the FLASH. Where the bitstream ends in the two different FLASH images.
The bitfile has always the same length (3961632 bit for an Spartan2E-600)!
The bitfile in the FLASH has always the same lenght, it starts with the synchronization words (FF FF FF FF AA 99 55 66...) and ends with the dummy words.
The FLASH has width of 64 Megabit. We use the AM29LV640MH/L from AMD.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.