[Libre-soc-dev] daily kan-ban update 27aug2020

Cole Poirier colepoirier at gmail.com
Thu Aug 27 19:02:22 BST 2020

On Thu, Aug 27, 2020 at 10:51 AM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> On Thu, Aug 27, 2020 at 6:35 PM Cole Poirier <colepoirier at gmail.com> wrote:
> >
> > How are you going about this?
> * compiling microwatt core_tb ("make core_tb")
> * copying tests/1.bin to main_ram.bin (as shown in scripts/make_test.sh)
> * outputting the log to a file
> * running litex/florent/sim.py --debug > /tmp/ls.txt
> * running litex/florent/sim.py --debug --cpu=microwatt > /tmp/mw.txt
> * doing a diff on ls.txt and mw.txt
> * when discrepancies are found do a ridiculously laborious process of
> analysing the *microwatt* core_tb log file to find the XER and CR
> modifications that you *can't* get out via the DMI interface in sim.py
> because microwatt doesn't _have_ a way through core_debug.vhdl to
> _read_ XER or CR.
> sigh.

Oy! Quite the process, will this be made significantly easier by the
patch you just sent the microwatt team? or is that just a minor

> > Can I help, perhaps trying to find bugs
> > in another part of the HDL? Would need some brief instruction if this
> > is the case, but could be a benefit to have a second person working on
> > it with you?
> the problem is that because of a cascade effect where one error
> creates knock-on errors when that register's incorrect value is used
> in another instruction, i can only realistically find (then fix) one
> instruction at a time.
> of course, if you were to use microwatt/tests/2.bin *instead* then yes
> you could help because the chances are high that, by running a
> different instruction, you'd find a different bug.

May try this, if I have time after working on dcache.py, adding
dcache_tb.vhdl, and documenting mesa-dev-env setup.

> it's excruciatingly tedious.
> i have to stop typing.  RSI.

Indeed. Get some rest :)


More information about the Libre-soc-dev mailing list