Sparten-IIE Configuration (Slave Parallel Mode)

[Christian Zander]

Hello,

I spent some time experimenting with the Parallel Slave Mode
configuration procedure available in the Spartan-IIE to
configure an XC2S300E over the parallel port; the motivation
was to use the same interface for configuration and, after
startup, for external communication during normal operation.

I'm using a CPLD to generate the necessary signals from the
IEEE1284 compatibility mode handshake and this is working just
fine, but I'd like to follow up on the behavior I observed.

If I understand the datasheet correctly, the FPGA expects the
user to load the complete bitstream before deasserting the /CS
and /WRITE signals, and then procedes to the CRC check. From
what I've seen, this doesn't appear to be the case; the device
drives DONE high after only 234448 of the documented 234456
configuration bytes are loaded; I'm assuming that I simply did
not understand the datasheet correctly with respect to /WRITE
and /CS, but why does the configuration complete early?

Thanks,

 

[Andras Tantos]

Hello,

I spent some time experimenting with the Parallel Slave Mode
configuration procedure available in the Spartan-IIE to
configure an XC2S300E over the parallel port; the motivation
was to use the same interface for configuration and, after
startup, for external communication during normal operation.

I'm using a CPLD to generate the necessary signals from the
IEEE1284 compatibility mode handshake and this is working just
fine, but I'd like to follow up on the behavior I observed.

If I understand the datasheet correctly, the FPGA expects the
user to load the complete bitstream before deasserting the /CS
and /WRITE signals, and then procedes to the CRC check. From
what I've seen, this doesn't appear to be the case; the device
drives DONE high after only 234448 of the documented 234456
configuration bytes are loaded; I'm assuming that I simply did
not understand the datasheet correctly with respect to /WRITE
and /CS, but why does the configuration complete early?

I've done the (fairly) same thing but without a CPLD: the download is slower
since you can't use EPP mode but that's not a big deal for me. I'm
experiencing the same: the bit stream is longer than the FPGA actually
wants. Also, make sure you read the APP notes on 5V compatibility of the
Spartant2E series and that the clock you use is clean enough. That can cause
a lot of programming problems.

Regards,
Andras Tantos

 

[Christian Zander]

I've done the (fairly) same thing but without a CPLD: the download
is slower since you can't use EPP mode but that's not a big deal
for me. I'm experiencing the same: the bit stream is longer than
the FPGA actually wants. Also, make sure you read the APP notes on
5V compatibility of the Spartant2E series and that the clock you
use is clean enough. That can cause a lot of programming problems.

The original plan was to just use some of the control lines to drive
/PROGRAM, CCLK, /CS and /WRITE, as well as status lines to monitor
/INIT and DONE, likely the cheapest solution; I was also just going
to fiddle the parallel port signals manually to get data to and from
the device after configuration.

I changed my mind after doing some reading on IEEE1284 and the modes
it offers; EPP is simple and hosts implement it in hardware, making
it a good choice. The idea then was to use compatibility mode writes
to configure the device with a CPLD to coordinate the handshake(s);
with the configuration done, I was going to let the CPLD "disappear"
from the status lines, allowing the FPGA to take over.

This works fine, with the exception that the configuration completes
early. Since the CPLD seems to fit enough logic for an IEEE1284
compliant peripheral, I'll probably move all parallel port handling
there for good, though.

At first, things didn't work quite right since DONE was going high
before I expected it; as described, it did so before I finished the
bitstream download, before I got a chance to deassert /CS and /WRITE
and, lastly, before the FPGA finished its startup sequence. Because
of this, the last two CCLK transitions were missing. While it was
frustrating for a little while, it motivated me to check the clocks
and relevant signals for noise, but they were/are all fine.

In terms of 5V tolerance and dealing with the parallel port itself,
I decided to play safe, a 19bit IEEE1284 bus interface takes care of
the details; its peripheral side operates on 3.3V.

Thanks,