(iomshr) address check to determine io has bug?

[beatsnbytes]

Hello,

I am working on the untethered version 0.2 and I discovered a possible bug in the chisel code at the file (uncore/src/main/scala/iospace.scala). To be more specific at the end of the code there is there is a snippet of code checking if the address provided belongs to IO or not. The piece of logic used there is the same one that you can find on the LowRisc webpage "For any address (addr), it belongs to a memory section if *(addr & ~io_mask) == io_base." However this logic is not correct. I will give you a clarifying example. io_base = 0x10000000 (32bit) io_mask = 0x3fffffff --> ~io_mask = 0xc0000000

Now lets forget about the 28 LSBs of our address since whatever we and with zero will give us zero as a result. Let us focus on the 4 MSBs :
addr 0 0 0 ? &
io_mask 1 1 0 0 (equals)
io_base 0 0 0 1

Evidently this logical operation cannot has no solution i.e no address can make it true. Yet, it should hold true for addresses that their 4 MSBs are (0001, 0010, 0011, 0100).

To sum up. Is this the expected behavior of the io address checking mechanism and if yes, am I missing any limitation on the address space mapping? Is this corrected on the next releases? I couldn't tell if this behavior persists because, and correct me if I am wrong, the logic of accessiong the IO has changed in the next releases.

Thank you a lot in advance. Best, Vatistas

[jrrk]

It would only work for a limited (but still useful) subset of address, such as (for DDR)

mem_base = 0x80000000

mem_mask = 0x7FFFFFF

addr = 0x84000000 (for example):

belongs = 0x84000000 & 0xF8000000 == 0x80000000 (true)

We are no longer actively addressing this old release. If you features that you rely on from this release, that are not in the v0.6 release,

we can consider reimplementing them for a future release.

On 18/02/2019 10:40, Koba wrote:

Hello,

I am working on the untethered version 0.2 and I discovered a possible bug in the chisel code at the file (uncore/src/main/scala/iospace.scala). To be more specific at the end of the code there is there is a snippet of code checking if the address provided belongs to IO or not. The piece of logic used there is the same one that you can find on the LowRisc webpage "/For any address (addr), it belongs to a memory section if/ (addr & ~mem_mask) == mem_base." However this logic is not correct. I will give you a clarifying example. mem_base = 0x10000000 (32bit) mem_mask = 0x3fffffff --> ~mem_mask = 0xc0000000

Now lets forget about the 28 LSBs of our address since whatever we and with zero will give us zero as a result. Let us focus on the 4 MSBs : addr 0 0 0 ? & mem_mask 1 1 0 0 (equals) mem_base 0 0 0 1

Evidently this logical operation cannot has no solution i.e no address can make it true. Yet, it should hold true for addresses that their 4 MSBs are (0001, 0010, 0011, 0100).

To sum up. Is this the expected behavior of the io address checking mechanism and if yes, am I missing any limitation on the address space mapping? Is this corrected on the next releases? I couldn't tell if this behavior persists because, and correct me if I am wrong, the logic of accessiong the IO has changed in the next releases.

Thank you a lot in advance. Best, Vatistas

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/104, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF19JbSKIrkvYLSLdtqN5cfzxWIS5_ks5vOoMogaJpZM4bAk_n.

[beatsnbytes]

Well, I see. As part of an experiment,I am trying to map the whole address space to IO space (by nulling the memory space). I am not aware of any implications that, this approach might had, but my very first step was to alter the memory map. And then I encountered the above mentioned issue. As far as I understand in order to overcome this limitation I should change the logic that raises the flag of IO addresses (is_IO) to take into account the addresses that it should (from BASE to BASE+MASK). Is there something that would prevent this endeavour?

Best, Vatistas

[jrrk]

An obvious problem is that IO space is not executable so there will be nowhere to put your program.

But lowRISC isn't really meant for that, the aim is to try and help the user to get something working out of the box.

If you just want to experiment with the performance of different kinds of interface, just start from the latest Rocket

project and customise it with the number of interfaces wanted, size, width and whether cachable, executable etc.

On 18/02/2019 14:28, Koba wrote:

Well, I see. As part of an experiment,I am trying to map the whole address space to IO space (by nulling the memory space). I am not aware of any implications that, this approach might had, but my very first step was to alter the memory map. And then I encountered the above mentioned issue. As far as I understand in order to overcome this limitation I should change the logic that raises the flag of IO addresses (is_IO) to take into account the addresses that it should (from BASE to BASE+MASK). Is there something that would prevent this endeavour?

Best, Vatistas

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/104#issuecomment-464750850, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF17n_8w5z4yIHzByDdo9yq6H3tz3Oks5vOrihgaJpZM4bAk_n.

[beatsnbytes]

Great, Thank you for the feedback. Indeed that would prove to be a serious obstacle. Thank you also for the suggestions. Have a nice day!