[libre-riscv-dev] [Bug 377] New: possible bug in Simulator Mem ld/st function

[libre-riscv-dev] [Bug 377] New: possible bug in Simulator Mem ld/st function

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=377

            Bug ID: 377
           Summary: possible bug in Simulator Mem ld/st function
           Product: Libre-SOC's first SoC
           Version: unspecified
          Hardware: PC
                OS: Mac OS
            Status: CONFIRMED
          Severity: enhancement
          Priority: ---
         Component: Source Code
          Assignee: lkcl@lkcl.net
          Reporter: lkcl@lkcl.net
                CC: libre-riscv-dev@lists.libre-riscv.org
   NLnet milestone: ---

michael, hi,

it looks like there might be a bug in caller.py Mem ld/st.  by accident
i asked a byte-store (stb) to write to address 0x9.  the memory-dump
(fu/compunits/test/test_compunit.py) dumps out the internal dictionary
(sim.mem.mem.items()) however it uses sim.mem.ld to initialise the
nmigen Memory object.

* bytes per word is 8
* address 9 divided by 8 is 1
* remainder is also 1.

does this mean that the LD/ST is being word-order realigned?


Writing 0xee to ST 0x9 memaddr 0x1/1
width,rem,shift,mask 1 1 0x30 0xff
mem @ 0x1: 0xabeeef0187654321
None
carry already done? 0b0
get_cu_outputs 2 0
after got outputs, rd_rel, wr_rel, wrmask:  0b0 0b0 0b0
busy 1
busy 1
busy 1
busy 0
check cu outputs stb 3, 1(2) {}
check extra output 'stb 3, 1(2)' 0 0
sim mem dump
         0 5432123412345678
         1 abeeef0187654321
         4 1828384822324252
nmigen mem dump
         0 5432123412345678
         1 abcdef018765ee21
         2 0000000000000000
         3 0000000000000000
         4 1828384822324252
         5 0000000000000000

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 377] possible bug in Simulator Mem ld/st function

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=377

Luke Kenneth Casson Leighton <lkcl@lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|lkcl@lkcl.net               |mtnolan2640@gmail.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 377] possible bug in Simulator Mem ld/st function

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=377

--- Comment #1 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
problem "solved":

diff --git a/src/soc/decoder/isa/caller.py b/src/soc/decoder/isa/caller.py
index f76afda..7dfcec1 100644
--- a/src/soc/decoder/isa/caller.py
+++ b/src/soc/decoder/isa/caller.py
@@ -51,6 +51,7 @@ class Mem:
     def _get_shifter_mask(self, wid, remainder):
         shifter = ((self.bytes_per_word - wid) - remainder) * \
             8  # bits per byte
+        shifter = remainder * 8
         mask = (1 << (wid * 8)) - 1
         print ("width,rem,shift,mask", wid, remainder, hex(shifter),
hex(mask))
         return shifter, mask

is this something that we need to put under the control of a BE/LE MSR flag?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 377] possible bug in Simulator Mem ld/st function

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=377

--- Comment #2 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
hmmm i took a look at microwatt, and i'm likewise not seeing any evidence of
offset-reversal based on an 8-byte (64-bit) boundary.

i did however discover that qemu 8-byte memory-read returns data in big-endian
order, and had to read it in single-bytes then reconstruct a little-endian
debug/display value.

honestly i have no real idea what i am doing here and could really use some
help and discussion.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 377] possible bug in Simulator Mem ld/st function

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=377

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
i think i got it.

nmigen memory write port, if you specify a granularity argument to cut the SRAM
into bytes, writes those bytes in *big* endian order.

however if you read the same interface with a single read-enable line, the
answer comes back in *little* endian order.

*face-palm*

i am however much preferring thinking in LE terms when it comes to memory
layouts and byte addressing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 377] possible bug in Simulator Mem ld/st function

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=377

--- Comment #4 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
i tracked this down by adding memory dump/alteration to qemu and making
a comparison of memory in qemu and memory in the simulator.

it was a number of separate things:

* the hardware was not performing big-endian byte reversal
* the simulator was storing 8 bytes in a dictionary on 8-byte
  address-aligned boundary where the data order of each 8-byte
  group was byte-reversed (big-endian)
* to correct this, the shift-mask function subtracted the offset
  from the *other* end (the 8-byte boundary of the underlying
  simulated memory - 64 bit blocks)

what i did was:

* reverse the order of 8-byte groups being stored to be in
  little-endian format in the simulator
* turned the shift round so that it is exactly the
  LSB bits of the address (bits 0 to 2) where previously
  it was (7-datalen-AddrLSBs)
* added a function which byte-reverses (big-endians) the load/store
  *data* - not the entire simulator-stored 64-bit-granularity memory
* added a byte-reverse function into the hardware.

that byte-reverse function *should* now be possible to call on-demand
for LD/ST byte-reversal opcodes.  i will give that a shot and see if
it works.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev