Spartan-3 configuration -- peculiar problem

Hello All,
  I'm three days into this configuration problem,
so I think it's time to consult the experts.
Problem's like this usually seem trivial in
retrospect, but I've usually been looking in
the wrong places...

  Briefly, INIT line goes low one CCLK pulse after
DONE line goes high. Configuration loads and runs,
but INIT line low indicates a CRC error. The signals
look quite reasonable on a scope.

 Specifics:
 On a new prototype board I'm trying to congigure
a Spartan-3 3s1000-5fg456 using a 3.3V IO micro-
controller driving the fpga's config lines. Dedicated
config lines have serial resistor (100 ohm), as
per recommendation for 3.3V tolerant config.

  I'm using slave-serial mode to write config file,
which is stored on the micro's flash memory. I've
used the same micro and method successfully in other
products (but using Spartan-2).

  I send all data frames ( FFFFFFFF , AA995566 ,
... 20000000 ) start to end of file.

  I'm not sure exactly _where_ the DONE line should
go high. It would seem that it should go high at some
point after the last 32-bit configuration frame, but
in fact DONE transitions on the 7th CCLK pulse of the
(N-4)th configuration frame. XAPP452 shows this as being
[CMD Write Packet Data(DESYNC)] frame. The INIT line
goes low on the 8th CCLK pulse, Fpga operation commences
on the 9th CCLK pulse.

  All design tweaks (resistor value changes) and clock/
data timing tweaks result in the same behavior. I would
have thought that the CRC error would have prevented
startup of the fpga (CRC is _not_ disabled in bitgen), but
I guess this is not the case...

  If the DONE line _is_ going high early, I suppose this
would mean that extra CCLK transitions were seen by
the FPGA, pointing perhaps towards signal integrity
issues, but this would puzzle me, as under different
circumstances, the transitions happen at the same
points.

  The bit file is being generated by ISE6.2.02.

  Sorry, this post is longwinded, I'm hoping that someone
in the group has encountered a similar situation and can
perhaps point me in the right direction.

  Thanks in advance...

Scott@sdeviation.com

On 14 Aug 2005 19:21:08 -0700, ScreamingFPGA@yahoo.com wrote:

>Hello All,
>  I'm three days into this configuration problem,
>so I think it's time to consult the experts.
>Problem's like this usually seem trivial in
>retrospect, but I've usually been looking in
>the wrong places...
>
>  Briefly, INIT line goes low one CCLK pulse after
>DONE line goes high. Configuration loads and runs,
>but INIT line low indicates a CRC error. The signals
>look quite reasonable on a scope.
>
> Specifics:
> On a new prototype board I'm trying to congigure
>a Spartan-3 3s1000-5fg456 using a 3.3V IO micro-
>controller driving the fpga's config lines. Dedicated
>config lines have serial resistor (100 ohm), as
>per recommendation for 3.3V tolerant config.
>
>  I'm using slave-serial mode to write config file,
>which is stored on the micro's flash memory. I've
>used the same micro and method successfully in other
>products (but using Spartan-2).
>
>  I send all data frames ( FFFFFFFF , AA995566 ,
>... 20000000 ) start to end of file.
>
>  I'm not sure exactly _where_ the DONE line should
>go high. It would seem that it should go high at some
>point after the last 32-bit configuration frame, but
>in fact DONE transitions on the 7th CCLK pulse of the
>(N-4)th configuration frame. XAPP452 shows this as being
>[CMD Write Packet Data(DESYNC)] frame. The INIT line
>goes low on the 8th CCLK pulse, Fpga operation commences
>on the 9th CCLK pulse.
>
>  All design tweaks (resistor value changes) and clock/
>data timing tweaks result in the same behavior. I would
>have thought that the CRC error would have prevented
>startup of the fpga (CRC is _not_ disabled in bitgen), but
>I guess this is not the case...
>
>  If the DONE line _is_ going high early, I suppose this
>would mean that extra CCLK transitions were seen by
>the FPGA, pointing perhaps towards signal integrity
>issues, but this would puzzle me, as under different
>circumstances, the transitions happen at the same
>points.
>
>  The bit file is being generated by ISE6.2.02.
>
>  Sorry, this post is longwinded, I'm hoping that someone
>in the group has encountered a similar situation and can
>perhaps point me in the right direction.
>
>  Thanks in advance...
>
>Scott@sdeviation.com


