Spartan 3A startup

[Jon Elson]

So, after being assured Spartan 3A should be around for a while
(Thanks, all who commented) I made a board for a Spartan XC3S50A
in the 144 lead package. I am using an SST25VF010A serial SPI
PROM for configuration. I have my own reset monitor to drive
the PROG-B/ pin, and that seems to be working correctly.
I have it set for the master SPI mode, with M<2:0> set
for 001 and VS<2:0> set for 101 as the Xilinx config doc
says to do.

But, at power-on, I don't get any configuration activity.
What I see is short positive pulses on all the pins connected to the
serial PROM, and then they go Hi-Z and fall slowly back to zero.
This repeats at about a 1 second rate. Manually triggering
the PROG_B/ doesn't seem to do anything. I have left INIT_B
open, is this right?

The config document for SPI shows some greyed-out resistors,
with no explanation in the text that I can find about what
they are for or whether they are needed. I know Spartan 2E
needed a 3.3K pull-up on the INIT pin.

So, any from the trenches experience with SPI configuration of
a Spartan 3A would be greatly appreciated!

Thanks,

Jon

 

[Jon Elson]

Jon Elson wrote:

OOps, I think I found at least the first goof. I forgot to hook
up VCCAUX! I thought it was for special voltage output drivers,
but not so.

Jon

 

[Jon Elson]

Jon Elson wrote:

OOps, I think I found at least the first goof. I forgot to hook
up VCCAUX!
Ah, that helped a lot! Next problem turned out to be that the

bit ordering of an MCS file is reversed for Xilinx or SPI
EPROM chips in the file. When I selected the PROM formatter
to make Xilinx EPROM files instead of SPI, the FPGA accepted
the configuration. It now is doing things that look right on
a scope, but it doesn't seem to be communicating with the
test computer. I'll probably have to hook up the logic
analyzer to see where it is going wrong.

Jon

 

[Gabor]

Jon Elson wrote:

So, after being assured Spartan 3A should be around for a while
(Thanks, all who commented) I made a board for a Spartan XC3S50A
in the 144 lead package. I am using an SST25VF010A serial SPI
PROM for configuration. I have my own reset monitor to drive
the PROG-B/ pin, and that seems to be working correctly.
I have it set for the master SPI mode, with M<2:0> set
for 001 and VS<2:0> set for 101 as the Xilinx config doc
says to do.

But, at power-on, I don't get any configuration activity.
What I see is short positive pulses on all the pins connected to the
serial PROM, and then they go Hi-Z and fall slowly back to zero.
This repeats at about a 1 second rate. Manually triggering
the PROG_B/ doesn't seem to do anything. I have left INIT_B
open, is this right?

The config document for SPI shows some greyed-out resistors,
with no explanation in the text that I can find about what
they are for or whether they are needed. I know Spartan 2E
needed a 3.3K pull-up on the INIT pin.

So, any from the trenches experience with SPI configuration of
a Spartan 3A would be greatly appreciated!

Thanks,

Jon

Even before reading your next post I suspected a power issue. Also

INIT_B should be pulled up. If it has an internal pullup, that might
be OK, but the configuration process will be delayed if INIT_B
stays low after releasing PROGRAM_B, so I usually add an external
pullup anyway.

-- Gabor

 

[Jon Elson]

Gabor wrote:

Even before reading your next post I suspected a power issue. Also
INIT_B should be pulled up. If it has an internal pullup, that might
be OK, but the configuration process will be delayed if INIT_B
stays low after releasing PROGRAM_B, so I usually add an external
pullup anyway.
Yes, this once per second pulsing really had to be either power

or some floating pin. I'm pretty sure INIT_B does have internal
pullup, but I'll double check the docs. Extra-fast config is
not required, here, it just needs to be finished before the PC
boots.

Anyway, found another goof, I had failed to solder one whole row
of pins on one of the voltage translator chips! Now the
board is communicating with the PC, and some preliminary tests
all look OK. I couldn't figure out how it could have been so
far off, as the VHDL is almost identical to the Spartan 2E
version. The UCF pad assignment was the only real change,
so I was looking for a mis-assignment of one wrong pin
and not thinking as globally as I should have.

Jon