[libre-riscv-dev] [Bug 325] create POWER9 TRAP pipeline

[bugzilla-daemon at libre-soc.org]

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

--- 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:

class fixedtrap:

    @inject()
    def op_twi(self, RA):
        a = EXTS(RA[32:64])
        if lt(a, EXTS(SI)) & TO[0]:self.TRAP()
        if gt(a, EXTS(SI)) & TO[1]: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.