You might try banging some extra dummy bits; sometimes that helps.

John

John Larkin wrote:
> On 14 Aug 2005 19:21:08 -0700, ScreamingFPGA@yahoo.com wrote:
>
> >Hello All,
> >  I'm three days into this configuration problem,
> >so I think it's time to consult the experts.
> >Problem's like this usually seem trivial in
> >retrospect, but I've usually been looking in
> >the wrong places...
> >
> >  Briefly, INIT line goes low one CCLK pulse after
> >DONE line goes high. Configuration loads and runs,
> >but INIT line low indicates a CRC error. The signals
> >look quite reasonable on a scope.
> >
> > Specifics:
> > On a new prototype board I'm trying to congigure
> >a Spartan-3 3s1000-5fg456 using a 3.3V IO micro-
> >controller driving the fpga's config lines. Dedicated
> >config lines have serial resistor (100 ohm), as
> >per recommendation for 3.3V tolerant config.
> >
> >  I'm using slave-serial mode to write config file,
> >which is stored on the micro's flash memory. I've
> >used the same micro and method successfully in other
> >products (but using Spartan-2).
> >
> >  I send all data frames ( FFFFFFFF , AA995566 ,
> >... 20000000 ) start to end of file.
> >
> >  I'm not sure exactly _where_ the DONE line should
> >go high. It would seem that it should go high at some
> >point after the last 32-bit configuration frame, but
> >in fact DONE transitions on the 7th CCLK pulse of the
> >(N-4)th configuration frame. XAPP452 shows this as being
> >[CMD Write Packet Data(DESYNC)] frame. The INIT line
> >goes low on the 8th CCLK pulse, Fpga operation commences
> >on the 9th CCLK pulse.
> >
> >  All design tweaks (resistor value changes) and clock/
> >data timing tweaks result in the same behavior. I would
> >have thought that the CRC error would have prevented
> >startup of the fpga (CRC is _not_ disabled in bitgen), but
> >I guess this is not the case...
> >
> >  If the DONE line _is_ going high early, I suppose this
> >would mean that extra CCLK transitions were seen by
> >the FPGA, pointing perhaps towards signal integrity
> >issues, but this would puzzle me, as under different
> >circumstances, the transitions happen at the same
> >points.
> >
> >  The bit file is being generated by ISE6.2.02.
> >
> >  Sorry, this post is longwinded, I'm hoping that someone
> >in the group has encountered a similar situation and can
> >perhaps point me in the right direction.
> >
> >  Thanks in advance...
> >
> >Scott@sdeviation.com
>
>
> You might try banging some extra dummy bits; sometimes that helps.
>
> John

Thanks John,

   The Configuration file _does_ load, though. I think dummy bits
might help if the DONE line didn't go high. But it does. The FPGA
starts, but the problem is that the INIT line goes low subsequent
to the DONE line going high.
   There are apparently differences in configuration programming
between the Virtex/Spartan-2, and the Virtex-2/Spartan-3 that
I don't understand well enough. Especially the CRC / AutoCRC
differences. I've been studying the doc's, but at this point I'm
just confused...

Thanks for the suggestion though.

-Scott

b

On 15 Aug 2005 17:48:35 -0700, ScreamingFPGA@yahoo.com wrote:

