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

Reply to
Peter Mendham
Loading thread data ...

sent as aa 55 66 99

Antti

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

Reply to
Peter Mendham

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:

Reply to
Aurelian Lazarut

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:

Reply to
Aurelian Lazarut

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:

Reply to
jenze

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.

Reply to
Antti

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

Reply to
Antti

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

Reply to
Peter Mendham

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

Reply to
Antti

Peter, I apolgise the corect sync word is 0xAA 0x99 0x55 0x66 the docs are correct. you need to send the bytes in this order (from left to right) at your select map interface. MSB to MSB (NSB bit from the bytes from file to D7 at fpga)

Aurash

Peter Mendham wrote:

Reply to
Aurelian Lazarut

Antti I think it's 0xaa 0x99 0x66 0x66 (typo?) Aurash

Reply to
Aurelian Lazarut

I meant 0xaa 0x99 0x55 0x66 (yes typo, friday evening) Aurash

Reply to
Aurelian Lazarut

So, what happens with 3 FPGAs from a SPI stream ?

-jg

Reply to
Jim Granville

not quite sure, I guess promgen inserts 3rd one into LOUT of the second one, and that combined bistream into LOUT of the first one. But I have not dealt with such configs. BTW its the same if SPI flash or normal fpga serial flash

Antti

Reply to
Antti Lukats

Fantastic, thanks for the confirmation.

Peter.

Reply to
Peter Mendham

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.