Spartan3 Configuration Puzzler

Hi,

I'm using a microcontroller to configure a Spartan-3 device. The device
seems to configure ok (the design works as expected) but INIT_B goes
low & stays low after the last frame has been clocked in. According to
the datasheet this indicates a CRC error.

Does anyone have any idea why I'd get a CRC error but my design still
works ?

Thanks
Dave

Daveb wrote:
> Hi,
>
> I'm using a microcontroller to configure a Spartan-3 device. The device
> seems to configure ok (the design works as expected) but INIT_B goes
> low & stays low after the last frame has been clocked in. According to
> the datasheet this indicates a CRC error.
>
> Does anyone have any idea why I'd get a CRC error but my design still
> works ?
>
> Thanks
> Dave

INIT_B is a "dual-purpose" pin.  After config it is an I/O.  Make sure
you
haven't inadvertently assigned this pin as an output (this can happen
if
your .ucf file doesn't specify LOC for all top level module outputs).
When
in doubt, use FPGA editor to check the pin.

HTH,
Gabor

Gabor wrote:
> Daveb wrote:
> > Hi,
> >
> > I'm using a microcontroller to configure a Spartan-3 device. The device
> > seems to configure ok (the design works as expected) but INIT_B goes
> > low & stays low after the last frame has been clocked in. According to
> > the datasheet this indicates a CRC error.
> >
> > Does anyone have any idea why I'd get a CRC error but my design still
> > works ?
> >
> > Thanks
> > Dave
>
> INIT_B is a "dual-purpose" pin.  After config it is an I/O.  Make sure
> you
> haven't inadvertently assigned this pin as an output (this can happen
> if
> your .ucf file doesn't specify LOC for all top level module outputs).
> When
> in doubt, use FPGA editor to check the pin.
>
> HTH,
> Gabor

Gabor

I've checked my .ucf file & loaded it into FPGA pin editor & INIT_B
isn't inadvertently being used by the design. I'm really quite baffled
as to what is going on because the datasheet says that if the CRC is
incorrect then the startup sequence is aborted. In this situation I'm
assuming the design isn't used to configure the device. Maybe this is
an incorrect assumption ?

Dave

"Daveb" <dave.bryan@gmail.com> wrote in message 
news:1164743617.931311.315690@n67g2000cwd.googlegroups.com...
> Hi,
>
> I'm using a microcontroller to configure a Spartan-3 device. The device
> seems to configure ok (the design works as expected) but INIT_B goes
> low & stays low after the last frame has been clocked in. According to
> the datasheet this indicates a CRC error.
>
> Does anyone have any idea why I'd get a CRC error but my design still
> works ?
>
> Thanks
> Dave

You may have the bitgen option for the INIT_B "Persist" set to "No" for this 
pin, making the INIT_B no longer determined by the configuration logic once 
you're programmed.

The fact that your design works says that the INIT_B stayed high throughout 
the startup sequence.  The flow diagram in the documentation you were 
probably looking at shows that a CRC error does not allow you to enter user 
mode. 

"Daveb" <dave.bryan@gmail.com> wrote in message 
news:1164754755.908635.123850@16g2000cwy.googlegroups.com...
> Gabor wrote:
>> Daveb wrote:
>> > Hi,
>> >
>> > I'm using a microcontroller to configure a Spartan-3 device. The device
>> > seems to configure ok (the design works as expected) but INIT_B goes
>> > low & stays low after the last frame has been clocked in. According to
>> > the datasheet this indicates a CRC error.
>> >
>> > Does anyone have any idea why I'd get a CRC error but my design still
>> > works ?
>> >
>> > Thanks
>> > Dave
>>
>> INIT_B is a "dual-purpose" pin.  After config it is an I/O.  Make sure
>> you
>> haven't inadvertently assigned this pin as an output (this can happen
>> if
>> your .ucf file doesn't specify LOC for all top level module outputs).
>> When
>> in doubt, use FPGA editor to check the pin.
>>
>> HTH,
>> Gabor
>
> Gabor
>
> I've checked my .ucf file & loaded it into FPGA pin editor & INIT_B
> isn't inadvertently being used by the design. I'm really quite baffled
> as to what is going on because the datasheet says that if the CRC is
> incorrect then the startup sequence is aborted. In this situation I'm
> assuming the design isn't used to configure the device. Maybe this is
> an incorrect assumption ?
>
> Dave
>

