[libre-riscv-dev] [Bug 325] create POWER9 TRAP pipeline
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Sun Jun 7 22:11:59 BST 2020
--- Comment #80 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cole Poirier from comment #79)
> (In reply to Luke Kenneth Casson Leighton from comment #75)
> > commit d2e0e6bea57795fb522e0805b16e6f2852472f98
> > Author: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > Date: Sun Jun 7 07:03:58 2020 +0100
> > add MSR to simulator context
> > as comment says. i also updated the git submodule so that sprset now
> > contains the (new, untested) mtmsr/mfmsr. if you rerun pywriter.py
> > you'll see the code now gets created.
> > and that in turn means that if you add a unit test that uses mfmsr
> > or mtmsr, the code in the auto-generated sprset.py for op_mfmsr/op_mtmsr
> > will get called.
> > whether that (completely untested) code is *accurate* or not is another
> > matter.
> > we now have a situation of two "unknowns"
> > 1. unknown simulator
> > 2. unknown hardware code.
> > the normal solution for this is to "call in" something that *is* known,
> > and that would be the qemu emulator. except we kinda need some help from
> > michael to do that in a short timescale, or we need to investigate it
> > in a longer one. given that there's a critical task needed (investigating
> > the CR bit-ordering) i'd rather we not pull him off of that.
> So until we have the known qemu emulator I should just try writing
> appropriate unit tests for when we have the emulator working? Should I raise
> a bug report for investigating the qemu powerpc emulator on a longer
> timescale? What should I say in the bug description?
> (In reply to Luke Kenneth Casson Leighton from comment #76)
> > i'm also attempting to add support for TRAP - as a function - in the
> > parser and simulator, *without* changing fixedtrap.mdwn, which is
> > taken directly from the 3.0B PDF. bit of a pain.
> > now, if you create a test_tdi() function in trap test_pipe_caller.py,
> > the simulator *should* print out "TRAP TODO".
> > diff --git a/src/soc/decoder/isa/caller.py b/src/soc/decoder/isa/caller.py
> > index 61aa451..ae5d479 100644
> > --- a/src/soc/decoder/isa/caller.py
> > +++ b/src/soc/decoder/isa/caller.py
> > @@ -233,6 +233,11 @@ class ISACaller:
> > self.decoder = decoder2.dec
> > self.dec2 = decoder2
> > + def TRAP(self, trap_addr=0x700):
> > + print ("TRAP: TODO")
> > + # store PC in SRR0, set PC to 0x700
> > + # store MSR in SRR1, set MSR to um errr something
> > +
> > def memassign(self, ea, sz, val):
> > self.mem.memassign(ea, sz, val)
> This is our autogenerated from parsing csv files emulator?
nono, that's actually the function that gets called *by* the emulator.
it's decoder/isa/caller.py (which is the base class for the simulator)
> Is this something I can help with
actually, probably yes. it should be as brain-dead simple as
putting things into the self.spr dict:
self.spr['SRR0'] = self.pc.CIA
and also modify the NIA. that sort of thing.
> So is this TRAP function added in sort of ad hoc via caller.py, because it
> isn't contained in fixedtrap.mdwn?
it is... however look at the PDF SPEC (or see comment #1 which contains
the pseudo-code. that's not a function, is it?
so what i did was, identify the keyword "TRAP" and got it to output
a *function* call "self.TRAP()". auto-generated decoder/isa/fixedtrap.py
now contains this:
def op_twi(self, RA):
a = EXTS(RA[32:64])
if lt(a, EXTS(SI)) & TO:self.TRAP()
if gt(a, EXTS(SI)) & TO:self.TRAP()
*now* it can call the function which was added in caller.py, *now* we
can get that function to make the required modifications to the SPRs
and to the PC (NIA - Next Instruction Address).
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-riscv-dev