FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 11-12-2007, 04:04 PM
Andrew Greensted
Guest
 
Posts: n/a
Default Spartan3E Slave Serial Daisy chain

Hi All,

I've got three Spartan3Es daisy chained together in slave serial mode.
I'm attempting to configure the 3 devices from an Atmel AVR reading the
configuration from an SDCard.

The DONE line is not going high after all the data has been shifted. As
shown in the device datasheet, done is commoned and pulled high with a
330R resistor, so any of the devices could be holding done low.

Q1: Will the bitstream be forwarded to DOUT even if the FPGA thinks the
data it has recieved so far is invalid? At the moment DOUT is staying
high. (BTW, INIT_B stays high whilst the data is being shifted)

Q2: Is this the correct way to generate a binary file from 3 separate
bit files?
promgen -w -p bin -u 0 device1.bit device2.bit device3.bit -o array.bin

Q3: As for bit ordering, I'm pretty sure this is correct:
I'm reading the generated binary file (array.bin) 1 byte at a time and
shifting the MSB first. I'm also shifting some dummy data (DIN='1')
after the bitstream.

Q4: If one of the devices is holding DONE low, will it stop the others
from starting up?

Thanks for any help you can offer
Andy
Reply With Quote
  #2 (permalink)  
Old 11-12-2007, 04:27 PM
Gabor
Guest
 
Posts: n/a
Default Re: Spartan3E Slave Serial Daisy chain

On Nov 12, 11:04 am, Andrew Greensted <[email protected]> wrote:
> Hi All,
>
> I've got three Spartan3Es daisy chained together in slave serial mode.
> I'm attempting to configure the 3 devices from an Atmel AVR reading the
> configuration from an SDCard.
>
> The DONE line is not going high after all the data has been shifted. As
> shown in the device datasheet, done is commoned and pulled high with a
> 330R resistor, so any of the devices could be holding done low.
>
> Q1: Will the bitstream be forwarded to DOUT even if the FPGA thinks the
> data it has recieved so far is invalid? At the moment DOUT is staying
> high. (BTW, INIT_B stays high whilst the data is being shifted)
>
> Q2: Is this the correct way to generate a binary file from 3 separate
> bit files?
> promgen -w -p bin -u 0 device1.bit device2.bit device3.bit -o array.bin
>
> Q3: As for bit ordering, I'm pretty sure this is correct:
> I'm reading the generated binary file (array.bin) 1 byte at a time and
> shifting the MSB first. I'm also shifting some dummy data (DIN='1')
> after the bitstream.
>
> Q4: If one of the devices is holding DONE low, will it stop the others
> from starting up?
>
> Thanks for any help you can offer
> Andy



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

Reply With Quote
  #3 (permalink)  
Old 11-12-2007, 04:37 PM
Andrew Greensted
Guest
 
Posts: n/a
Default Re: Spartan3E Slave Serial Daisy chain

Gabor wrote:

> I seem to recall that "bin" files are actually ascii strings of 1's
> and 0's,


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
Reply With Quote
  #4 (permalink)  
Old 11-12-2007, 06:01 PM
John_H
Guest
 
Posts: n/a
Default Re: Spartan3E Slave Serial Daisy chain

"Andrew Greensted" <[email protected]> wrote in message
news:[email protected]
> Hi All,
>
> I've got three Spartan3Es daisy chained together in slave serial mode. I'm
> attempting to configure the 3 devices from an Atmel AVR reading the
> configuration from an SDCard.
>
> The DONE line is not going high after all the data has been shifted. As
> shown in the device datasheet, done is commoned and pulled high with a
> 330R resistor, so any of the devices could be holding done low.
>
> Q1: Will the bitstream be forwarded to DOUT even if the FPGA thinks the
> data it has recieved so far is invalid? At the moment DOUT is staying
> high. (BTW, INIT_B stays high whilst the data is being shifted)
>
> Q2: Is this the correct way to generate a binary file from 3 separate bit
> files?
> promgen -w -p bin -u 0 device1.bit device2.bit device3.bit -o array.bin
>
> Q3: As for bit ordering, I'm pretty sure this is correct:
> I'm reading the generated binary file (array.bin) 1 byte at a time and
> shifting the MSB first. I'm also shifting some dummy data (DIN='1') after
> the bitstream.
>
> Q4: If one of the devices is holding DONE low, will it stop the others
> from starting up?
>
> Thanks for any help you can offer
> 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


Reply With Quote
  #5 (permalink)  
Old 11-13-2007, 09:35 AM
Andrew Greensted
Guest
 
Posts: n/a
Default Re: Spartan3E Slave Serial Daisy chain

Andrew Greensted wrote:
> Q3: As for bit ordering, I'm pretty sure this is correct:
> I'm reading the generated binary file (array.bin) 1 byte at a time and
> shifting the MSB first. I'm also shifting some dummy data (DIN='1')
> after the bitstream.


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
Reply With Quote
  #6 (permalink)  
Old 11-13-2007, 04:25 PM
Gabor
Guest
 
Posts: n/a
Default Re: Spartan3E Slave Serial Daisy chain

On Nov 13, 4:35 am, Andrew Greensted <[email protected]> wrote:
> Andrew Greensted wrote:
> > Q3: As for bit ordering, I'm pretty sure this is correct:
> > I'm reading the generated binary file (array.bin) 1 byte at a time and
> > shifting the MSB first. I'm also shifting some dummy data (DIN='1')
> > after the bitstream.

>
> 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

Reply With Quote
  #7 (permalink)  
Old 11-13-2007, 04:47 PM
Andrew Greensted
Guest
 
Posts: n/a
Default Re: Spartan3E Slave Serial Daisy chain

Gabor wrote:

> This is interesting. What revision of iMpact/promgen are you using?


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
Reply With Quote
  #8 (permalink)  
Old 11-13-2007, 06:06 PM
John_H
Guest
 
Posts: n/a
Default Re: Spartan3E Slave Serial Daisy chain

"Gabor" <[email protected]> wrote in message
news:[email protected] ups.com...
>
> 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


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.


Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Spartan-3E Slave Serial Configuration Andrew Greensted FPGA 5 09-16-2007 10:28 AM
configuring in slave serial mode with serial platform PROM [email protected] FPGA 1 02-20-2007 05:20 PM
PROM files: build .bin for daisy chain on the fly [email protected] FPGA 3 07-11-2006 09:33 AM
Spartan IIE daisy chain problems Jerker Hammarberg \(DST\) FPGA 1 12-12-2003 06:13 PM


All times are GMT +1. The time now is 09:12 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved