Xilinx SelectMAP Question

Dear all,

I am configuring a Xilinx Spartan 3 using SelectMap (the parallel 
interface), although the simple details of this interface that I am 
interested apply to a number of other chips.  Having looked at as many 
datasheets, application notes and examples as I can find, I cannot 
answer a simple question: in what order are the bytes of a SelectMap 
configuration stream sent?

Ignoring bit-swapping within a byte, are the bytes forming the beginning 
of the stream (dummy word/sync word) sent as: 0xFF 0xFF 0xFF 0xFF 0xAA 
0x99 0x55 0x66 i.e. big-endian, or are they sent as 0xFF 0xFF 0xFF 0xFF 
0x66 0x55 0x99 0xAA i.e. little-endian?

Any help would be greatly appreciated.

TIA,

Peter

sent as aa 55 66 99

Antti

Antti wrote:
> sent as aa 55 66 99
> 
> Antti
> 
Thanks for your response, but I'm a little confused.  The data sheet 
specifies the sync dword as 0xAA995566, does that *really* get sent as 
AA 55 66 99?  i.e. byte0 byte2 byte3 byte1?  Or did you just mean to 
point out that the 0xAA is sent first, i.e. AA 99 55 66?

If the AA is sent first this makes things a little more tricky for me, 
as part of a reconfiguration stream passes through my device and I must 
calculate a CRC.  The CRC is calculated least significant bit first 
which means I must wait for a whole dword before being able to update my 
current CRC, rather than being able to update it on every byte.  This 
seems most inefficient.

Best,

Peter

Peter,
the spartan3 select map IF is 8 bit wide, as Antti said before, just 
send the bytes as they are coming from the *.bit file, 0xFF 0xFF 0xaa 
0x55 0x66 0x99 and so on...
about the CRC I'm not sure why you would want to calculate the CRC 
yourself, bitgen does this for you

Aurash

Peter Mendham wrote:
> Antti wrote:
> 
>> sent as aa 55 66 99
>>
>> Antti
>>
> Thanks for your response, but I'm a little confused.  The data sheet 
> specifies the sync dword as 0xAA995566, does that *really* get sent as 
> AA 55 66 99?  i.e. byte0 byte2 byte3 byte1?  Or did you just mean to 
> point out that the 0xAA is sent first, i.e. AA 99 55 66?
> 
> If the AA is sent first this makes things a little more tricky for me, 
> as part of a reconfiguration stream passes through my device and I must 
> calculate a CRC.  The CRC is calculated least significant bit first 
> which means I must wait for a whole dword before being able to update my 
> current CRC, rather than being able to update it on every byte.  This 
> seems most inefficient.
> 
> Best,
> 
> Peter

Peter,
One more thing, can you please point me to the document and page # where 
you find 0xAA995566 as sync word?
thanks,
Aurash


Aurelian Lazarut wrote:
> Peter,
> the spartan3 select map IF is 8 bit wide, as Antti said before, just 
> send the bytes as they are coming from the *.bit file, 0xFF 0xFF 0xaa 
> 0x55 0x66 0x99 and so on...
> about the CRC I'm not sure why you would want to calculate the CRC 
> yourself, bitgen does this for you
> 
> Aurash
> 
> Peter Mendham wrote:
> 
>> Antti wrote:
>>
>>> sent as aa 55 66 99
>>>
>>> Antti
>>>
>> Thanks for your response, but I'm a little confused.  The data sheet 
>> specifies the sync dword as 0xAA995566, does that *really* get sent as 
>> AA 55 66 99?  i.e. byte0 byte2 byte3 byte1?  Or did you just mean to 
>> point out that the 0xAA is sent first, i.e. AA 99 55 66?
>>
>> If the AA is sent first this makes things a little more tricky for me, 
>> as part of a reconfiguration stream passes through my device and I 
>> must calculate a CRC.  The CRC is calculated least significant bit 
>> first which means I must wait for a whole dword before being able to 
>> update my current CRC, rather than being able to update it on every 
>> byte.  This seems most inefficient.
>>
>> Best,
>>
>> Peter

