[Libre-soc-dev] synchronised incremental SV development planning

[Luke Kenneth Casson Leighton]

we have three things to augment to do SV: ISACaller, power-gem5 and
TestIssuer.  i would like us to do these in lock-step, with plenty of help
from everyone, with at least one person nominally "in charge" of each, and
plenty of discussion on what's involved and what's going on.

the reason for including ISACaller is that it is the simplest way to run 1,
2, 3, 6 assembly instructions and inspect the resultant gtkwave output.

the reason for including power-gem5 is that it runs linux and is a
cycle-accurate simulator: it will be possible to compile e.g ffmpeg and
libavutil etc to run under it at some point, for Lauri to run AV tests.

the stages that we need to go through are actually very simple and
straightforward, being quite literally going through the "overview"
document and doing them, one by one.

starting with the for-loop 0-VL-1 we have *one job* involving 2
ultra-ultra-braindead-simple lines of pseudocode to implement:

   for i = 0 to VL-1:
       GPR(RT+i) = GPR(RA+i) + GPR(RB+i)

this involves 4 things:

1) adding SVSTATE as an SPR

2) identifying the "Program Counter Loop Step" routine and adding a VL
for-loop

3) shoving the "i" of "for i in range(VL") into the SVSTATE.srcstep bits

4) modifying the read/write point in the regfile to add SVSTATE.srcstep to
the reg number

*that is it*.  that is *literally* all that is needed.  ISACaller should
take no more than 2 days, gem5 a bit longer because it is unfamiliar code,
TestIssuer maybe 5 days because it involves adding to a complex FSM, it
can't be done as like a software for-loop.

TestIssuer has to implement the more complex increment-based FSM straight
away, whereas for ISACaller and gem5 the first implementation can literally
be a for-loop.


the next stage will be to add an implementation of setvl, and at that point
it becomes possible to run unit tests.

two things definitely needed:

* that macro system you were talking about, jacob.  we actually need one in
c, one in c++ and one in python.  the python one to overload to a
string/list that autogenerates ".long xxx" followed by the v3.0B asm code.

* to find out how to get gem5 to run really, REALLY short programs and get
at the regfile and memory, just like in the qemu-runner.
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simulator/qemu.py;hb=HEAD

being able to run power-gem5 and inspect the ongoing state is extremely
important, apart from anything we need to know if it matches the unit
tests.  i will ask the lead developer if this is possible.

who would like to do what?

i have volunteered alain to curate and coordinate power-gem5 already :)

l.





https://github.com/power-gem5/gem5/tree/gem5-experimental/src/arch/power/isa/formats


https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/isa/caller.py;h=ad724a113ba21359c455a903c7816b4a0aa79e9e;hb=1c274daab0955fa0e1cb98c4fe43709b7f795c99#l270


https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simple/issuer.py;h=d662dff4c20e7904e6ca7cb3ae2ceaa6f03b6e06;hb=HEAD#l290




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68