Xlinix configuration: DONE pin too early?

Hello,

We use different Xilinx FPGAs (Spartan3, Virtex2, etc.). When downloading the code, everything works fine except the fact that the DONE pine is going high before the last data is written (tested on XC2V250fg456 or XC3S50vc100: DONE goes high after writing the N-13th byte). If we check the ODNE pin after loading ALL bytes, everyhing is still fine, but we would like to check the INIT pin during the configuration process in order to determine CRC errors. Has anyone experince with this, thus is it possible to determine when the DONE pins must go high and is it possible to define a point at the end of the configuration process where the INIT pin can be checked for CRC errors?

thanks for any comments.... Guenter

Reply to
gw
Loading thread data ...

Have you got the "DRIVE DONE PIN HIGH" option selected for one of your designs in the Generate Programming File stage of ISE?

John Adair Enterpoint Ltd. - Home of MINI-CAN. PCI and CAN Development Board.

formatting link

Reply to
John Adair

At least there is an external pull-up on the DONE pin. Anyway, even if the DONE pin is an open collector only, it shouldn't stop pulling low before the end of the data?

The only thing with the open collector option is that DONE may come a little bit later than expected.

One additional thing we observed is that the FPGA started to drive its outputs one clock before the DONE appeared. Therefore it seems that the configuration process is already over before all data is written to the FPGA. Guenter

Reply to
gw

The point is that DONE is not always an open drain drive. Have a look at this Xilinx answer

formatting link
and you might get a clearer understanding.

John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board.

formatting link

Reply to
John Adair

John Adair schrieb:

Well, this points to a different topic. We don't have any problems after the done pin is high. We have the problem (?) that the DONE pin goes high earlier than expected. The loaded code works very well.

Although I doubt that this is a problem, I'll go and check the bitstream option and the lower pull-up value (we use more than 330 Ohms).

Can you confirm that the DONE only appears *after* all configuration data has been sent?

Guenter

Reply to
gw

Some time ago I wrote a loader to load the Xilinx Spartan2 but this should be the same for the Virtex2 and Spartan3 as far as I know and when I checked back than the signal behave the done should only go active after the whole bitstream was loaded and the crc was ok. You can control when it will go using the Startup Option (By default it come before the output are enable and the internal reset is released).

If the reason you are concern about good CRC is that if it is bad you want to try and reload or maybe load different bitstream than what I did was once I ended loading the bitstream I let 16 clocks pass and than checked the done. I don't recall why I use 16 clock as the startup don't let you delay for so long and probably count to 6 should be enough but ...

Have fun.

Reply to
Berty

I too have written a loader for Spartan II, and I can confirm that DONE becomes active before the correct number of bits is loaded. At one point my load code stopped clocking when it saw DONE go high - but the fpga would then not operate. I now always send the correct number of clocks and then check DONE and everything is fine ...

Dave

Posted Via Nuthinbutnews.Com Premium Usenet Newsgroup Services

---------------------------------------------------------- ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **

----------------------------------------------------------

formatting link

Reply to
Dave Garnett

Let's get back to basics: As configuration approaches its end, there are three things that must happen:

The internal global reset must be released The universal 3-stating of all outputs must end DONE must go High.

The configuration options allow you to rearrange the sequence of these events anyway you like. Obviously, the clocking must continue until the last of these events is finished. And a few extra clocks never hurt. These are basic things that have been known and described ever since the early XC4000 days, more than 10 years ago. Peter Alfke

Dave Garnett wrote:

Reply to
Peter Alfke

I believe you are mixing two things, the DONE go high after the CRC is checked. The fact you need to give extra clock have nothing to do with the CRC checker. It has to do with the fact that the FPGA require few more clocks after the last data bit was received. Have Fun.

Reply to
Berty

"Peter Alfke" schrieb im Newsbeitrag news: snipped-for-privacy@g44g2000cwa.googlegroups.com...

So far so good. But the OP stated something like

"When downloading the code, everything works fine except the fact that the DONE pine is going high before the last data is written (tested on XC2V250fg456 or XC3S50vc100: DONE goes high after writing the N-13th byte)."

Maybe a miscount in the software routine? Which file format is used for downloading? *.bit, *.hex or *.mcs? Remember that *.bit has some (non constant) "garbarge" at the beginning, the real data stream starts after the sync sequence.

Just my two (Euro)cents

Regards Falk

Reply to
Falk Brunner

Falk Brunner wrote: [...]

I don't think it is a miscount... Berty has it right - the DONE pin going high doesn't indicate you've completed all the clocking that the FPGA requires.

Marc

Reply to
Marc Randolph

Thanks for all the comments so far.

I know that the bitgen options can modify the startup behaviour and therefore a different number of clocks are required to finish the configuration process.

Anyway, what I want to know is: When do I have to stop checking for CRC errors on the INIT pin?

The loader I write should be used with different FPGA families and the project that creates the bitstream is not under my control, so I probably can't define the bitgen options. Even the hardware connections are not fixed, so there is some need for CRC checking during configuration. The bitsream I use is generated from an ASCII configuration file (.rbt).

Here's a little correction of what I've observed: After writing the n-13th byte one of the I/Os that is an output goes high. After the next byte INIT changes to low and DONE changes to high. INIT is also used as an I/O in the design. Therefore I would suspect that at this time the internal GTS and/or GSR signals toggle and INIT switches from configuration to I/O. Therefoe the INIT toggling shouldnt be considered as a CRC error.

So let's redefine the question as follows: How can I determine when to stop polling INIT for CRC errors? Do I have to know the bitgen options with which the bitstream was generated? Or can I simply ignore the INIT pin one (or more?) clock(s) before DONE goes high? Perhaps there is some application note that shows a little bit more details than the usual datasheets?

Guenter

Reply to
Guenter Wolpert

Take a look at the very end of

formatting link

which is the Spartan-3 data sheet. It has a good description of the configuration process. It benefits from many previous generations, and it was compiled by Steve Knapp who has an excellent track record of providing good explanations. (used to be my claim to fame...) Peter Alfke, Xilinx Applications

Reply to
Peter Alfke

And if I am allowed a supplementary question ... I've recently been bitten when upgrading ISE versions because the 'Compress Bitstream' option got set. If this is on, then a .rbt file is produced which is shorter (not too suprising !). Is there any way to determine whether a given .rbt file has been compressed ? How has the compression been done - if I just send the bitstream to the device will it decompress automatically ? How do I determine how many clocks will be needed ?

Dave

Posted Via Nuthinbutnews.Com Premium Usenet Newsgroup Services

---------------------------------------------------------- ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **

----------------------------------------------------------

formatting link

Reply to
Dave Garnett

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.