Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Michael Nolan <mtnolan2640@gmail.com>]

On 3/26/20 5:03 PM, Luke Kenneth Casson Leighton wrote:
>
> if you prefer just reply to this message with a paragraph or two and i
> will cut/paste it?
>
> l.

The decoder we have is based on that of IBM's [microwatt reference
design](https://github.com/antonblanchard/microwatt). Because
microwatt's decoder is quite regular, consisting of a bunch of large
switch statements returning fields of a struct, we elected not to
pursue a direct conversion of the VHDL to nmigen. Instead, we
extracted the information in the switch statements into several CSV
tables, and leveraged nmigen to construct the decoder from these
tables. We applied the same technique to extract the subfields
(register numbers, branch offset, immediates, etc.) from the
instruction, where Luke converted the information in the POWER ISA
specification to text, and wrote a module in python to extract those
fields from an instruction.

To test the decoder, we initially verified it against the tables we
extracted, and manually against the power ISA specification. Later
however, we came up with the idea of verifying the decoder against the
output of the GNU assembler. This is done by selecting an instruction
type (integer reg/reg, integer immediate, load store, etc), and
randomly selecting the opcode, registers, immediates, and other
operands. We then feed this instruction to GNU AS to assemble, and
then the assembled instruction is sent to our decoder. From this, we
can then verify that the output of the decoder matches what was generated
earlier.

We also explored using a similar idea to test the functionality of the
entire SOC. By using the [QEMU](https://www.qemu.org/) powerpc
emulator, we can compare the execution of our SOC against that of the
emulator to verify that our decoder and backend are working correctly.
We would write snippets of test code (or potentially randomly generate
instructions) and send the resulting binary to both the SOC and
QEMU. We would then simulate our SOC until it was finished executing
instructions, and use Qemu's gdb interface to do the same. We would
then use Qemu's gdb interface to compare the register file and memory
with that of our SOC to verify that it is working correctly. I did
some experimentation using this technique to verify a rudimentary
simulator of the SOC backend, and it seemed to work quite well.


_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev