[Libre-soc-sim] NLnet grant request, draft

[Peter Hsu]

Hello Luke, All,

I have rewritten uspike.  It is on the 'uspike' branch of 
github.com/phaa-eu/cavatools if you are interested.

It now understand all instructions Spike does: standard GC, vector RVV, 
and various in-progress extensions such as "B" Bit Manipulation.  The 
encodings and execution semantics are script-derived from riscv-opcodes 
and riscv-isa-sim which you need to download from github.  I use the 
execution state directly from Spike's processor_t and state_t declarations.

I have also connected uspike to riscv-unknown-linux-gnu-gdb through the 
gdb command 'target remote hostname:portnumber' and running 'uspike 
--gdb=hostname:portnumber <riscv elf binary>.  However it is missing 
many things like setting breakpoint, etc. so is not operational.

The new uspike structure uses a Json file of instructions like this:

{
     "beq": {
         "type": "sb",
         "bits": "{-12|10:5} rs2 rs1 000 {4:1|11} 1100011",
         "ext": "",
         "flags": "pc",
         "exec": "if(RS1 == RS2)\n  set_pc(BRANCH_TARGET);\n"
     },
     "bne": {
         "type": "sb",

The only code that needs to include Spike headers is the interpreter 
loop and gdblink; the rest of the system carries the CPU state as a 
void*.  I'm hoping this will make it easier to port a different ISA from 
an existing simulator.

There are still bugs in uspike--on a simple test (John Hennessy's 
Stanford Benchmark from a million years ago) it crashes after doing a 
bunch of system calls running 47 million instructions.  I will continue 
to debug.

Cheers, Peter


On 29/7/21 18:17, lkcl wrote:
> On 7/29/21, Peter Hsu <peter.hsu at bsc.es> wrote:
>> BTW the laptop failure was due to SSD.
> i do not recommend anything other than Intel S3500 series. i tested
> these, power pulled 6,000 times between 5 and 25 seconds, during heavy
> read/write. not one single byte lost.
>
> by contrast Kingston and Crucial drives self-destructed after 2 to 10
> minutes, some so badly they actually corrupted their firmware blocks
> and did not come back on the SATA Bus.
>
>> I am (slowly) recoding lost work.
>> But it is opportunity to write better code now that I know what needs to be
>> done.
> at least there is a bright side.