Support for mstatus MBE, SBE

[MuhammadHammad001]

Hi
I am currently writing the test for little and big endianess in the virtual memory verification.
I was trying to write the mstatush.SBE to enable big endianess for loads/stores but I am unable to do so.

mem[X,0x80000A98] -> 0xA073
mem[X,0x80000A9A] -> 0x3102
[643] [M]: 0x80000A98 (0x3102A073) csrrs zero, 0x310, t0
CSR 0x310 -> 0x00000000
CSR 0x310 <- 0x00000000 (input: 0x00000010)

I went through the sail code to figure out what is wrong and I saw the following comment here:

  /* We don't currently support changing MBE and SBE. */
  if xlen == 64 then {
    Mk_Mstatus([m.bits with 37 .. 36 = 0b00])
  } else m
}

Is there any plan to add the support for this or am I missing something?

[Timmmm]

No plans but you're welcome to add support if you like. Do you know of actual users of this feature? I mean does any hardware actually exist that implements it?

[jordancarlin]

The OpenHWGroup CVW core implements support for switching endian modes using MBE/SBE. Would be a great feature to get into the Sail model eventually, but I don't think it's been that high on anyone's priority list.

[Timmmm]

Has anyone actually taped it out with support for big endian though? Kind of feels like CVW is trying to support every feature of RISC-V regardless of whether anyone wants it (which is fine), and I would be mildly surprised if anyone really wants big endian! I guess someone asked for it though; the spec says it was added to support legacy code.

Anyway feel free to try. It might not be too invasive; you probably just need to modify mem_read_priv_meta and mem_write_value_priv_meta to swap the bytes (unless Typ is Execute).

It may interact awkwardly with #49 - maybe have a skim of Alasdair's PR there before doing anything.

[jordancarlin]

You're not wrong that CVW is trying to support most RISC-V features in at least one of its configurations. I'm pretty sure the configuration being used for an upcoming tapeout has big endian supported though.

I might look at adding endian support down the road, but probably won't get around to it for a while so if you're interested feel free @MuhammadHammad001.

[MuhammadHammad001]

@Timmmm @jordancarlin Sure, I can work on this

[allenjbaum]

Big Endian is there for a reason: there are other architectures that work that way, and this greatly reduces porting effort for SW. This is important for the Japanese market, I believe, and probably networking markets as well. Having said that: I am unaware of implementations that allow this (either as a static -always big Endian - or a dynamic setting.

…

On Tue, Dec 3, 2024 at 4:58 AM Tim Hutt ***@***.***> wrote: Has anyone actually taped it out with support for big endian though? Kind of feels like CVW is trying to support every feature of RISC-V regardless of whether anyone wants it (which is fine), and I would be mildly surprised if anyone really wants big endian! I guess someone asked for it though; the spec says it was added to support legacy code. Anyway feel free to try. It might not be too invasive; you probably just need to modify mem_read_priv_meta and mem_write_value_priv_meta to swap the bytes (unless Typ is Execute). It may interact awkwardly with #49 <#49> - maybe have a skim of Alasdair's PR there before doing anything. — Reply to this email directly, view it on GitHub <#632 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJQ7NJAZVRO3H5NS2ML2DWTGVAVCNFSM6AAAAABS4MNBIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJUGQ4TEOBWGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>