TLM2 endianness rules

[rahuljn]

Hi Guys

In TLM2 LRM, under section 14.18.2, I am not fully understand the following points

Rule i) The effective word length shall be calculated as (BUSWIDTH + 7)/8 bytes.

>> from where this expression comes from and why we have additional 7 in this expression.

Rule i) initiators and targets are connected LSB-to-LSB, MSB-to-MSB.

>> does it mean we direct connect the ports regardless to their endianness and host endianness.

Can you please help me to understand these.

Thanks

Rahul

[apfitch]

In the first example - the +7 just makes sure you have enough bytes to hold all the bits. E.g. suppose I have 32 bits then I need 4 bytes - but if I have 33 bits, I need 5 bytes. By adding 7 it works correctly

 

(32+7)/8 = 4

(33+7)/8  = 5

 

etc.

 

Regarding the second rule, the easiest way to visualize it is to think of a real bus. A real bus just consists of a set of wires. You need to specify what order the wires are connected, but you don't know anything about the endianness of the data that is transferred across the bus. So that second rule is saying that if you model 32 wires using a 32 bit socket, wire 0 should be connected to wire 0, wire 1 to wire 1, and so on.

 

The interpretation of endianness lies in the initiators and targets, not in the bus itself (if you see what I mean!)

 

regards

Alan

[Zdenek Prikryl]

Hi Alan,

Following Rahul's post, I have one more question. You mentioned that the interpretation lies in the initiators and targets. So, let's have two  initiations (one big, one little) and a bus word has 4 bytes. The target (memory for instance) doesn't allow an unaligned access (address requests have to be: 0, 4, 8, ...). What should the initiations put into payloads when there is a half-word access at an unaligned address?

 

For instance, an initiator wants to write 0xaabb to address 2 (address request goes to 0), Should the data and byte_enable fields of a payload be as follow?

 

• Little endian initiator
  
  data[0] == 0x00      (address offset +0)
  data[1] == 0x00      (address offset +1)
  data[2] == 0xbb    (address offset +2)
  data[3] == 0xaa     (address offset +3)
  
  byte_enable[0] = 0x00
  byte_enable[1] = 0x00
  byte_enable[2] = 0xff
  byte_enable[3] = 0xff
   
• Big Endian initiator
  
  data[0] == 0xbb        (address offset +3)
  data[1] == 0xaa        (address offset +2)
  data[2] == 0xaa         (address offset +1)
  data[3] == 0xbb         (address offset +0)
  
  byte_enable[0] = 0xff
  byte_enable[1] = 0xff
  byte_enable[2] = 0x00
  byte_enable[3] = 0x00

Is this a correct interpretation of endianness in the little/big initiator (assuming little endian host)?

 

Thanks.

[apfitch]

I believe that's correct - though I always find endianness very confusing!

There are examples on page 489 of the LRM which might help,

 

regards

Alan

[Zdenek Prikryl]

Hi Alan,

Thanks, one more question. LRM page 492 says:

 

In summary, the approach to be taken with the hostendian conversion functions is to write the initiator code
as if the endianness of the host computer matched the endianness of the component being modeled, while
keeping the bytes within each data word in actual host-endian order. For data words wider than the host
machine word length, use an array in host-endian order. Then if host endianness differs from modeled
endianness, simply call the hostendian conversion functions.
 

My understanding is that an initiator creates a payload (like described above) and then calls to_host_endianness() helper function to be able to send the payload in the hostendian form. When the payload arrives to a target then the target calls from_host_endianness() helper function and it obtains the payload in the correct form. In fact, using this approach, all communication outside of the initiators/targets is handled in the hostendian form, only internal parts of initiators and targets switches bytes in the payload when necessary.

[apfitch]

That sounds correct,

Alan