>John Larkin wrote:
>>
>> You might try banging some extra dummy bits; sometimes that helps.
>>
>> John
>
>Thanks John,
>
>   The Configuration file _does_ load, though. I think dummy bits
>might help if the DONE line didn't go high. But it does. The FPGA
>starts, but the problem is that the INIT line goes low subsequent
>to the DONE line going high.
>   There are apparently differences in configuration programming
>between the Virtex/Spartan-2, and the Virtex-2/Spartan-3 that
>I don't understand well enough. Especially the CRC / AutoCRC
>differences. I've been studying the doc's, but at this point I'm
>just confused...
>
>Thanks for the suggestion though.
>
>-Scott
>
>b


We just take a .RBT file from ISE and pass it through a little program
that packs it verbatum into our ROM image as binary stuff, up above
the uP code (sort of a linker, sort of.) At powerup we bit-bang this
into the FPGAs in slave serial mode, plus maybe 32 extra bits for
luck. This has worked every time so far, on 4000's and S2's and S3's.

Does the INIT thing matter?

John

John Larkin wrote:
> On 15 Aug 2005 17:48:35 -0700, ScreamingFPGA@yahoo.com wrote:
>
> >John Larkin wrote:
> >>
> >> You might try banging some extra dummy bits; sometimes that helps.
> >>
> >> John
> >
> >Thanks John,
> >
> >   The Configuration file _does_ load, though. I think dummy bits
> >might help if the DONE line didn't go high. But it does. The FPGA
> >starts, but the problem is that the INIT line goes low subsequent
> >to the DONE line going high.
> >   There are apparently differences in configuration programming
> >between the Virtex/Spartan-2, and the Virtex-2/Spartan-3 that
> >I don't understand well enough. Especially the CRC / AutoCRC
> >differences. I've been studying the doc's, but at this point I'm
> >just confused...
> >
> >Thanks for the suggestion though.
> >
> >-Scott
> >
> >b
>
>
> We just take a .RBT file from ISE and pass it through a little program
> that packs it verbatum into our ROM image as binary stuff, up above
> the uP code (sort of a linker, sort of.) At powerup we bit-bang this
> into the FPGAs in slave serial mode, plus maybe 32 extra bits for
> luck. This has worked every time so far, on 4000's and S2's and S3's.
>
> Does the INIT thing matter?
>
> John

  Yeah, that's what we do too, just bang out the bit file verbatim.

  Maybe it doesn't matter. I checked my older designs, and see that I
never
monitored the INIT line, so the S2's could be behaving the same
way, and I wouldn't know it. Ignorance is bliss? Maybe I should
check...

  I noticed that the Parallel Programmer 6 pin interface adaptor
doesn't use the INIT pin either. That says something...

  It only matters in that:
1) The fpga is complaining. I'd hate to get bit by it later on
   (no pun intended).
2) In this design I use INIT (a dual purpose pin) as an input
   after config, but it persists as an output. I guess I could
   cut and jumper, but it would be nice to sort it out and save
   a board rev.

  As a practical matter, maybe I should just ignore it for the time
being. File it in the conundrum bin and move on...
 
Again, thanks for the fresh perspective.

 -Scott

On 15 Aug 2005 19:15:42 -0700, ScreamingFPGA@yahoo.com wrote:

