Endianness

Comments and questions related to the "Down to the TLP" pages

Endianness

Postby Guest »

Eli,

According to the following paper, pcie is a little endian. In your blog it's big endian. Could you please clarify it?
http://www.intel.com/design/intarch/papers/endian.pdf

Thanks
Guest
 

Re: Endianness

Postby support »

Hi,

I'm not, of course, the author of that paper from 2004, and if I didn't miss anything, the only reference to PCI Express is in one of the tables.

PCI Express is big Endian as far as the transaction layer goes. This is important in particular when designating DMA addresses to a PCIe card.

Why it appears under little Endian in that specific document is beyond me.

Eli
support
 
Posts: 802
Joined:

Re: Endianness

Postby Guest »

Actually the PCIe spec only defines endianess for TLP headers (implicit as big) and configuration space (little).
Endianess for the data payload (and thus your memory bar or your DMA buffers) is defined by the designer of the EP. Mine is little endian, which is true i would assume for most of the devices.

The issue is a bit clarified in the 2.1 spec due to caveats with AtomicOp's (new in 2.1).

Regards Manfred
Guest
 

Re: Endianness

Postby support »

Hmmm... It really looks like Endianess is something one can get confused about forever. Anyhow, when discussing Endianess, the first question is always when it's going to be relevant.

The configuration space is indeed little Endian oriented, in the sense that multi-byted numeric values are organized so that the lower-addressed bytes have a smaller significance.

On the transaction layer level, the significance of which byte is where, relates to the byte enables, which signal which bytes in the beginning and the end of a burst are active in the data section. The mapping there is big Endian: Bit zero of any of the BE[3:0] vectors corresponds to byte zero in the DWord, which is related to bits [31:24] in the data packet.

Tricky is it, indeed.
support
 
Posts: 802
Joined:

Re: Endianness

Postby Guest »

eli wrote: byte zero in the DWord, which is related to bits [31:24] in the data packet.


This is not correct. The spec nowhere assigns the bytes inside a DWord of the payload to any specific bits. So assigning byte zero to bits [7:0] is also valid. Figure 2.6 in the 2.1 Spec (and newer) shows two samples for the FetchAdd OP (as it is an add the order matters of course), one for big enadian targets and one for little endian targets.
Guest
 

Re: Endianness

Postby support »

I have to admit that the atomic operations are beyond the scope of anything I'm doing, so I'm not so familiar with that.

And yes, it's true that the spec doesn't say anything about what happens in the data payload region, since it obviously doesn't care about its content. So the endpoint may reverse the bytes of the data payload (in fact, Altera's PCIe core in its Avalon-ST interface does that) and in that case bit 0 of Byte Enables will indeed correspond to bits [7:0].

We agree: There is no doubt that the endpoint logic is allowed to do whatever it wants when interfacing with the application logic. But if the endpoint just feeds the TLP through as it arrives from the data link layer with no specific manipulations, and it does so in 32 bit words, so that the bit field maps in the spec for the headers apply, then byte 0 is at [31:24], and bit 0 of BE corresponds to those bits. That's big Endian.
support
 
Posts: 802
Joined:

Re: Endianness

Postby Guest »

Agreed. I would assume that the TLP Interfaces of most PCIe cores does that. So big endian looks more native at first glance. But it is easy to swap the bytes at that interface.

Just a few lines from my PCIe completer: (TLP Interface is 16bit@125 MHz)
Code: Select all
// memory read  NOTE: Little endian host assumed
        4'b0111:
          begin
            tx_data[15:8] <= ReadData[7:0];
            tx_data[7:0]  <= ReadData[15:8];
            State      <= 4'b1000;
            DataLength    <= DataLength - 1;
          end
Guest
 


Return to General PCIe

cron