[Libre-soc-bugs] [Bug 855] add libre-soc to kestrel

[bugzilla-daemon at libre-soc.org]

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

--- Comment #13 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to tpearson from comment #12)
> I'm holding off on posting the patches until I'm a little bit further along
> -- basically I'm still validating the overall approach to integration here
> to make sure I'm not going down a dead end.

please don't take this approach, aside from anything we are under Audit
Conditions.  and also under time-pressure: we cannot wait for weeks.

please do use a branch, like last time, i don't mind: create
what you need.

> There are still a couple of issues, mostly centered around the timebase /
> decrementer but also some general problems and functional differences from
> Microwatt that I need to investigate.

there should be absolutely no difference whatsoever: that is the inviolate
rule.

if you investigate those "in a general uncontrolled way", it will
take forever, you will have hundreds of thousands or potentially millions
of instructions to go through with an almost impossible / non-existent
debugging environment.

our approach in this project has been: unit tests, unit tests, unit tests.

the reason why Libre-SOC works at all is not because i knew exactly
what i was doing, it was because i strictly followed a process of
creating unit tests that could produce *identical* output to that
of microwatt, usually under verilator, literally dumping output
of all registers line-by-line.

i have run mmu.bin, helloworld.bin, binary tests1 through 10,
dectb.bin, and several others, in this way.

by doing simple "diffs" on runs containing those register-dumps i
could then track down the exact point at which the instruction was
wrong.

i then added a libre-soc unit test, corrected the python-based Simulator
to match it, ran the same unit test against the HDL, corrected that,
then went back and re-ran the verilator simulation and found that it worked.

after enough of these (18 months worth) it made progress.

mmu.bin took weeks to get working.  each unit test in mmu.bin
that failed required 2-4 unit tests in libre-soc to be written,
including getting the python-based Simulator to replicate the
functionality.


to reiterate: if there is a problem i *need* to know *exactly* where
it is, with a small stand-alone (helloworld-like) unit test or other
repro case.


> As a bit of background, Zephyr (the RTOS underlying the full network-enabled
> version of Kestrel) uses both the timebase and the decrementer, along with
> the decrementer interrupt, for thread scheduling and delays / timeouts.  For
> some reason I haven't been able to track down yet, Zephyr operates as if it
> is under continual overload -- timeouts are running way too fast, it's
> literally saturated a test network with continuous DHCP requests instead of
> waiting the normal second or two for a response.

timer/dec in neither microwatt nor libre-soc are "according to spec".
the linux kernel device-tree file has to have an explicit entry to
say what the timer base frequency is, and does a calculation on what
multiplier is needed to get that into "real" Hz, by running a tight
"CTR" loop and checking how much dec/tb time elapsed.

with libre-soc running an FSM, a similar calibration may be needed
because the FSM runs instructions approximately 10x slower than microwatt.

it would not surprise me at all if timer/dec were running 1-2 orders of
magnitude faster than "expected".


> Potentially related to the abocve: I have noticed that LibreSoC is
> significantly slower than Microwatt in at least the bootloader memory test
> loop,

you should find it to be approximately 10x slower because it is still a
Finite State Machine not a pipeline.  there's a pipelined Core in development.


> and that would be explained by a decrementer interrupt firing more
> often than under Microwatt.

DEC/TB also operate slightly differently: they run on a 4-clock schedule,
readdec-writedec-readtb-writetb to avoid having half a dozen register file
ports.

so you can expect DEC/TB to be 4x slower than microwatt which updates
them both exactly on a clock cycle per update.

> Finally, I've noticed problems with the GPIO setup / set using the LiteX CSR
> access routines.  I need to determine if this is a difference in how
> LibreSoC is executing an instruction specific to the CSR bytewise access, or
> a general problem in the new integration "glue logic".

again: unit tests.

i need to activate the project's standard procedures, i appreciate this one
may be slightly tricky, although it may be possible to do with a verilator
c++ GPIO simulator module, first under microwatt then drop-in libre-soc.

this is the FSM which performs $display() dumping of full register state
from both microwatt and libresoc, using DMI control

https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=sim.py;h=f4ec8dce544e5ede1ec909d86cd28a7b3d2df08b;hb=0f03df1546c8cf6ab91ef63b04713dca768a84c4#l189

it's pretty braindead, it's dreadfully slow, and has saved vast amounts
of pain.

-- 
You are receiving this mail because:
You are on the CC list for the bug.