>John Larkin wrote:
>> On 15 Aug 2005 17:48:35 -0700, ScreamingFPGA@yahoo.com wrote:
>>
>> >John Larkin wrote:
>> >>
>> >> You might try banging some extra dummy bits; sometimes that helps.
>> >>
>> >> John
>> >
>> >Thanks John,
>> >
>> >   The Configuration file _does_ load, though. I think dummy bits
>> >might help if the DONE line didn't go high. But it does. The FPGA
>> >starts, but the problem is that the INIT line goes low subsequent
>> >to the DONE line going high.
>> >   There are apparently differences in configuration programming
>> >between the Virtex/Spartan-2, and the Virtex-2/Spartan-3 that
>> >I don't understand well enough. Especially the CRC / AutoCRC
>> >differences. I've been studying the doc's, but at this point I'm
>> >just confused...
>> >
>> >Thanks for the suggestion though.
>> >
>> >-Scott
>> >
>> >b
>>
>>
>> We just take a .RBT file from ISE and pass it through a little program
>> that packs it verbatum into our ROM image as binary stuff, up above
>> the uP code (sort of a linker, sort of.) At powerup we bit-bang this
>> into the FPGAs in slave serial mode, plus maybe 32 extra bits for
>> luck. This has worked every time so far, on 4000's and S2's and S3's.
>>
>> Does the INIT thing matter?
>>
>> John
>
>  Yeah, that's what we do too, just bang out the bit file verbatim.
>
>  Maybe it doesn't matter. I checked my older designs, and see that I
>never
>monitored the INIT line, so the S2's could be behaving the same
>way, and I wouldn't know it. Ignorance is bliss? Maybe I should
>check...
>
>  I noticed that the Parallel Programmer 6 pin interface adaptor
>doesn't use the INIT pin either. That says something...
>
>  It only matters in that:
>1) The fpga is complaining. I'd hate to get bit by it later on
>   (no pun intended).
>2) In this design I use INIT (a dual purpose pin) as an input
>   after config, but it persists as an output. I guess I could
>   cut and jumper, but it would be nice to sort it out and save
>   a board rev.
>
>  As a practical matter, maybe I should just ignore it for the time
>being. File it in the conundrum bin and move on...
> 
>Again, thanks for the fresh perspective.
>
> -Scott

Are you pulling up INIT?

John

Possibly this is what John is suggesting in his previous post, but how
do you know it is the FPGA pulling Init low? You mention that the Init
pin is used as an input after config. What drives the Init pin
externally?

John Larkin wrote:
> On 15 Aug 2005 19:15:42 -0700, ScreamingFPGA@yahoo.com wrote:
>
> >John Larkin wrote:
> >> On 15 Aug 2005 17:48:35 -0700, ScreamingFPGA@yahoo.com wrote:
> >>
> >> >John Larkin wrote:
> >> >>
> >> >> You might try banging some extra dummy bits; sometimes that helps.
> >> >>
> >> >> John
> >> >
> >> >Thanks John,
> >> >
> >> >   The Configuration file _does_ load, though. I think dummy bits
> >> >might help if the DONE line didn't go high. But it does. The FPGA
> >> >starts, but the problem is that the INIT line goes low subsequent
> >> >to the DONE line going high.
> >> >   There are apparently differences in configuration programming
> >> >between the Virtex/Spartan-2, and the Virtex-2/Spartan-3 that
> >> >I don't understand well enough. Especially the CRC / AutoCRC
> >> >differences. I've been studying the doc's, but at this point I'm
> >> >just confused...
> >> >
> >> >Thanks for the suggestion though.
> >> >
> >> >-Scott
> >> >
> >> >b
> >>
> >>
> >> We just take a .RBT file from ISE and pass it through a little program
> >> that packs it verbatum into our ROM image as binary stuff, up above
> >> the uP code (sort of a linker, sort of.) At powerup we bit-bang this
> >> into the FPGAs in slave serial mode, plus maybe 32 extra bits for
> >> luck. This has worked every time so far, on 4000's and S2's and S3's.
> >>
> >> Does the INIT thing matter?
> >>
> >> John
> >
> >  Yeah, that's what we do too, just bang out the bit file verbatim.
> >
> >  Maybe it doesn't matter. I checked my older designs, and see that I
> >never
> >monitored the INIT line, so the S2's could be behaving the same
> >way, and I wouldn't know it. Ignorance is bliss? Maybe I should
> >check...
> >
> >  I noticed that the Parallel Programmer 6 pin interface adaptor
> >doesn't use the INIT pin either. That says something...
> >
> >  It only matters in that:
> >1) The fpga is complaining. I'd hate to get bit by it later on
> >   (no pun intended).
> >2) In this design I use INIT (a dual purpose pin) as an input
> >   after config, but it persists as an output. I guess I could
> >   cut and jumper, but it would be nice to sort it out and save
> >   a board rev.
> >
> >  As a practical matter, maybe I should just ignore it for the time
> >being. File it in the conundrum bin and move on...
> >
> >Again, thanks for the fresh perspective.
> >
> > -Scott
> 
> Are you pulling up INIT?
> 
> John

