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

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.
http://www.enterpoint.co.uk


"gw" <guenter.wolpert@orsys.de> wrote in message 
news:1119011442.346145.82770@o13g2000cwo.googlegroups.com...
> 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
> 

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

The point is that DONE is not always an open drain drive. Have a look at 
this Xilinx answer 
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=5865 
and you might get a clearer understanding.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development 
Board.
http://www.enterpoint.co.uk


"gw" <guenter.wolpert@orsys.de> wrote in message 
news:1119014517.226639.8750@g47g2000cwa.googlegroups.com...
> 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
> 

John Adair schrieb:
> The point is that DONE is not always an open drain drive. Have a look at
> this Xilinx answer and you might get a clearer understanding.
>

>>Answers Database
>>Virtex, Virtex-II Configuration - The DONE pin goes High, but the device does
>>not start up (I/Os are inactive/3-stated)

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

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.

"Berty" <wooster.berty@gmail.com> wrote in message 
news:1119024451.072046.217090@z14g2000cwz.googlegroups.com...
> 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.
>
>

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 **
----------------------------------------------------------        
                http://www.nuthinbutnews.com

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:
> "Berty" <wooster.berty@gmail.com> wrote in message
> news:1119024451.072046.217090@z14g2000cwz.googlegroups.com...
> > 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.
> >
> >
>
> 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 **
> ----------------------------------------------------------
>                 http://www.nuthinbutnews.com

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.

"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag
news:1119026650.260592.64880@g44g2000cwa.googlegroups.com...

> 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.

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