Spartan3E Slave Serial Daisy chain

I seem to recall that "bin" files are actually ascii strings of 1's and 0's, not actual binaries. Take a look at your files and see if the size seems to approximately match the sum of the .bit files (which are raw binaries with a header) or if they're about 8 times too big. In the past I have always used the raw hex format to create a file that is about twice the size of a raw binary (two ascii hex characters per byte with no other formatting). Then I convert that to binary with a simple C program and use the output for embedded programming. My promgen looks like:

promgen -w -p hex -b -c FF -o outfile -u 0 first.bit second.bit

Regards, Gabor

Hi Gabor, The ascii file (with 1s and 0s in text) is the .rbt. I'm pretty sure that the .bin is the binary bitsream. Andy

I use the GUI to generate my programming files. There are two styles of .bin files that can be generated through the GUI - one is MSbit first, the other is byte-reversed for LSbit first. My recollection is that the DOUT will only pass data once the first device is programmed so your file order will be from the first device to the last. If the DOUT on the first device never changes, assume the first programming file is bad and troubleshoot that situation first. If the first device programms bot the others don't, insert a couple hundred cycles of logic-1 data between the files.

If you want to try both auto-generated .bin files through the Xilinx GUI, one is generated from the Generate Programming File property "Create Binary Configuration File" and the other by using the IMPACT tool directly through the Generate PROM, ACE, or JTAG File under the Generate Programming File process. If you "Prepare a PROM File" you get the option to generate a BIN Prom File Format. It's this .bin file that has the bits reversed in the byte relative to the promgen version.

The low DONE shouldn't keep the other devices from programming. The DOUT stuck high should keep the other devices from programming.

- John_H

Well, I was sure I had the bit ordering right, but it would seem not!!! Shifting in the LSB first, on a byte-by-byte basis made is work.

So just in case any one else has the same problem in the future:

I've got 3 Spartan3E XC3S500E in slave serial mode daisy-chained together. I'm using an Atmel AVR (ATMega644) running at 3.3V with a 10MHz clock. (The bit file is held on an SDCard)

The slave serial controls are connected to the AVR.

DOUT (from fpga 3) is input to the AVR DIN (to fpga 1) is output from the AVR DONE is input to the AVR CCLK is output from the AVR INIT_B is input to the AVR PROG_B is output from the AVR

For the Spartan3E, all signals apart from the PROG_B are 3.3V tolerant, so these can be connected directly to the AVR.

DONE is 2.5V high, but the AVR should read this as a '1' (Just with a lower noise threshold)

PROG_B needs to be 2.5V high, so it needs some kind of level translation, I used a SN74LVC1G07DCK (Farnell 128-7544). It's an open drain driver. use this with a 4.7k

All FPGA DONE signals are common (with a 330R pull-up) All PROG_B signals are common (with a 4.7k pull-up) All INIT_B signals are common (with a 4.7k pull-up)

A binary file is created using the following command: promgen -w -p bin -u 0 device1.bit device2.bit device3.bit -o array.bin

It is loaded like this:

for each byte in the bin file

// Get byte byte = next byte from bin file;

// Iterate through each bit for each bit 0 to 7

// If bit=1 set DATA high (Keep PROG_B high during config) if (byte & 0x01) data = PROG_B | DATA_AVR2FPGA; else data = PROG_B;

// output data output data;

// set CCLK high data = data | CCLK;

// output data and CCLK output data;

byte >>= 1;

end for

end for

Hope all that helps someone Andy

This is interesting. What revision of iMpact/promgen are you using? I have seen issues with version 8.x where the bits are swapped for .hex file outputs even if you un-check the box for swap bits. This was in fact why i was using promgen from the command line for creating my .hex files rather than the iMpact GUI. I haven't tried the .bin file output option, though. Perhaps if you look deep enough into the documents you'll find that the .bin option also defaults to swapped bits?

Regards, Gabor

Its ISE version 9.1 (With SP3).

Yes, I have to admit, I'm confused too. I used the .rbt (ASCII 1s and

0s) file to check the bit ordering. I assumed this would be created with the bits ordered in the sequence they should be shifted in the chain. I was sure I was reading the bin file to replicated this.

Hey ho, its working now

Andy

I mentioned before: promgen produces one bit order, Impact produces another. There's an option to generate a .bin file for the main program file implementation "tab" as well as a "BIN" output format for the Impact project. These two files are bit-reversed within a byte.