The INIT pin becomes user I/O after configuration. INIT going low
indicates a CRC only if it goes low before the startup sequence of the
device. If it goes low after the DONE pin has gone high then this does
not indicate a CRC error but is rather attributable to the fact that
INIT has probably become a user I/O now that the image is loaded and
the FPGA has gone through the startup process.

Stephan

John Larkin wrote:
> On 15 Aug 2005 19:15:42 -0700, ScreamingFPGA@yahoo.com wrote:
>
> >John Larkin wrote:
> >> On 15 Aug 2005 17:48:35 -0700, ScreamingFPGA@yahoo.com wrote:
> >>
> >> >John Larkin wrote:
> >> >>
> >> >> You might try banging some extra dummy bits; sometimes that helps.
> >> >>
> >> >> John
> >> >
> >> >Thanks John,
> >> >
> >> >   The Configuration file _does_ load, though. I think dummy bits
> >> >might help if the DONE line didn't go high. But it does. The FPGA
> >> >starts, but the problem is that the INIT line goes low subsequent
> >> >to the DONE line going high.
> >> >   There are apparently differences in configuration programming
> >> >between the Virtex/Spartan-2, and the Virtex-2/Spartan-3 that
> >> >I don't understand well enough. Especially the CRC / AutoCRC
> >> >differences. I've been studying the doc's, but at this point I'm
> >> >just confused...
> >> >
> >> >Thanks for the suggestion though.
> >> >
> >> >-Scott
> >> >
> >> >b
> >>
> >>
> >> We just take a .RBT file from ISE and pass it through a little program
> >> that packs it verbatum into our ROM image as binary stuff, up above
> >> the uP code (sort of a linker, sort of.) At powerup we bit-bang this
> >> into the FPGAs in slave serial mode, plus maybe 32 extra bits for
> >> luck. This has worked every time so far, on 4000's and S2's and S3's.
> >>
> >> Does the INIT thing matter?
> >>
> >> John
> >
> >  Yeah, that's what we do too, just bang out the bit file verbatim.
> >
> >  Maybe it doesn't matter. I checked my older designs, and see that I
> >never
> >monitored the INIT line, so the S2's could be behaving the same
> >way, and I wouldn't know it. Ignorance is bliss? Maybe I should
> >check...
> >
> >  I noticed that the Parallel Programmer 6 pin interface adaptor
> >doesn't use the INIT pin either. That says something...
> >
> >  It only matters in that:
> >1) The fpga is complaining. I'd hate to get bit by it later on
> >   (no pun intended).
> >2) In this design I use INIT (a dual purpose pin) as an input
> >   after config, but it persists as an output. I guess I could
> >   cut and jumper, but it would be nice to sort it out and save
> >   a board rev.
> >
> >  As a practical matter, maybe I should just ignore it for the time
> >being. File it in the conundrum bin and move on...
> >
> >Again, thanks for the fresh perspective.
> >
> > -Scott
>
> Are you pulling up INIT?
>
> John

John

  I _really_ should have ruled out the obvious before jumping to the
conclusion that there was some exotic problem...

  I had come to the conclusion that the fpga was driving the pin
low with a 'galvanic skin resistance' pull-up plus scope probe.
Didn't budge from ground, though adjacent inputs pulled-up.
Should have been a bit more systematic in that test...

  Being a bit more thorough, I just tacked in a 4.7K pull-up, and
