Confusion about configuring Spartan 6 with cypress EZ-USB FX2 CY7C68013A

I am trying to design a PCB with Spartan 6 FT(G)256 Package and it will be configured by EZ-USB FX2 CY7C68013A. The configuration mode will be Microprocessor-Driven SelectMAP Configuration, as shown in the attached image and what is described in the following document:
https://www.xilinx.com/support/documentation/user_guides/ug380.pdf
My confusion is about the data bus connection. On FX2 side, the data bus is FD[15..0], on Spartan 6 side, the data bus is D[15..0]. As you know, D0 is the pin IO_L3P_D0_DIN_MISO_MISO1_2, D1 is the pin IO_L12P_D1_MISO2_2, D2 the pin IO_L12N_D2_MISO3_2 ..... D15 is the pin IO_L31N_GCLK30_D15_2. I take it for granted that data pin on FX2 side should be connected to the data pin on Spartan 6 side which is at the same position in the data bus of Spartan 6. That is to say, FD0 of FX2 should be connected to D0 of Spartan 6, FD1 of FX2 to D1of Spartan 6, FD2 to D2, FD3 to D3......FD15 to D15. This is my understanding.
I have an similar PCB of earlier version designed by other people, which is my design reference at the moment. On that PCB, all other signals required in the configuration are the same apart from the data bus connection. On that PCB, FD0 of FX2 was connected to D12 of Spartan 6, FD1 of FX2 connected to D11 of Spartan 6, FD2 to D0, FD3 to D10, FD4 to D4, FD5 to D6,FD7 to D1, FD8 to D13, FD9 to D14, FD10 to D15, FD11 to D8, FD12 to D9, FD13 to D4, FD14 to D7, FD15 to D3. You can see, it looks that the data lines are connected in a messy corresponding sequence. But what makes me very confused is that PCB still works! Programming the Spartan 6 through FX2 has always been successful. It should not have been working. Could anybody please explain to me why this messy connection sequence still works in the configuration of Spartan 6? I can connect FD0 to D0, FD1 to D1....FD15 to D15, but the design on that reference board really makes me confused. Is there anything I missed in understanding this?

It's probably being bit manipulated in that Cypress USB microcontroller code. Based on the datasheet it has an 8051 embedded in it and the code is run from RAM, EEPROM, or an external memory device.

I'd wager that the original board designer let the PCB layout person to pin swap on that bus to make routing easier. I'd also wager the firmware engineer who wrote the 8051 code for the CY7C68013A probably wanted to see both the board designer and the PCB layout people hung.

This is a case where it shows how poorly some things are designed (i.e. they aren't designed, the people involved got lucky because it could be fixed in firmware code). Also shows how many "engineers" (using the term loosely in this case) are horrible at documentation. If nothing else this screwed up pin assignment should have been noted somewhere obvious (e.g. on the schematic, in the design docs for the board, etc). Of course that means you would have to own up to having screwed up, and most people have too big of an ego to admit that. :thumbsdown:

My recommendation, hook it up with the screwed up pinout (if you are going to use the exact same USB controller with the same embedded software), otherwise if the code is going to be modified or rewritten for a different USB controller, ask (nicely) the software engineer responsible for that part to remove that bit manipulating code and use the bits directly. They will probably thank you for the extra clock cycles or for clearing up why that code even existed in the first place.

Hi ads-ee,

Thank you for reminding me this. Indeed, the FPGA configuration stream was bit shuffled in the application software. It took me ages as a hardware engineer to dig into the software to find out how the bit sequence was manipulated at that time, all down to the poor documentation. Best regards.