Skip to main content

Verification

Even though the CPU is relatively simple, I still want to verify it. I've got two Java emulators, which seem to work okay .... ish. One seems to be more established and supported (RARS) so I will verify against that. 

Jupiter has the option to dump code and data so it can operate as an assembler, so I use that to generate object code (a text file of hex constants, but it'll do)

So Plan 9 is to write some Python scripts to generate verification code using a seeded RNG, so I can reseed it if there's a problem. I've got a skeleton so far, but no actual code in it, yet. Then I'll write a reference emulator in Python to check I understand how the RV32I instructions work, which look relatively straightforward. 

Then I'll write a proper emulator in C, verify that, and start on the design and implementation of the quasi-assembler.

L8R: I have a Python emulator that mostly seems to work .... it probably doesn't :( only missing the load and store instructions which will be done tomorrow.

Then I will start work on the verification of the various instruction groups, testing it against the RARS emulator then the Python emulator. Once this is done I can be reasonably confident in the implementation. RARS is used by many university courses so any significant bugs should have been picked up.

The only tricky thing about writing a rv32i emulator is the messy opcodes the Branch and Jump and SB/SH/SW opcodes have. 


Comments

Post a Comment

Popular posts from this blog

About Phidias

Phidias is a RISC V based home computer design, which should run on non RISC V platforms as well. Design ideas are here on github This blog is pretty much progress notes, assuming I make any :)
Post a Comment
Read more

Generation

So I finished the verification generator and it seems to run pretty well, and validates on RARS. When experimenting with MUL I found that Jupiter isn't actually generating the right mnemonics, I'm not entirely sure what's going on, if it's generating RV64i equivalents - doesn't seem to be.But for things like ADD the upper 7 bits are zero and they're not. Probably make sense when I get further into RISC V. Then I wrote a fairly standard emulator generator that produces C. I reduced the basic opcode to 256 ; every rv32i opcode ends in 11, so that's 5 bits from that and 3 function bits. This way I can make the code generator in the case statement use a jump vector table rather than some lookup nonsense. Next up is to get the 'C' code verified, then build that into something resembling an emulator. L8R: I have the generated C code compiling and most of the support code written. Should get some code running in C, including the verifier hopefully tomorrow.
Post a Comment
Read more