OpenRISC 1000

incorrect short/word access (030rc3) #52

Closed swaka opened this issue about 15 years ago

Hi, I checked the latest or1ksim. It seems to change the behavior from big-endian to host-endian. In my environment (host-endian : little ),

byte access is correct But half word/ word accesses are incorrect. Could you check the behavior using logger_test example? Writing half word 0xbeef to address 0x090000002 Data: 0xefbe0000 ( should be 0xbeaf0000 ) Writing full word 0xdeadbeef to address 0x090000004 Data: 0xefbeadde ( should be 0xdeadbeaf )

Regards, swaka

Hi Swaka, Thanks for the feedback. 0.3.0rc3 has made the upcall interface explicitly host-endian. I realized that previously it was a mixture of host-endian and model-endian (cause of the bug you reported earlier). This is consistent with OSCI TLM 2.0, which specifies that transaction payloads are host-endian. The models at each end are responsible for conversion between model- and host-endianness. You'll see that the code in generic.c now includes functions mtohl, mtohs, htoml and htoms to perform these conversions explicitly. I will check the logger example, to make sure I have got this correct. I may need to update the logger example.

Hi,

In the case of current or1ksim implementation, In target model, user cannot use a following style. unsigned int data = (unsigned int)payload.get_data_ptr(); target model has to do byte swap for half/word access.

embecosm-esp1-sysc-tlm2.0-examples-1.2 only uses UART models as SystemC model. So this problem does not occur. UART model does not use above cast and half/word access. But this issue always occurs for models with half/word access. Could you check?

Hi Swaka, You are correct, but it is intentional. I anticipate the main use of the upcalls will be to build SystemC interfaces. OSCI TLM 2.0 is explicit that payloads use host-endianism (section 6.17.2 (e)). This is a change from earlier. My original implementation was muddled over endianness. The new implementation adds a small level of inconvenience in the example you quote, but the advantage is that the interface is unambiguous. I recommend that any modeler should have htoml, htoms, mtohl and mtohs functions. TLM 2.0 also provides helper functions to determine host endianess. As you note, this does not matter for UART which is only byte addressed anyway. It does mean the Logger example from the application note shows the wrong output on an Intel machine. Default ORPSoC is big endian, while Intel PCs are little endian. So the correct output should be: Writing byte 0xa5 to address 0x090000000 Logging Command: Write Address: 0x90000000 Byte enables: 0x000000ff Data: 0x000000a5 Writing half word 0xbeef to address 0x090000002 Logging Command: Write Address: 0x90000000 Byte enables: 0xffff0000 Data: 0xefbe0000 Writing full word 0xdeadbeef to address 0x090000004 Logging Command: Write Address: 0x90000004 Byte enables: 0xffffffff Data: 0xefbeadde Logging Command: Read Address: 0x90000000 Byte enables: 0x000000ff Read byte 0x0FF from address 0x090000000 Logging Command: Read Address: 0x90000000 Byte enables: 0xffff0000 Logging Command: Read Address: 0x90000004 Byte enables: 0xffffffff Read full word 0x084690508 from address 0x090000004 exit(0) @reset : cycles 0, insn #0 @exit : cycles 28147, insn #14490 diff : cycles 28147, insn #14490 I believe this is no work to be done on this, so I'm marking the issue closed.

jeremybennett was assigned about 15 years ago

jeremybennett closed this about 15 years ago

Assignee

jeremybennett

Labels

Bug

Browse

OpenRISC 1000