Hi Peter,

AFSIK the syncword is not included in the bitstream CRC calculation.
Only the commands and  data sections are included in calculation.

Regards

Jens

Aurelian Lazarut schrieb:

> Peter,
> the spartan3 select map IF is 8 bit wide, as Antti said before, just
> send the bytes as they are coming from the *.bit file, 0xFF 0xFF 0xaa
> 0x55 0x66 0x99 and so on...
> about the CRC I'm not sure why you would want to calculate the CRC
> yourself, bitgen does this for you
>
> Aurash
>
> Peter Mendham wrote:
> > Antti wrote:
> >
> >> sent as aa 55 66 99
> >>
> >> Antti
> >>
> > Thanks for your response, but I'm a little confused.  The data sheet
> > specifies the sync dword as 0xAA995566, does that *really* get sent as
> > AA 55 66 99?  i.e. byte0 byte2 byte3 byte1?  Or did you just mean to
> > point out that the 0xAA is sent first, i.e. AA 99 55 66?
> >
> > If the AA is sent first this makes things a little more tricky for me,
> > as part of a reconfiguration stream passes through my device and I must
> > calculate a CRC.  The CRC is calculated least significant bit first
> > which means I must wait for a whole dword before being able to update my
> > current CRC, rather than being able to update it on every byte.  This
> > seems most inefficient.
> > 
> > Best,
> > 
> > Peter

its an active document, called HEX viewer.
on my PC it is the "F4" - I am using winXP mainly as a way to start
multiply copies of FAR (clone of norton commander)
so on my PC I select any xilinx .BIT file, press F4, and I see the 0xAA
... :)

Antti
PS sure the sync and all other details of the xilinx bitstream are
documented in xilinx datasheets as well.

included in CRC are
1) data to be written 32 bits
2) addr of target register 4 or 5 bits depending on family

data stream sent to LOUT register is not included

Antti

Aurelian Lazarut wrote:
> Peter,
> One more thing, can you please point me to the document and page # where 
> you find 0xAA995566 as sync word?
> thanks,
> Aurash

Aurash,

XAPP452 "Spartan-3 Advance Configuration Architecture", p. 11
XAPP151 "Virtex Series Configuration Architecture User Guide", p. 27
(I know this is not for the S3 but the interface is so similar and it 
documents many things XAPP452 doesn't)

A hex inspection of any bit file will also bring up the same data.

Similarly, is there any chance that you, or anyone else, can point me to 
a reference which confirms this byte ordering (i.e. MSB first)?  I'm 
clearly missing something obvious.

Thanks to all who have replied on this topic,

Peter

Hi Peter,

dont push xilinx again on documentation too hard - it is as it is - the
bytes appear in bytewide config stream in the order they are in the
.BIT file, also the bits are sent out MSBit first, eg if you write the
.BIT file as continous file onto MMC/SD card, and then read the card
sector per sector clocking CCLK on each databit then FPGA does get
configured. Similarly you can just copy .BIT file into SPI flash and
read out the image (and copy to DIN/CCL) and it works and configures
the FPGA.

Well if you have multiply FPGAs in serial chain then you need to run
promgen (to insert second bitstream as LOUT stream), promgen reverses
bits (when XCF is target) then to get programming file for SPI flash
(chained config) the output of promgen needs to have bitreversing
applied.

I was really surprised and frustrated when trying to load 2 FPGA's from
SPI flash, no matter the settings the best result (without using LOUT
stream) was that both FPGAs did get configured DONE=1 but on the second
FPGA GHIGH was not activated (FPGA not released from config) the first
FPGA started well. I still dont understand completly why it was like
that, but using promgen (to 'insert' the slave stream inside the master
bitstreams LOUT frame) fixed the issue. I had to write my own
bitreverse to fix the output of promgen though.

Antti