saw that it (INIT) behaves as it should during config, but only
pulls up to ~1/4 VCCO after config. A 1.5K brings it up to ~3/4 VCCO.

  It is clear now that there is no config problem and I've been
barking up the wrong tree here. Seem's the input is unhappy after
config, but the reason is probably a board short, or at worst
a stressed IOB. I've been poking and probing it for days, so maybe
I induced some ESD damage on the IOB. In any case, no config problem.

  A million thanks John, for getting me to look in the right
place. I feel a bit foolish for letting myself get out on the
configuration tangent...

Thanks.

-Scott

ScreamingFPGA@yahoo.com wrote:
> Hello All,
>   I'm three days into this configuration problem,
> so I think it's time to consult the experts.
> Problem's like this usually seem trivial in
> retrospect, but I've usually been looking in
> the wrong places...
>
>   Briefly, INIT line goes low one CCLK pulse after
> DONE line goes high. Configuration loads and runs,
> but INIT line low indicates a CRC error. The signals
> look quite reasonable on a scope.
>
>  Specifics:
>  On a new prototype board I'm trying to congigure
> a Spartan-3 3s1000-5fg456 using a 3.3V IO micro-
> controller driving the fpga's config lines. Dedicated
> config lines have serial resistor (100 ohm), as
> per recommendation for 3.3V tolerant config.
>
>   I'm using slave-serial mode to write config file,
> which is stored on the micro's flash memory. I've
> used the same micro and method successfully in other
> products (but using Spartan-2).
>
>   I send all data frames ( FFFFFFFF , AA995566 ,
> ... 20000000 ) start to end of file.
>
>   I'm not sure exactly _where_ the DONE line should
> go high. It would seem that it should go high at some
> point after the last 32-bit configuration frame, but
> in fact DONE transitions on the 7th CCLK pulse of the
> (N-4)th configuration frame. XAPP452 shows this as being
> [CMD Write Packet Data(DESYNC)] frame. The INIT line
> goes low on the 8th CCLK pulse, Fpga operation commences
> on the 9th CCLK pulse.
>
>   All design tweaks (resistor value changes) and clock/
> data timing tweaks result in the same behavior. I would
> have thought that the CRC error would have prevented
> startup of the fpga (CRC is _not_ disabled in bitgen), but
> I guess this is not the case...
>
>   If the DONE line _is_ going high early, I suppose this
> would mean that extra CCLK transitions were seen by
> the FPGA, pointing perhaps towards signal integrity
> issues, but this would puzzle me, as under different
> circumstances, the transitions happen at the same
> points.
>
>   The bit file is being generated by ISE6.2.02.
>
>   Sorry, this post is longwinded, I'm hoping that someone
> in the group has encountered a similar situation and can
> perhaps point me in the right direction.
>
>   Thanks in advance...
>
> Scott@sdeviation.com

Thanks All

  For your considerations and patience.

  Problem solved. Mea Culpa. IIFI. A comedy of errors:

  Configuration worked perfectly from the get-go. I was convinced
there was a config problem because my little 'hello world' LED-
BLINKY-THINGY that I had dropped into the top level of the design
wasn't causing the LED to blink.

 I noticed the INIT line was low and became convinced I had a
configuration problem. I chased that for a couple of days.

 By chance I left the proto powered for a couple of hours and noticed
the LED had turned on. Checked the design and noticed I had
miscalculated the clock divisor for the LED blinker by a few
orders of magnitude and it was blinking once every 4 hours, instead
of once every second. DOH!

 By then I had fixated on the INIT line being low, and was ensconced
in my theory that the config logic was driving it there, as it
'shoudn't' have been low, by design.

 My post-config use of the INIT pin was as an input. However my design
wasn't using this particular input at this stage of the proto. The
synthesis tool re-defined it as an unused pin.

 I had asked bitgen to pull unused pins low.

 It all makes sense now.
 
Thanks again all for humoring me.

-Scott