Dave,

During configuration, there are several CRC checks.  The first makes sure 
that the bitstream device ID matches that of the device being programmed. 
The other CRC checks are performed after the final frame of each FRDI read 
sequence.  After the final CRC is completed, the startup sequence begins and 
DONE goes high (assuming default startup).  The IO's are released as well as 
internal FF's and RAM.

As you are not using INIT as an IO in your design, the default is to attach 
a weak pulldown on the (all unused) IO.  Thus, it is now low.  Without 
knowing what type of file you are using with your u-proc configuration, it 
is hard to say what is contained in the last frame of the configuration 
file, but everything you are describing appears to be normal.

You can always specify to leave unused IO as floating or pulled up if you 
wanted to test this for a sanity check.

-David 

davide wrote:
> "Daveb" <dave.bryan@gmail.com> wrote in message
> news:1164754755.908635.123850@16g2000cwy.googlegroups.com...
> > Gabor wrote:
> >> Daveb wrote:
> >> > Hi,
> >> >
> >> > I'm using a microcontroller to configure a Spartan-3 device. The device
> >> > seems to configure ok (the design works as expected) but INIT_B goes
> >> > low & stays low after the last frame has been clocked in. According to
> >> > the datasheet this indicates a CRC error.
> >> >
> >> > Does anyone have any idea why I'd get a CRC error but my design still
> >> > works ?
> >> >
> >> > Thanks
> >> > Dave
> >>
> >> INIT_B is a "dual-purpose" pin.  After config it is an I/O.  Make sure
> >> you
> >> haven't inadvertently assigned this pin as an output (this can happen
> >> if
> >> your .ucf file doesn't specify LOC for all top level module outputs).
> >> When
> >> in doubt, use FPGA editor to check the pin.
> >>
> >> HTH,
> >> Gabor
> >
> > Gabor
> >
> > I've checked my .ucf file & loaded it into FPGA pin editor & INIT_B
> > isn't inadvertently being used by the design. I'm really quite baffled
> > as to what is going on because the datasheet says that if the CRC is
> > incorrect then the startup sequence is aborted. In this situation I'm
> > assuming the design isn't used to configure the device. Maybe this is
> > an incorrect assumption ?
> >
> > Dave
> >
>
> Dave,
>
> During configuration, there are several CRC checks.  The first makes sure
> that the bitstream device ID matches that of the device being programmed.
> The other CRC checks are performed after the final frame of each FRDI read
> sequence.  After the final CRC is completed, the startup sequence begins and
> DONE goes high (assuming default startup).  The IO's are released as well as
> internal FF's and RAM.
>
> As you are not using INIT as an IO in your design, the default is to attach
> a weak pulldown on the (all unused) IO.  Thus, it is now low.  Without
> knowing what type of file you are using with your u-proc configuration, it
> is hard to say what is contained in the last frame of the configuration
> file, but everything you are describing appears to be normal.
>
> You can always specify to leave unused IO as floating or pulled up if you
> wanted to test this for a sanity check.
>
> -David

Thanks for the suggestions.

I decided to set the INIT_B to an output forced high in my design and
hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual
purpose I/O pins are weak pull down. Turns out that there's weak and
there's weak! the pull down can be less than 2K so my (fairly weak)
pull up lost. So no CRC error after all but I should have read the
datasheet in more detail before panicking.

DaveB

Daveb wrote:
> I decided to set the INIT_B to an output forced high in my design and
> hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual
> purpose I/O pins are weak pull down. Turns out that there's weak and
> there's weak! the pull down can be less than 2K so my (fairly weak)
> pull up lost. So no CRC error after all but I should have read the
> datasheet in more detail before panicking.

You are not the first engineer to have been caught napping by the
Spartan 3 "weak" pullups (downs).  Where I work, there is a strong
tendancy to not act, or even react, but to *over*react to issues.
Someone discovered this on a project a couple of years ago and decided
to use 0 ohm jumpers to set the config pins.  Then when I was drawing
up my schematics, like you, I initially used resistors that were
inappropriate.  When another engineer corrected me and I investigated,
I found what the issue was and decided to only add jumpers to ground
since the pullups were plenty strong enough to pull up and could not be
turned off.  That led to a tirade about how 0 ohm jumpers were required
in *all* cases on the Spartan 3s, pullup or pulldown.  Of course this
is not correct, but that day it was no fun being right.

The long and the short of it is that Xilinx does not always get this
stuff right and they don't consider this broken enough to fix it.  You
would think they would note this clearly in the documentation that this
part is very different from their other devices.

"rickman" <gnuarm@gmail.com> wrote in message 
news:1164822883.158338.136150@j72g2000cwa.googlegroups.com...
> Daveb wrote:
>> I decided to set the INIT_B to an output forced high in my design and
>> hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual
>> purpose I/O pins are weak pull down. Turns out that there's weak and
>> there's weak! the pull down can be less than 2K so my (fairly weak)
>> pull up lost. So no CRC error after all but I should have read the
>> datasheet in more detail before panicking.
>
> You are not the first engineer to have been caught napping by the
> Spartan 3 "weak" pullups (downs).  Where I work, there is a strong
> tendancy to not act, or even react, but to *over*react to issues.
> Someone discovered this on a project a couple of years ago and decided
> to use 0 ohm jumpers to set the config pins.  Then when I was drawing
> up my schematics, like you, I initially used resistors that were
> inappropriate.  When another engineer corrected me and I investigated,
> I found what the issue was and decided to only add jumpers to ground
> since the pullups were plenty strong enough to pull up and could not be
> turned off.  That led to a tirade about how 0 ohm jumpers were required
> in *all* cases on the Spartan 3s, pullup or pulldown.  Of course this
> is not correct, but that day it was no fun being right.
>
> The long and the short of it is that Xilinx does not always get this
> stuff right and they don't consider this broken enough to fix it.  You
> would think they would note this clearly in the documentation that this
> part is very different from their other devices.

Starting in the Spartan-3 FPGA Family: Functional Description v1.4 (August 
19 2005) diction similar to the first instance is found:

  The Spartan-3 I/O pull-up and pull-down resistors are stronger
  than the "weak" pull-up/pull-down resistors used in previous
  Xilinx FPGA families. See Table 6, Module 3 for
  equivalent resistor strengths.

Your design was probably before the data sheet revision but the 
documentation DOES reflect this change.  If you've looked at the S3E data 
sheet, your comment that "You
> would think they would note this clearly in the documentation" is made 
> MORE clear by adding the great big warning signs and outlined text to 
> emphasize the issues that are issues.

They didn't do a good job with the resistor strength in S3, absolutely. 
They _have_ taken care of the documentation side of things. 

John_H wrote:
> "rickman" <gnuarm@gmail.com> wrote in message
> news:1164822883.158338.136150@j72g2000cwa.googlegroups.com...
> > Daveb wrote:
> >> I decided to set the INIT_B to an output forced high in my design and
> >> hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual
> >> purpose I/O pins are weak pull down. Turns out that there's weak and
> >> there's weak! the pull down can be less than 2K so my (fairly weak)
> >> pull up lost. So no CRC error after all but I should have read the
> >> datasheet in more detail before panicking.
> >
> > You are not the first engineer to have been caught napping by the
> > Spartan 3 "weak" pullups (downs).  Where I work, there is a strong
> > tendancy to not act, or even react, but to *over*react to issues.
> > Someone discovered this on a project a couple of years ago and decided
> > to use 0 ohm jumpers to set the config pins.  Then when I was drawing
> > up my schematics, like you, I initially used resistors that were
> > inappropriate.  When another engineer corrected me and I investigated,
> > I found what the issue was and decided to only add jumpers to ground
> > since the pullups were plenty strong enough to pull up and could not be
> > turned off.  That led to a tirade about how 0 ohm jumpers were required
> > in *all* cases on the Spartan 3s, pullup or pulldown.  Of course this
> > is not correct, but that day it was no fun being right.
> >
> > The long and the short of it is that Xilinx does not always get this
> > stuff right and they don't consider this broken enough to fix it.  You
> > would think they would note this clearly in the documentation that this
> > part is very different from their other devices.
>
> Starting in the Spartan-3 FPGA Family: Functional Description v1.4 (August
> 19 2005) diction similar to the first instance is found:
>
>   The Spartan-3 I/O pull-up and pull-down resistors are stronger
>   than the "weak" pull-up/pull-down resistors used in previous
>   Xilinx FPGA families. See Table 6, Module 3 for
>   equivalent resistor strengths.
>
> Your design was probably before the data sheet revision but the
> documentation DOES reflect this change.  If you've looked at the S3E data
> sheet, your comment that "You
> > would think they would note this clearly in the documentation" is made
> > MORE clear by adding the great big warning signs and outlined text to
> > emphasize the issues that are issues.
>
> They didn't do a good job with the resistor strength in S3, absolutely.
> They _have_ taken care of the documentation side of things.

I don't agree with this.  I had this discussion with Xilinx (mostly in
this group) when I was investigating the behavior of all the pullups on
all the pins of the Spartan 3.  I found that the required information
was scattered over multiple sections of the document and stated in
different ways that even appear to contradict each other in some ways.
Xilinx did make some adjustments to the data sheet, but I think the
issue of using the pullup resistors in Spartan 3 devices is complicated
enough that the information should be pulled together in one section
where it can be found easily and completely.  No one has time to read
every sentance in a 200 page document.  Instead we rely on the tools
available for searching the document and typically don't expect to have
to find info in multiple places to tell us the *whole* story.

Putting one sentance at the end of one section is not what I would call
"taking care" of documentation.  Obviously people are still missing
this sentance and not realizing that the Spartan 3 pullups are
different from the pullups on nearly every FPGA made by any vendor.

"rickman" <gnuarm@gmail.com> wrote in message 
news:1164827093.834310.306760@80g2000cwy.googlegroups.com...
> John_H wrote:
>> Starting in the Spartan-3 FPGA Family: Functional Description v1.4 
>> (August
>> 19 2005) diction similar to the first instance is found:
>>
>>   The Spartan-3 I/O pull-up and pull-down resistors are stronger
>>   than the "weak" pull-up/pull-down resistors used in previous
>>   Xilinx FPGA families. See Table 6, Module 3 for
>>   equivalent resistor strengths.
>>
>> Your design was probably before the data sheet revision but the
>> documentation DOES reflect this change.  If you've looked at the S3E data
>> sheet, your comment that "You
>> > would think they would note this clearly in the documentation" is made
>> > MORE clear by adding the great big warning signs and outlined text to
>> > emphasize the issues that are issues.
>>
>> They didn't do a good job with the resistor strength in S3, absolutely.
>> They _have_ taken care of the documentation side of things.
>
> I don't agree with this.  I had this discussion with Xilinx (mostly in
> this group) when I was investigating the behavior of all the pullups on
> all the pins of the Spartan 3.  I found that the required information
> was scattered over multiple sections of the document and stated in
> different ways that even appear to contradict each other in some ways.
> Xilinx did make some adjustments to the data sheet, but I think the
> issue of using the pullup resistors in Spartan 3 devices is complicated
> enough that the information should be pulled together in one section
> where it can be found easily and completely.  No one has time to read
> every sentance in a 200 page document.  Instead we rely on the tools
> available for searching the document and typically don't expect to have
> to find info in multiple places to tell us the *whole* story.
>
> Putting one sentance at the end of one section is not what I would call
> "taking care" of documentation.  Obviously people are still missing
> this sentance and not realizing that the Spartan 3 pullups are
> different from the pullups on nearly every FPGA made by any vendor.

If engineers - myself included - are too lazy to RTFM, how _can_ a vendor 
forcefeed these professionals with the information that they *know* they'll 
need?

I'd be interested in the how.  Very interested in any effective means above 
and beyond the documentation.  If the PULLUPS and PULLDOWNs section is 2 or 
3 paragraphs, the last of which is a caution, how much more can be done?

With any complicated systems, the ability to communicate every nuance is 
hampered not by poor documentation as much as by the complexity.  Engineers 
are supposed to be doggedly detailed people.  If the datasheet isn't the 
first line of defense, what is?