[libre-riscv-dev] [Bug 368] New: Need one example unit test of how to run some assembly code "qemu vs simulator" rather than "qemu vs hardware"

[libre-riscv-dev] [Bug 368] New: Need one example unit test of how to run some assembly code "qemu vs simulator" rather than "qemu vs hardware"

[bugzilla-daemon]

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

            Bug ID: 368
           Summary: Need one example unit test of how to run some assembly
                    code "qemu vs simulator" rather than "qemu vs
                    hardware"
           Product: Libre-SOC's first SoC
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: CONFIRMED
          Severity: enhancement
          Priority: ---
         Component: Formal Verification
          Assignee: lkcl@lkcl.net
          Reporter: colepoirier@gmail.com
                CC: libre-riscv-dev@lists.libre-riscv.org
   NLnet milestone: ---

We need one example unit test of how to run some assembly code
"qemu vs simulator" rather than "qemu vs hardware"

or, even just "qemu with some asserts" but looking *exactly* like how
it's done in the simulator, right now.

and that ultimately it should be possible to have a runtime switch
(or a suite of tests) that allow us to verify *aaalll* the simulator
test_pipe_caller.py tests, in the following way:

* simulator vs qemu
* qemu vs hardware
* hardware vs simulator

later i would very much like to be able to add microwatt to that list.

<https://bugs.libre-soc.org/show_bug.cgi?id=325#c82>

-- 
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 368] Need one example unit test of how to run some assembly code "qemu vs simulator" rather than "qemu vs hardware"

[bugzilla-daemon]

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

Michael Nolan <mtnolan2640@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mtnolan2640@gmail.com

--- Comment #1 from Michael Nolan <mtnolan2640@gmail.com> ---
Ok, I did this quite a while ago, testing against my crappy handwritten python
simulator. I'll give testing against the pseudocode simulator tomorrow a go.

Beware, from what I remember only general purpose registers work. qemu-gdb
seemed to have a bug (or maybe it's qemu? idk) where you couldn't read out XER,
CR, and friends directly from gdb.

-- 
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 368] Need one example unit test of how to run some assembly code "qemu vs simulator" rather than "qemu vs hardware"

[bugzilla-daemon]

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

--- Comment #2 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #1)
> Ok, I did this quite a while ago, testing against my crappy handwritten
> python simulator. I'll give testing against the pseudocode simulator
> tomorrow a go.

that would be superb.


> Beware, from what I remember only general purpose registers work. qemu-gdb
> seemed to have a bug (or maybe it's qemu? idk) where you couldn't read out
> XER, CR, and friends directly from gdb.

hmmm... we could cheat, in a similar way to how gdb itself works: substitute
some instructions, actually execute mfcrf and mfmsr etc. directly putting
the result into a register, read *that*, then restore them afterwards.

or, it could just be that python-gdb doesn't have the capability added yet.

at least however if we can check int registers, then another hack-way to
do it would be to actually add, into the assembly listing being emulated,
the instruction to copy out to RT.  it's a bad hack.

-- 
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 368] Need one example unit test of how to run some assembly code "qemu vs simulator" rather than "qemu vs hardware"

[bugzilla-daemon]

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

--- Comment #3 from Michael Nolan <mtnolan2640@gmail.com> ---
We could also do what I did originally. It's not particularly elegant, but at
the end of a program where I wanted to check CR, I manually added a mfcr
$some_register to the end. It won't allow us to check everything in lockstep,
but it will let us verify that the two simulators produce the same results for
a given program.

-- 
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 368] Need one example unit test of how to run some assembly code "qemu vs simulator" rather than "qemu vs hardware"

[bugzilla-daemon]

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

--- Comment #4 from Michael Nolan <mtnolan2640@gmail.com> ---
Oh, since the actual debug interface uses gdb and has nothing to do with qemu,
it might be possible to run the generated programs under gdb on power hardware.

-- 
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 368] Need one example unit test of how to run some assembly code "qemu vs simulator" rather than "qemu vs hardware"

[bugzilla-daemon]

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

--- Comment #5 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #4)
> Oh, since the actual debug interface uses gdb and has nothing to do with
> qemu, it might be possible to run the generated programs under gdb on power
> hardware.

oh of course.  and... hmmm... here's an idea.
if an option can be added which allows that to be done through ssh,
we'd be able to work locally and not have to
have a full dev environment on talos1.libre-soc.org (each).

one utterly cool way of doing remote python execution:
https://github.com/tomerfiliba/rpyc

he invented a packet format and a protocol that contains commands
like "dir()" so you get back the list of objects, and so on.  even
exceptions are properly transferred.

once "on" that remote system, the only library that would need to
be installed on the *remote* system: pygdbmi.

-- 
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 368] Need one example unit test of how to run some assembly code "qemu vs simulator" rather than "qemu vs hardware"

[bugzilla-daemon]

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

--- Comment #6 from Michael Nolan <mtnolan2640@gmail.com> ---
Ok, I think I've got something working. In soc/simulator/test_sim.py, I
replaced the code dealing with my handwritten simulator with what's needed to
use the pseudocode simulator. All the tests, except for multiplication now work

-- 
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 368] Need one example unit test of how to run some assembly code "qemu vs simulator" rather than "qemu vs hardware"

[bugzilla-daemon]

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

--- Comment #7 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #6)
> Ok, I think I've got something working. In soc/simulator/test_sim.py, I
> replaced the code dealing with my handwritten simulator with what's needed
> to use the pseudocode simulator. All the tests, except for multiplication
> now work

fantastic.  now we're cooking.  ultimately it should be possible to morph
this into classes that have a "set inputs" method, a "run_program" method,
and a "get results" method.

then we can construct unit tests that can be passed in one class instance
that does qemu, and another that does hardware, another that does simulator,
and compare anything-against-anything.

-- 
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 368] Need one example unit test of how to run some assembly code "qemu vs simulator" rather than "qemu vs hardware"

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CONFIRMED                   |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
https://docs.cocotb.org/en/latest/quickstart.html
should allow us to also include microwatt in the mix.
TODO later.  thank you michael for getting this started.

-- 
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