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

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

[bugzilla-daemon]

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

            Bug ID: 325
           Summary: create POWER9 TRAP pipeline
           Product: Libre-SOC's first SoC
           Version: unspecified
          Hardware: Other
                OS: Linux
            Status: CONFIRMED
          Severity: enhancement
          Priority: ---
         Component: Source Code
          Assignee: lkcl@lkcl.net
          Reporter: lkcl@lkcl.net
                CC: libre-riscv-dev@lists.libre-riscv.org
   NLnet milestone: ---

we need a "trap" pipeline, or to decide if this is to be considered part of
Branch, due to the changes that trap makes to the PC.  this by analysing the
register port allocation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

Luke Kenneth Casson Leighton <lkcl@lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.libre-soc.org/
                   |                            |show_bug.cgi?id=305

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

Luke Kenneth Casson Leighton <lkcl@lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.libre-soc.org/
                   |                            |show_bug.cgi?id=313

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #1 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
* twi TO,RA,SI
* tw TO,RA,RB

    a <- EXTS((RA)[32:63])
    b <- EXTS((RB)[32:63])
    if (a < b) & TO[0] then TRAP
    if (a > b) & TO[1] then TRAP
    if (a = b) & TO[2] then TRAP
    if (a <u b) & TO[3] then TRAP
    if (a >u b) & TO[4] then TRAP

Special Registers Altered:

    None

so, here, inputs are:

* RA
* RB (or imm)
* MSR (where does this come from?)

logic is identical to CMP


outputs are:

* NIA
* SRR1 (SPR)

see
https://github.com/antonblanchard/microwatt/blob/master/execute1.vhdl

irq_nia <= (to_unsigned(16#700#, 64));
srr1 <= msr_copy(ctrl.msr);
-- set bit 46 to say trap occurred
srr1(63 - 46) <= '1';


this one although it smells like a Branch it actually seems to smell more like
a MicroCoded double op, a combination of OP_CMP and OP_BR.

i am reluctant to suggest we do microcoding for this design right now

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #2 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
this code in microwatt execute1.vdhl tends to suggest that two SPRs need to be
outputted from TRAP:

* SRR0 (containing the PC *after* the trap is to return - NIA)
* SRR1 (containing the new MSR)

note they are also using a FSM, writing out the two registers SRR0 and SRR1
across
2 clock cycles.

    ctrl_tmp.irq_state <= WRITE_SRR0;
    exception := '0';
        illegal := '0';
        exception_nextpc := '0';
        v.e.exc_write_enable := '0';
        v.e.exc_write_reg := fast_spr_num(SPR_SRR0);
        v.e.exc_write_data := e_in.nia;

    if ctrl.irq_state = WRITE_SRR1 then
        v.e.exc_write_reg := fast_spr_num(SPR_SRR1);
        v.e.exc_write_data := ctrl.srr1;
            v.e.exc_write_enable := '1';
            ctrl_tmp.msr(MSR_SF) <= '1';
            ctrl_tmp.msr(MSR_EE) <= '0';
            ctrl_tmp.msr(MSR_PR) <= '0';
            ctrl_tmp.msr(MSR_IR) <= '0';
            ctrl_tmp.msr(MSR_DR) <= '0';
            ctrl_tmp.msr(MSR_RI) <= '0';
            ctrl_tmp.msr(MSR_LE) <= '1';
        f_out.redirect <= '1';
        f_out.redirect_nia <= ctrl.irq_nia;
        v.e.valid := e_in.valid;

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
section 7.5.9 covers TRAP, and shows that yes:

* SRR0 is set to "PC following trap"
* SRR1 contains the *old* MSR (sorry, not the new MSR)
* MSR is updated to meet the conditions of the trap

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

Jacob Lifshay <programmerjake@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |programmerjake@gmail.com

--- Comment #4 from Jacob Lifshay <programmerjake@gmail.com> ---
I think this should also cover interrupts.

I would suggest having the execution unit be a FSM since traps/interrupts are
rare, so the FSM is not activated unless a trap/interrupt is taken. When we
receive an external interrupt, we could switch the decoder to insert a special
trap instruction instead of decoding normally.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

Michael Nolan <mtnolan2640@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|lkcl@lkcl.net               |mtnolan2640@gmail.com
                 CC|                            |mtnolan2640@gmail.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #5 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jacob Lifshay from comment #4)
> I think this should also cover interrupts.
> 
> I would suggest having the execution unit be a FSM since traps/interrupts
> are rare, so the FSM is not activated unless a trap/interrupt is taken. When
> we receive an external interrupt, we could switch the decoder to insert a
> special trap instruction instead of decoding normally.

traps are stunningly simple, the only thing they do is change the MSR and NIA
(program counter).  and change SRR0 and SRR1. it is hardly even an FSM :)

i like the interrupt idea, i believe it is kinda expected to do this.

l.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #6 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
* did the usual code-morphs blah blah just to make me feel happy
  (and also so i know what the code is doing, so i feel confident
  when it comes to connecting it up).

  i'm done with that :)

* branch's data structure uses Data to indicate when things
  are updated.  i felt it might be sensible to keep a consistent
  API so did the same thing to Trap's data structure.

  thus, o.nia.ok, o.srr0.ok and o.srr1.ok are all set to 1
  when the trap signals "go"

  these signals, for the two SPRs, can be wired directly to
  the FunctionUnit "WRITE_REQUEST" signals with no additional
  logic needed for decoding the operand at the FunctionUnit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #7 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #5)
> (In reply to Jacob Lifshay from comment #4)
> > I think this should also cover interrupts.
> > 
> > I would suggest having the execution unit be a FSM since traps/interrupts
> > are rare, so the FSM is not activated unless a trap/interrupt is taken. When
> > we receive an external interrupt, we could switch the decoder to insert a
> > special trap instruction instead of decoding normally.
> 
> traps are stunningly simple, the only thing they do is change the MSR and
> NIA (program counter).  and change SRR0 and SRR1. it is hardly even an FSM :)
> 
> i like the interrupt idea, i believe it is kinda expected to do this.

hints of this technique:

irq_valid := '0';
if ctrl.msr(MSR_EE) = '1' then
    if ctrl.dec(63) = '1' then
        ctrl_tmp.irq_nia <= std_logic_vector(to_unsigned(16#900#, 64));
        report "IRQ valid: DEC";
        irq_valid := '1';
    elsif i_in.irq = '1' then
        ctrl_tmp.irq_nia <= std_logic_vector(to_unsigned(16#500#, 64));
        report "IRQ valid: External";
        irq_valid := '1';
    end if;
end if;

so hypothetically, yes, we could create an OP_IRQ that is covered by this
pipeline and is responsible for changing nia etc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #8 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
here is the continuation of that process (the FSM in microwatt which has to
take a couple of cycles to write out SRR0/1)

the first bit drops SRR1 into the SPR regfile (we can do 1 cycle) then moves on

the second elsif is near identical to TRAP except it sets the priv bit in the
outgoing MSR.

this we would need to detect at the instruction issue phase (MSR PR bit set)
and yes that is a pain in the neck, for *issue* phase to have to do that.

however once detected, again, an internal OP_INTPRIVthing can be created, sent
to the Trap pipeline for it to action and generate SRR1 and 0


elsif irq_valid = '1' and e_in.valid = '1' then
    -- we need two cycles to write srr0 and 1
    -- will need more when we have to write HEIR
    -- Don't deliver the interrupt until we have a valid instruction
    -- coming in, so we have a valid NIA to put in SRR0.
    exception := '1';
    ctrl_tmp.srr1 <= msr_copy(ctrl.msr);

elsif e_in.valid = '1' and ctrl.msr(MSR_PR) = '1' and
            instr_is_privileged(e_in.insn_type, e_in.insn) then
    -- generate a program interrupt
    exception := '1';
    ctrl_tmp.irq_nia <= std_logic_vector(to_unsigned(16#700#, 64));
    ctrl_tmp.srr1 <= msr_copy(ctrl.msr);
    -- set bit 45 to indicate privileged instruction type interrupt
    ctrl_tmp.srr1(63 - 45) <= '1';
    report "privileged instruction";

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #9 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
suggest adding mfmsr and mtmsr to TRAP pipeline.  does mean adding RT and MSR
as additional output regs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #10 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
could also add SPRSET as well (1 more SPR reg to input)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #11 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
and probably addpcis:

D <- d0||d1||d2
RT <- NIA + EXTS(D || 16 0)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #12 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #11)
> and probably addpcis:
> 
> D <- d0||d1||d2
> RT <- NIA + EXTS(D || 16 0)

and OP_RFID:

            when OP_RFID =>
                f_out.redirect <= '1';
                f_out.virt_mode <= b_in(MSR_IR) or b_in(MSR_PR);
                f_out.priv_mode <= not b_in(MSR_PR);
                f_out.redirect_nia <= a_in(63 downto 2) & "00"; -- srr0
                -- Can't use msr_copy here because the partial function MSR
                -- bits should be left unchanged, not zeroed.
                ctrl_tmp.msr(63 downto 31) <= b_in(63 downto 31);
                ctrl_tmp.msr(26 downto 22) <= b_in(26 downto 22);
                ctrl_tmp.msr(15 downto 0)  <= b_in(15 downto 0);
                if b_in(MSR_PR) = '1' then
                    ctrl_tmp.msr(MSR_EE) <= '1';
                    ctrl_tmp.msr(MSR_IR) <= '1';
                    ctrl_tmp.msr(MSR_DR) <= '1';
                end if;

although i have no idea what to do about those "priv_mode" and "virt_mode"
bits: we don't have global data structures like they do in microwatt.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #13 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #10)
> could also add SPRSET as well (1 more SPR reg to input)

no, it's 2.  too many.  2 because one is FAST (covering TAR, LR, SRR0/1 etc.)
the other is for the (slow) SPR regfile SRAM.  not a good idea.  that's 6
input regs, and 6 output.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #14 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
and OP_SC.  this also sets NIA and SRR1.

            when OP_SC =>
                -- check bit 1 of the instruction is 1 so we know this is sc;
                -- 0 would mean scv, so generate an illegal instruction
interrupt
                -- we need two cycles to write srr0 and 1
                if e_in.insn(1) = '1' then
                    exception := '1';
                    exception_nextpc := '1';
                    ctrl_tmp.irq_nia <= std_logic_vector(to_unsigned(16#C00#,
64));
                    ctrl_tmp.srr1 <= msr_copy(ctrl.msr);
                    report "sc";
                else
                    illegal := '1';
                end if;

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

Luke Kenneth Casson Leighton <lkcl@lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|mtnolan2640@gmail.com       |colepoirier@gmail.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #15 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=2955619bc39a83b09920f8452882c4c327d30fef

cole, this is important to understand: you *do not* need to "understand"
what is "going on".  you do not need to read 1,300 page PDFs - in full -
memorised in their entirety - before being able to take action.

this can be extremely uncomfortable.  it feels... "unnatural", like,
"i should know everything because if i don't i might make a mistake or
implement the wrong thing".

sound familiar?

please understand: "understanding" != "action".

the trick that i learned - a long time ago, from doing reverse-engineering -
is to find someone else's *working* implementation, and *without*
understanding,
perform as direct a one-to-one translation as is humanly and conveniently
possible.

forget optimisation.

forget "understanding".

forget even *bug* fixes.

just... get... it... translated.

through that process, it turns out that by walking over the code (which you
quotes don't understand quotes), this puts that code into your brain.

**THEN** when you read the spec - the 1300 page PDF - you go, "ohhhh, yeahhh, i
recognise that.  that's those bits/flags/functions/insert-whatever that i saw
when i was reading and translating the code, line-by-line".

and *NOW* you have quotes understanding quotes.

without having taken that first step, i guarantee to you that you will get
nowhere, fast.


so just - and i mean this literally - translate the comments that i've put
from microwatt execute1.vhdl into nmigen.  you can see how Michael and i
did that already for both OP_TRAP and OP_MFMSR.

i deliberately inserted the original microwatt code even for those, so that
you have a direct side-by-side comparison, and can follow the adage
"A is to B, as C is to D".

you'll also need to translate the bit-patterns MSR_* - this again should be
obvious and easy.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #16 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
TODO: add OP_SC line but not exactly like it is done in microwatt:
it has to go in extra.csv so as to be able to detect (and exclude) scv.
this through bit 1 (actually bit 30 sigh) "if e_in.insn(1) = '1' then"

     17 =>       (ALU,    OP_SC,        NONE,       NONE,        NONE, NONE,
'0', '0', '0', '0', ZERO, '0', NONE, '0', '0', '0', '0', '0', '0', NONE, '0',
'0'), -- sc

so this would be something like:

17 in binary ------  bit 30 here
010001------------------------1-,TRAP,OP_SC,....,sc,NONE

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #17 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
Cole: example (A is to B, as C is to D).  examine case OP_TRAP and case OP_SC.

A:
                ctrl_tmp.irq_nia <= std_logic_vector(to_unsigned(16#C00#, 64));
                ctrl_tmp.srr1 <= msr_copy(ctrl.msr);

B:

                ????


C:
                    ctrl_tmp.irq_nia <= std_logic_vector(to_unsigned(16#700#,
64));
                    ctrl_tmp.srr1 <= msr_copy(ctrl.msr);

D:

                    comb += self.o.nia.data.eq(0x700)         # trap address
                    comb += self.o.nia.ok.eq(1)


it should be BLINDINGLY obvious that B should be:

                    comb += self.o.nia.data.eq(0xC00)         # trap address
                    comb += self.o.nia.ok.eq(1)


therefore, in switch statement OP_SC, that's what goes into that function.

and that's it.

ta-daaa.  OP_SC is completed.

wasn't that easy?

Q: do you understand or know what OP_SC is or does?
A: i don't... and don't care, and it is completely irrelevant to you, as well.

   (it's *optional* to have understanding: you may *desire* understanding,
    you may *like* to have understanding, but it is, fundamentally, *completely
    irrelevant* to the actual task)

Q: do we *need* to understand or know what OP_SC is or does?
A: no we do not.

Q: will it work?
A: yes it will.

Q: will there be bugs?
A: most probably, and those can be found with unit tests.

Q: do absolutely all the required unit tests have to be written *right now*?
A: no they do not.

Q: do we need to freeze and lock up solid in total fear at our total and
   complete lack of understanding just because those unit tests do not exist?
A: of course not.

so reading a 1300 page PDF is completely and utterly pointless.  and making
reading that 1300 page PDF a hard, fixed, absolute critical dependency on
*completing this task* is a false assumption, isn't it?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #18 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #15)
> https://git.libre-soc.org/?p=soc.git;a=commitdiff;
> h=2955619bc39a83b09920f8452882c4c327d30fef
> 
> cole, this is important to understand: you *do not* need to "understand"
> what is "going on".  you do not need to read 1,300 page PDFs - in full -
> memorised in their entirety - before being able to take action.
> 
> this can be extremely uncomfortable.  it feels... "unnatural", like,
> "i should know everything because if i don't i might make a mistake or
> implement the wrong thing".
> 
> sound familiar?
> 
> please understand: "understanding" != "action".
> 
> the trick that i learned - a long time ago, from doing reverse-engineering -
> is to find someone else's *working* implementation, and *without*
> understanding,
> perform as direct a one-to-one translation as is humanly and conveniently
> possible.
> 
> forget optimisation.
> 
> forget "understanding".
> 
> forget even *bug* fixes.
> 
> just... get... it... translated.
> 
> through that process, it turns out that by walking over the code (which you
> quotes don't understand quotes), this puts that code into your brain.
> 
> **THEN** when you read the spec - the 1300 page PDF - you go, "ohhhh,
> yeahhh, i
> recognise that.  that's those bits/flags/functions/insert-whatever that i saw
> when i was reading and translating the code, line-by-line".
> 
> and *NOW* you have quotes understanding quotes.
> 
> without having taken that first step, i guarantee to you that you will get
> nowhere, fast.
> 
> 
> so just - and i mean this literally - translate the comments that i've put
> from microwatt execute1.vhdl into nmigen.  you can see how Michael and i
> did that already for both OP_TRAP and OP_MFMSR.
> 
> i deliberately inserted the original microwatt code even for those, so that
> you have a direct side-by-side comparison, and can follow the adage
> "A is to B, as C is to D".
> 
> you'll also need to translate the bit-patterns MSR_* - this again should be
> obvious and easy.

With you all the way Luke, just needed this redirection/confidence boost.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #19 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #17)
> Cole: example (A is to B, as C is to D).  examine case OP_TRAP and case
> OP_SC.
> 
> A:
>                 ctrl_tmp.irq_nia <= std_logic_vector(to_unsigned(16#C00#,
> 64));
>                 ctrl_tmp.srr1 <= msr_copy(ctrl.msr);
> 
> B:
> 
>                 ????
> 
> 
> C:
>                     ctrl_tmp.irq_nia <=
> std_logic_vector(to_unsigned(16#700#, 64));
>                     ctrl_tmp.srr1 <= msr_copy(ctrl.msr);
> 
> D:
> 
>                     comb += self.o.nia.data.eq(0x700)         # trap address
>                     comb += self.o.nia.ok.eq(1)
> 
> 
> it should be BLINDINGLY obvious that B should be:
> 
>                     comb += self.o.nia.data.eq(0xC00)         # trap address
>                     comb += self.o.nia.ok.eq(1)
> 
> 
> therefore, in switch statement OP_SC, that's what goes into that function.
> 
> and that's it.
> 
> ta-daaa.  OP_SC is completed.
> 
> wasn't that easy?
> 
> Q: do you understand or know what OP_SC is or does?
> A: i don't... and don't care, and it is completely irrelevant to you, as
> well.
> 
>    (it's *optional* to have understanding: you may *desire* understanding,
>     you may *like* to have understanding, but it is, fundamentally,
> *completely
>     irrelevant* to the actual task)
> 
> Q: do we *need* to understand or know what OP_SC is or does?
> A: no we do not.
> 
> Q: will it work?
> A: yes it will.
> 
> Q: will there be bugs?
> A: most probably, and those can be found with unit tests.
> 
> Q: do absolutely all the required unit tests have to be written *right now*?
> A: no they do not.
> 
> Q: do we need to freeze and lock up solid in total fear at our total and
>    complete lack of understanding just because those unit tests do not exist?
> A: of course not.
> 
> so reading a 1300 page PDF is completely and utterly pointless.  and making
> reading that 1300 page PDF a hard, fixed, absolute critical dependency on
> *completing this task* is a false assumption, isn't it?

Very, very helpful. Indeed my false assumption was thankfully very false :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #20 from Cole Poirier <colepoirier@gmail.com> ---
Pushed a commit with my attempt at OP_RFID and OP_SC. Can you take a look at
OP_RFID because I found it hard and confusing to translate? Is the only
remaining TRAP instruction to be implemented OP_ADDPCIS? I see the pseudo code
here for it, but I cannot understand it. Should I look for it's implementation
in microwatt on github?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #21 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
 comb += self.o.msr.data.eq(Cat(b[63:31], b[26:22], b[15:0]))

this says "concatenate bits and put thrm into the LSBs of MSR".

look again at the VHDL.  it says, "transfer 3 sets of bits into their exact
same corresponding bit places.

also, python numbering is start:end+1

you have specified end:start

so the ranges are 0:16
22:27
31:64

make 3 separate assignments ok?



 comb += self.o.msr.ok.eq(a)


the ok field is 1 bit, saying "this reg is to be written".  by placing the LSB
of a into it (because msr.ok is only 1 wide), you end up with random situations
where the MSB will randomly get written.

msr.ok should be set to 1, to gyarantee it will be written.


also remember to translate this bit:

          if c_in(MSR_PR) = '1' then
 131                         ctrl_tmp.msr(MSR_EE) <= '1';
 132                         ctrl_tmp.msr(MSR_IR) <= '1';
 133                         ctrl_tmp.msr(MSR_DR) <= '1';



OP_SC looks great.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #22 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #21)
>  comb += self.o.msr.data.eq(Cat(b[63:31], b[26:22], b[15:0]))
> 
> this says "concatenate bits and put thrm into the LSBs of MSR".
> 
> look again at the VHDL.  it says, "transfer 3 sets of bits into their exact
> same corresponding bit places.
> 
> also, python numbering is start:end+1
> 
> you have specified end:start
> 
> so the ranges are 0:16
> 22:27
> 31:64
> 
> make 3 separate assignments ok?

Thanks, will do. 

> 
>  comb += self.o.msr.ok.eq(a)
> 
> 
> the ok field is 1 bit, saying "this reg is to be written".  by placing the
> LSB of a into it (because msr.ok is only 1 wide), you end up with random
> situations where the MSB will randomly get written.
> 
> msr.ok should be set to 1, to gyarantee it will be written.

Ah thank you that was a typo, had meant to put 1.

> also remember to translate this bit:
> 
>           if c_in(MSR_PR) = '1' then
>  131                         ctrl_tmp.msr(MSR_EE) <= '1';
>  132                         ctrl_tmp.msr(MSR_IR) <= '1';
>  133                         ctrl_tmp.msr(MSR_DR) <= '1';
> 
> 
> 
> OP_SC looks great.

Thanks. I'm not sure how to tranlate c_in and in OP_MTMSR this seems to be done
by just:

```
comb += self.o.msr.data.eq(a)
comb += self.o.msr.ok.eq(1)
```

Is this correct?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #23 from Cole Poirier <colepoirier@gmail.com> ---
Pushed a commit with your suggested fixes, however I don't think what I wrote
makes sense, but since I don't understand b_in and c_in I tried follow what you
did in OP_MTMSR.

Also, does OP_ADDPCIS need to be implemented? I cannot find it's implementation
in microwatt.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #24 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #23)
> Pushed a commit with your suggested fixes, however I don't think what I
> wrote makes sense, but since I don't understand b_in and c_in I tried follow
> what you did in OP_MTMSR.

:)

you're still thinking too much.  less brain, more automatonic robot :)

the bitassignnents look great.

however, with this:
                comb += self.o.msr.data.eq(b)
 171                 comb += self.o.msr.ok.eq(1)
 172 

you just trashed all the good work :)

lose those lines.


> Also, does OP_ADDPCIS need to be implemented? I cannot find it's
> implementation in microwatt.

correct, we leave it for now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #25 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
i added some more TODOs, and also translated the "if blah blah" in OP_MTMSR
which you can now look at and cookie-cut for OP_RFID.

also you missed srr1 in OP_SC.  remember to set srr1.ok.eq(1)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #26 from Cole Poirier <colepoirier@gmail.com> ---
Thanks for your assisstance, it made things much easier, and more robotic :)
I just pushed a new commit with your suggested changes. If this is now complete
is the next step writing unit tests?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #27 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #26)
> Thanks for your assisstance, it made things much easier, and more robotic :)
> I just pushed a new commit with your suggested changes. If this is now
> complete is the next step writing unit tests?

yes... but it's not complete.  every single line needs to be translated,
which means paying attention to every line.  it's quite... tedious.
you missed several: i highlighted them for you.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #28 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #22)

> Thanks. I'm not sure how to tranlate c_in

err... errr... that means *sigh* having to look at the CSV files and see if
reg c can be moved to reg a, for MTMSR.

b _definitely_ needs to be in position "b" - so that means that in OP_RFID
this needs to be b not a:
     comb += self.o.msr.data[stt:end].eq( --->a<---- [stt:end])


> and in OP_MTMSR this seems to be
> done by just:
> 
> ```
> comb += self.o.msr.data.eq(a)
> comb += self.o.msr.ok.eq(1)
> ```
> 
> Is this correct?

it is... but we need to check minor_31.csv - ah:
0b0010110010,ALU,OP_MTMSRD,NONE,NONE,RS,NONE

that's wrong.  it says "RS goes into reg c" and if you look at
fu/trap/pipe_data.py
we don't *have* an rs.

so i'll go ahead and change that to:

0b0010110010,ALU,OP_MTMSRD,RS,NONE,NONE,NONE

and that will put RS into *a* (which we have)

gimme 1 sec...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #29 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #28)

> 0b0010110010,ALU,OP_MTMSRD,RS,NONE,NONE,NONE
> 
> and that will put RS into *a* (which we have)
> 
> gimme 1 sec...

commit 7e32307f763f693a405a5d1691fb23894bcd3be3 (HEAD -> master, origin/master)
Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date:   Wed Jun 3 02:39:29 2020 +0100

    update submodule for ISA tables


done, do make sure to do a "git submodule update" and make sure
"git submodule" reports this:
1970241a6db97d4ace1e053e72f2a3d9462e98b2 libreriscv

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #30 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
oo... errr... do another git pull - i added this:

                # L = self.fields.FormXL[0:-1]
                # if e_in.insn(16) = '1' then  <-- this is X-form field "L".

so rather than "with m.If(insn[16]):"

you want: "with m.If(L):"

ok?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #31 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #27)
> (In reply to Cole Poirier from comment #26)
> > Thanks for your assisstance, it made things much easier, and more robotic :)
> > I just pushed a new commit with your suggested changes. If this is now
> > complete is the next step writing unit tests?
> 
> yes... but it's not complete.  every single line needs to be translated,
> which means paying attention to every line.  it's quite... tedious.
> you missed several: i highlighted them for you.

Thanks for the help!!

Ok, I *think* I have made the necessary changes. Just pushed a commit. I'll
take a look at your comments and make any new recommended changes in the
morning.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #32 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
-                # TODO translate this, import and use br_ext from branch stage
-                # f_out.redirect_nia <= a_in(63 downto 2) & "00"; -- srr0
+                comb += self.o.nia.data.eq(br_ext(a[63:1] & 0))
+                comb += self.o.nia.ok.eq(1)

br_ext already adds the 2 zeros.  & in vhdl means "concatenate".  however they
go MSB -> LSB order, python is LSB->MSB order

                comb += self.o.nia.data.eq(br_ext(a[2:]))

you removed all of these, please do put them back:

-        a_i, b_i, cia_i, msr_i = self.i.a, self.i.b, self.i.cia, self.i.msr
-        o, msr_o, nia_o = self.o.o, self.o.msr, self.o.nia
-        srr0_o, srr1_o = self.o.srr0, self.o.srr1
+        a_i, b_i = self.i.a, self.i.b


-                #     -- just update EE and RI
-                #     ctrl_tmp.msr(MSR_EE) <= c_in(MSR_EE);
-                #     ctrl_tmp.msr(MSR_RI) <= c_in(MSR_RI);
+                L = self.fields.FormX.L[0:-1]
+                with m.If(L):
+                    comb += self.o.msr[MSR_EE].eq(self.i.msr[MSR_EE])
+                    comb += self.o.msr[MSR_RI].eq(self.i.msr[MSR_RI])
+

here, this is copying the incoming MSR into the outgoing MSR.  that's
just wasting time.    look again: it says c_in, and we discussed that
this is to be moved in comment #28 to "a".

also, those defines MSR_xx do not exist.  note the comment at the top:
# TODO: turn these into python constants (just "MSR_SF = 63-0 # comment" etc.)
"""
    Listed in V3.0B Book III Chap 4.2.1
    -- MSR bit numbers
    constant MSR_SF  : integer := (63 - 0);     -- Sixty-Four bit mode
....
"""

i'm leaving it to you to create those constants.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #33 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #32)
> -                # TODO translate this, import and use br_ext from branch
> stage
> -                # f_out.redirect_nia <= a_in(63 downto 2) & "00"; -- srr0
> +                comb += self.o.nia.data.eq(br_ext(a[63:1] & 0))
> +                comb += self.o.nia.ok.eq(1)
> 
> br_ext already adds the 2 zeros.  & in vhdl means "concatenate".  however
> they
> go MSB -> LSB order, python is LSB->MSB order
> 
>                 comb += self.o.nia.data.eq(br_ext(a[2:]))

I see. Thank you I will make this fix next...

> you removed all of these, please do put them back:
> 
> -        a_i, b_i, cia_i, msr_i = self.i.a, self.i.b, self.i.cia, self.i.msr
> -        o, msr_o, nia_o = self.o.o, self.o.msr, self.o.nia
> -        srr0_o, srr1_o = self.o.srr0, self.o.srr1
> +        a_i, b_i = self.i.a, self.i.b
> 
> 
> -                #     -- just update EE and RI
> -                #     ctrl_tmp.msr(MSR_EE) <= c_in(MSR_EE);
> -                #     ctrl_tmp.msr(MSR_RI) <= c_in(MSR_RI);
> +                L = self.fields.FormX.L[0:-1]
> +                with m.If(L):
> +                    comb += self.o.msr[MSR_EE].eq(self.i.msr[MSR_EE])
> +                    comb += self.o.msr[MSR_RI].eq(self.i.msr[MSR_RI])
> +
> 
> here, this is copying the incoming MSR into the outgoing MSR.  that's
> just wasting time.    look again: it says c_in, and we discussed that
> this is to be moved in comment #28 to "a".

Yes, sorry, I found that part confusing, and misinterpreted your change of the
csv to mean that this change was unnecessary, will fix this next next.

> also, those defines MSR_xx do not exist.  note the comment at the top:
> # TODO: turn these into python constants (just "MSR_SF = 63-0 # comment"
> etc.)
> """
>     Listed in V3.0B Book III Chap 4.2.1
>     -- MSR bit numbers
>     constant MSR_SF  : integer := (63 - 0);     -- Sixty-Four bit mode
> ....
> """
> 
> i'm leaving it to you to create those constants.

I did this, and restored the convenience variables, and restored the deleted
VHDL comments. It should be in the right state now, so I can move on to making
the two above, next, and next next changes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #34 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
> go MSB -> LSB order, python is LSB->MSB order

sorry, that should be "python is LSB->MSB+1" order.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #35 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #34)
> > go MSB -> LSB order, python is LSB->MSB order
> 
> sorry, that should be "python is LSB->MSB+1" order.

I think everything has been brought into line with your suggestions. Please
take a look and let me know if I've made a mistake, I'm specifically not
confident about my putting 'comb += nia_o.data.eq(br_ext(a_i[2:]))' on line
193, in OP_MFMSR.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #36 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
 153                 with m.If(L):
 154                     comb += msr_o[MSR_EE].eq(msr_i[MSR_EE])
 155                     comb += msr_o[MSR_RI].eq(msr_i[MSR_RI])
 156 

look again at the VHDL. it inputs from c_in.  we assigned a_i to that.

here instead the copy is ciming from the incoming msr (msr_i).  clearly thus is
wrong.

line by line.

compare, literally, by putting two fingers pointing one at the VHDL and the
other at the nmigen code, like you are 5 years old learning to read, if you
have to!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #37 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
 197                 with m.If(a[MSR_PR]):
 198                         msr_o[MSR_EE].eq(1)
 199                         msr_o[MSR_IR].eq(1)

bug.  line 187 says "b_in" doesn't it? so why is a (a variable that does not
exist) being tested at line 197?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #38 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
i'm looking at the 3.0B pseudocode for OP_SC and going "hmmm".

SC-Form

* sc LEV

    SRR0 <-iea CIA + 4
    SRR1[33:36] <- 0
    SRR1[42:47] <- 0
    SRR1[0:32]  <- MSR[0:32] 
    SRR1[37:41] <- MSR[37:41]
    SRR1[48:63] <- MSR[48:63]
    MSR <- new_value 
    NIA <- 0x0000_0000_0000_0C00

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #39 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #38)
> i'm looking at the 3.0B pseudocode for OP_SC and going "hmmm".
> 
> SC-Form
> 
> * sc LEV
> 
>     SRR0 <-iea CIA + 4

looking at what OP_TRAP does i think we need these 2 extra lines in OP_ SC:

      comb += srr0_o.data.eq(cia_i+4)   # old PC
      comb += srr0_o.ok.eq(1)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #40 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
OP_RFID POWER9 3.0B pseudocode also has this:

    NIA <-iea SRR0[0:61] || 0b00

oooooo ngggh ok.  so in microwatt they are inputting SRR0 from a_in, and SRR1
from b_in.

we are not going to do that.

so in these lines 193 to 197:

 193                 comb += nia_o.data.eq(br_ext(a_i[2:]))
 194                 comb += nia_o.ok.eq(1)
 195                 for stt, end in [(0,16), (22, 27), (31, 64)]:
 196                     comb += msr_o.data[stt:end].eq(b_i[stt:end])
 197                 with m.If(a[MSR_PR]):

substitute srr0_i for a_i (and a at line 197) and srr1_i for b_i

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #41 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/power_decoder2.py;hb=HEAD

for OP_SC, OP_RFID and OP_TRAP we need to set the fast spr fields in DecodeA,
DecodeB and so on, so that the fields are correctly set.

this may involve the CSV files, putting the information there.

example: OP_TRAP needs to output SRR0, therefore DecodeOut needs to set
fast_out to SRR0 when the opcode is OP_TRAP.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #42 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
from microwatt decode1.vhdl

elsif v.decode.insn_type = OP_RFID then
    report "PPC RFID";
    v.ispr1 := fast_spr_num(SPR_SRR0);
    v.ispr2 := fast_spr_num(SPR_SRR1);
end if;

that's what needs to go in PowerDecode2

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #43 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #42)
> from microwatt decode1.vhdl
> 
> elsif v.decode.insn_type = OP_RFID then
>     report "PPC RFID";
>     v.ispr1 := fast_spr_num(SPR_SRR0);
>     v.ispr2 := fast_spr_num(SPR_SRR1);
> end if;
> 
> that's what needs to go in PowerDecode2

done.  DecodeOut --> SRR0, DecodeOut2 --> SRR1

so.

when the TRAP pipeline is called, SRR0 will go into spr1, SRR1 will go into
spr2.



--- a/src/soc/decoder/power_decoder2.py
+++ b/src/soc/decoder/power_decoder2.py
@@ -241,6 +241,12 @@ class DecodeOut(Elaboratable):
             with m.If(~self.dec.BO[2]): # 3.0B p38 BO2=0, use CTR reg
                 comb += self.fast_out.data.eq(FastRegs.CTR) # constant: CTR
                 comb += self.fast_out.ok.eq(1)
+
+        # RFID 1st spr (fast)
+        with m.If(op.internal_op == InternalOp.OP_RFID):
+                comb += self.fast_out.data.eq(FastRegs.SRR0) # constant: SRR0
+                comb += self.fast_out.ok.eq(1)
+
         return m


@@ -275,6 +281,11 @@ class DecodeOut2(Elaboratable):
                 comb += self.fast_out.data.eq(FastRegs.LR) # constant: LR
                 comb += self.fast_out.ok.eq(1)

+        # RFID 2nd spr (fast)
+        with m.If(op.internal_op == InternalOp.OP_RFID):
+                comb += self.fast_out.data.eq(FastRegs.SRR1) # constant: SRR1
+                comb += self.fast_out.ok.eq(1)
+
         return m

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #44 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
i added a version of msr_copy, and this version it has the option to
zero the destination msr or not.  so unlike in the comments, it *can*
be used in OP_RFID.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #45 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
 184                     with m.If(a[MSR_PR]):
 185                             msr_o[MSR_EE].eq(1)
 186                             msr_o[MSR_IR].eq(1)
 187                             msr_o[MSR_DR].eq(1)

should be msr_o.data

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #46 from Cole Poirier <colepoirier@gmail.com> ---
Ok. I think now the nmigen should match the microwatt VHDL, however, there may
be small errors as you made some modifications but left others for me to fix,
and I got confused about some of your comments re a_i, b_i, but I did my best
to interpret your comments while reading, line-by-line the vhdl from the
comments.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #47 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
this is going to be a mess.

mtmsr pseudocode:

if L = 0 then
    MSR48 <- (RS)48 | (RS)49
    MSR58 <- ((RS)58 | (RS)49)
        & ¬(MSR41 & MSR3 & (¬(RS)49))
    MSR59 <- ((RS)59 | (RS)49)
        & ¬(MSR41 & MSR3 & (¬(RS)49))
    MSR32:40 42:47 49:50 52:57 60:62
       (RS)32:40 42:47 49:50 52:57 60:62
else:
    MSR48 62 <- (RS)48 62

i forgot to add the pseudocode from mtmsr and mfmsr to the isa markdown
files.  the above is note-form from the 3.0B PDF

mfmsr:

RT <- MSR

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #48 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
just did some updates/comments so we can see what's going on, in english.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #49 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #48)
> just did some updates/comments so we can see what's going on, in english.

Appreciated, significantly clearer than it was before. Looking at the code, it
seems to be in line with the VHDL in the comments. One question, what does '#
XXX which bit?' on line 147 refer to?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #50 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #46)
> Ok. I think now the nmigen should match the microwatt VHDL, however, there
> may be small errors as you made some modifications but left others for me to
> fix, and I got confused about some of your comments re a_i, b_i, but I did
> my best to interpret your comments while reading, line-by-line the vhdl from
> the comments.

microwatt decided to use a_in, b_in and c_in as the input lines for *SPRs*.

we are not going to do that.

therefore all places where SPRs are inputs, the names need to *be* SRR0,
*be* SRR1, *NOT* a_i, b_i, c_i.

however - some of the instructions *DO TAKE REGISTERS AS INPUT*.
see section 5.4.3, "mtmsr" for example: this takes a *REGISTER* (RS)
as the input, and moves it to the MSR (as output)

whereas OP_RFID, you can see clearly the pseudocode says:

  nia <= SRR0
  msr <= SRR1

however microwatt has this:

  nia <- a_in
  msr <- b_in

this is obviously a design decision that WE ARE NOT GOING TO COPY.

where they must have done this:

  a_in <- SRR0
  b_in <- SRR1

and then and only then could this microwatt code succeed:

  nia <- a_in
  msr <- b_in

we are **NOT** repeat **NOT** going to re-purpose register file lanes.
we have *SEPARATE* lanes for SPRs, *SEPARATE* lanes for integer registers.

if we were to copy what microwatt have done we would need full data-routing
crossbars in front of the register file ports to get data from the SPR
register files over to the integer inputs on the TRAP pipeline.

in an out-of-order system such "hacks" creates a severe architectural problem
for
Dependency Tracking and Management.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #51 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
i've removed the microwatt pseudocode because it now serves no purpose.
with microwatt using a_in, b_in and c_in as overloaded-lanes for incoming
SPRs, it it no longer useful.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #52 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #51)
> i've removed the microwatt pseudocode because it now serves no purpose.
> with microwatt using a_in, b_in and c_in as overloaded-lanes for incoming
> SPRs, it it no longer useful.

Looks good. What can I do now. Is there something left to be done here or
should I move on to another pipeline? I apologize, I cannot determine this for
myself by looking at fu/trap/main_stage.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #53 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #52)
> (In reply to Luke Kenneth Casson Leighton from comment #51)
> > i've removed the microwatt pseudocode because it now serves no purpose.
> > with microwatt using a_in, b_in and c_in as overloaded-lanes for incoming
> > SPRs, it it no longer useful.
> 
> Looks good. What can I do now. Is there something left to be done here or
> should I move on to another pipeline? 

> I apologize, I cannot determine this
> for myself by looking at fu/trap/main_stage.

nono, i've already started referencing the PDF.

two things (on this bugreport):

1) make a test_pipe_caller.py and remaining data structures/code.  (cookie-cut
an existing one, delete all the switch statements).  don't overwrite
pipe_data.py.  do cookie-cut a trap_input_data.py (cr_input_record.py)

2) add the pseudocode to sprset.mdwn (yes sprset.mdwn is a bad name) from
comment #47

https://libre-soc.org/openpower/isa/sprset/

or if you're bored of this one for a while, move on to
https://bugs.libre-soc.org/show_bug.cgi?id=348

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #54 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #47)
> this is going to be a mess.
> 
> mtmsr pseudocode:
> 
> if L = 0 then
>     MSR48 <- (RS)48 | (RS)49
>     MSR58 <- ((RS)58 | (RS)49)
>         & ¬(MSR41 & MSR3 & (¬(RS)49))
>     MSR59 <- ((RS)59 | (RS)49)
>         & ¬(MSR41 & MSR3 & (¬(RS)49))
>     MSR32:40 42:47 49:50 52:57 60:62
>        (RS)32:40 42:47 49:50 52:57 60:62
> else:
>     MSR48 62 <- (RS)48 62
> 
> i forgot to add the pseudocode from mtmsr and mfmsr to the isa markdown
> files.  the above is note-form from the 3.0B PDF
> 
> mfmsr:
> 
> RT <- MSR

Luke, in order to complete task 2 of your last comment, should this be added
with the note 'Note-Form from the 3.0B PDF' instead of 'X-Form' or 'XFX-Form'?

Additionally should the pseudo code for OP_SC from comment 38 be added to
sprset.mdwn as well?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #55 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #54)
> (In reply to Luke Kenneth Casson Leighton from comment #47)
> > this is going to be a mess.
> > 
> > mtmsr pseudocode:
> > 
> > if L = 0 then
> >     MSR48 <- (RS)48 | (RS)49
> >     MSR58 <- ((RS)58 | (RS)49)
> >         & ¬(MSR41 & MSR3 & (¬(RS)49))
> >     MSR59 <- ((RS)59 | (RS)49)
> >         & ¬(MSR41 & MSR3 & (¬(RS)49))
> >     MSR32:40 42:47 49:50 52:57 60:62
> >        (RS)32:40 42:47 49:50 52:57 60:62
> > else:
> >     MSR48 62 <- (RS)48 62
> > 
> > i forgot to add the pseudocode from mtmsr and mfmsr to the isa markdown
> > files.  the above is note-form from the 3.0B PDF
> > 
> > mfmsr:
> > 
> > RT <- MSR
> 
> Luke, in order to complete task 2 of your last comment, should this be added
> with the note 'Note-Form from the 3.0B PDF' instead of 'X-Form' or
> 'XFX-Form'?

whatever is in the PDF from the spec.  the format however has to be *exactly*
like the others, down to the linebreaks, because it is machine readable.

see pywriter.py,in the top level Makefile.

so you can test it before committing

> 
> Additionally should the pseudo code for OP_SC from comment 38 be added to
> sprset.mdwn as well?

grep sc or scv *.mdwn and you'll find those are in system.mdwn already.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #56 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #55)
> whatever is in the PDF from the spec.  the format however has to be
> *exactly* like the others, down to the linebreaks, because it is machine
> readable.
> 
> see pywriter.py,in the top level Makefile.
> 
> so you can test it before committing

Apologies Luke, after 20 minutes of checking and rechecking the psuedo code
against the PDF and making lots of small modifications I am unable to get
pywriter to complete. It errors with the following stack trace, I think I
require your assistance.

```
UnusedElaboratable: Enable tracemalloc to get the object allocation traceback
[None, <_ast.Name object at 0x7f19c3d02320>, '=', <_ast.Constant object at
0x7f19c3d02358>]
Traceback (most recent call last):
  File "src/soc/decoder/pseudo/pywriter.py", line 135, in <module>
    isa.write_pysource(source)
  File "src/soc/decoder/pseudo/pywriter.py", line 58, in write_pysource
    pycode, rused = convert_to_python(pcode, d.form)
  File "/home/colepoirier/src/soc/src/soc/decoder/power_pseudo.py", line 219,
in convert_to_python
    tree = gsc.compile(pcode, mode="exec", filename="string")
  File "/home/colepoirier/src/soc/src/soc/decoder/pseudo/parser.py", line 797,
in compile
    tree = self.parser.parse(code)
  File "/home/colepoirier/src/soc/src/soc/decoder/pseudo/parser.py", line 784,
in parse
    result = self.parser.parse(code, lexer=self.lexer, debug=self.debug)
  File "/usr/local/lib/python3.7/dist-packages/ply-3.11-py3.7.egg/ply/yacc.py",
line 333, in parse
    return self.parseopt_notrack(input, lexer, debug, tracking, tokenfunc)
  File "/usr/local/lib/python3.7/dist-packages/ply-3.11-py3.7.egg/ply/yacc.py",
line 1201, in parseopt_notrack
    tok = call_errorfunc(self.errorfunc, errtoken, self)
  File "/usr/local/lib/python3.7/dist-packages/ply-3.11-py3.7.egg/ply/yacc.py",
line 192, in call_errorfunc
    r = errorfunc(token)
  File "/home/colepoirier/src/soc/src/soc/decoder/pseudo/parser.py", line 767,
in p_error
    raise SyntaxError(p)
SyntaxError: LexToken(NUMBER,48,2,29)
```

I cannot identify what in my current pseudo-code is causing this problem:

```
 # Move To Machine State Register

 X-Form

 * mtmsr RS,L

     if L = 0 then
       MSR48 <- (RS)48 | (RS)49
       MSR58 <- ((RS)58 | (RS)49)
         & ¬(MSR41 & MSR3 & (¬(RS)49))
       MSR59 <- ((RS)59 | (RS)49)
         & ¬(MSR41 & MSR3 & (¬(RS)49))
       MSR32:40 42:47 49:50 52:57 60:62
         <- (RS)32:40 42:47 49:50 52:57 60:62
     else
       MSR48 62 <- (RS)48 62

 Special Registers Altered:

     MSR

 # Move From Machine State Register

 X-Form

 * mfmsr RT

     RT <- MSR

 Special Registers Altered:

     None

```

> 
> > 
> > Additionally should the pseudo code for OP_SC from comment 38 be added to
> > sprset.mdwn as well?
> 
> grep sc or scv *.mdwn and you'll find those are in system.mdwn already.

Ah yes thank you, I mistakenly thougt OP_SC because I worked on it at the same
time as MTMSR and MFMSR belonged to sprset not system.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #57 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #53)
> two things (on this bugreport):
> 
> 1) make a test_pipe_caller.py and remaining data structures/code. 
> (cookie-cut an existing one, delete all the switch statements).  don't
> overwrite pipe_data.py.  do cookie-cut a trap_input_data.py
> (cr_input_record.py)

This is done. Should I start trying to figure out how to write these unit tests
using fu/cr/test/test_pipe_caller as a guide? Or if this will be outside of my
current capacity, should I move on to bug #348?

> 2) add the pseudocode to sprset.mdwn (yes sprset.mdwn is a bad name) from
> comment #47
> 
> https://libre-soc.org/openpower/isa/sprset/

Waiting on your help with this one, I figured I shouldn't waste more time on it
given that it's likely something that you're capable of identifying and fixing
in a matter of seconds because you understand the parser completely.

> or if you're bored of this one for a while, move on to
> https://bugs.libre-soc.org/show_bug.cgi?id=348

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #58 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #56)
> (In reply to Luke Kenneth Casson Leighton from comment #55)
> > whatever is in the PDF from the spec.  the format however has to be
> > *exactly* like the others, down to the linebreaks, because it is machine
> > readable.
> > 
> > see pywriter.py,in the top level Makefile.
> > 
> > so you can test it before committing
> 
> Apologies Luke, after 20 minutes of checking and rechecking the psuedo code
> against the PDF and making lots of small modifications I am unable to get
> pywriter to complete. It errors with the following stack trace, I think I
> require your assistance.

yep, the pseudo-language is not documented, it's one of those things you
have to look at other scripts and just work it out by inference.

do a git pull on the libre-soc.org repo, i added the code to it there,
you should find it works.

one thing: you had a space in front of every line.  that would not have worked:
the parser was written very very quickly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #59 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #57)
> (In reply to Luke Kenneth Casson Leighton from comment #53)
> > two things (on this bugreport):
> > 
> > 1) make a test_pipe_caller.py and remaining data structures/code. 
> > (cookie-cut an existing one, delete all the switch statements).  don't
> > overwrite pipe_data.py.  do cookie-cut a trap_input_data.py
> > (cr_input_record.py)
> 
> This is done. Should I start trying to figure out how to write these unit
> tests using fu/cr/test/test_pipe_caller as a guide?

yes sure.  although bear in mind that only the instructions which are supported
in the emulator will work.

> Or if this will be
> outside of my current capacity, should I move on to bug #348?

generally speaking if there are several tasks which you can do, just
do another if you're blocked: don't wait to ask, just do it.

> > 2) add the pseudocode to sprset.mdwn (yes sprset.mdwn is a bad name) from
> > comment #47
> > 
> > https://libre-soc.org/openpower/isa/sprset/
> 
> Waiting on your help with this one, I figured I shouldn't waste more time on
> it given that it's likely something that you're capable of identifying and
> fixing in a matter of seconds because you understand the parser completely.

actually i don't: it has been several months, and i wrote it very fast,
to perform a minimal job!

i've done a git push on the libre-soc repo you should be able to retry.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #60 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
 161                     with m.If(a_i[MSR_PR]):
 162                         msr_o.data[MSR_EE].eq(1)
 163                         msr_o.data[MSR_IR].eq(1)
 164                         msr_o.data[MSR_DR].eq(1)

and at line 185 comb += is missing

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #61 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #58)
> yep, the pseudo-language is not documented, it's one of those things you
> have to look at other scripts and just work it out by inference.
> 
> do a git pull on the libre-soc.org repo, i added the code to it there,
> you should find it works.
> 
> one thing: you had a space in front of every line.  that would not have
> worked:
> the parser was written very very quickly.

Ah that's just when I pasted it here (I'm 90% sure), not in the file, for some
reason buzilla likes to prepend a space when I'm pasting code here.

(In reply to Luke Kenneth Casson Leighton from comment #59)
> (In reply to Cole Poirier from comment #57)
> > This is done. Should I start trying to figure out how to write these unit
> > tests using fu/cr/test/test_pipe_caller as a guide?
> 
> yes sure.  although bear in mind that only the instructions which are
> supported
> in the emulator will work.

Oh interesting, is this our fork of gem5? Or is this  the one that is generated
from parsing the csv files? I recall this being discussed on list but I can't
remember which one we are currently using.

> > Or if this will be
> > outside of my current capacity, should I move on to bug #348?
> 
> generally speaking if there are several tasks which you can do, just
> do another if you're blocked: don't wait to ask, just do it.

Don't worry, like 'waiting days or hours between commits' this is a bad habit
you helped me break a few weeks ago. I ended up working on Systemes Libres
stuff with Yehowshua for Wednesday's meeting. I'll be leaving this bug for now,
to work on bug #348. After I finish the pseudo-code translation for that, I
plan come back to do the unit tests for this, unless, as often happens with the
project, plans change.

> > > 2) add the pseudocode to sprset.mdwn (yes sprset.mdwn is a bad name) from
> > > comment #47
> > > 
> > > https://libre-soc.org/openpower/isa/sprset/
> > 
> > Waiting on your help with this one, I figured I shouldn't waste more time on
> > it given that it's likely something that you're capable of identifying and
> > fixing in a matter of seconds because you understand the parser completely.
> 
> actually i don't: it has been several months, and i wrote it very fast,
> to perform a minimal job!
> 
> i've done a git push on the libre-soc repo you should be able to retry.

Hmm yes, looking at the pseudo-code you've written there is no way I would have
figured out all of the necessary modifications to the spec pseudo code needed
to get the parser to validate it. Thanks for doing this for me, with this
knowledge I think I'll be able to do it solo next time.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #62 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---

> (In reply to Luke Kenneth Casson Leighton from comment #59)
> > (In reply to Cole Poirier from comment #57)
> > > This is done. Should I start trying to figure out how to write these unit
> > > tests using fu/cr/test/test_pipe_caller as a guide?
> > 
> > yes sure.  although bear in mind that only the instructions which are
> > supported
> > in the emulator will work.
> 
> Oh interesting, is this our fork of gem5?

no

> Or is this  the one that is
> generated from parsing the csv files?

yes.  hence the need for the pseudocode.  until that exists there *is* no mfmsr
(etc) to test against!

in this case even the TRAP function has to be written.

this would (in python) move the SPRs about, set NIA to 0x700 blah blah.


> > > Or if this will be
> > > outside of my current capacity, should I move on to bug #348?
> > 
> > generally speaking if there are several tasks which you can do, just
> > do another if you're blocked: don't wait to ask, just do it.
> 
> Don't worry, like 'waiting days or hours between commits' this is a bad
> habit you helped me break a few weeks ago.

:)


> > i've done a git push on the libre-soc repo you should be able to retry.
> 
> Hmm yes, looking at the pseudo-code you've written there is no way I would
> have figured out all of the necessary modifications to the spec pseudo code
> needed to get the parser to validate it. Thanks for doing this for me, with
> this knowledge I think I'll be able to do it solo next time.

cool.

the syntax is python-indented (that was a pig to implement), and borrowed
python concepts such as brackets.  i replaced operators such as = with <- and
so on.

subscripted ranges were obviously not possible to do in ASCII so i did straight
brackets python slices but kept the POWER numbering.

so the translator pushes an extra +1 out on the "end" of the slice.

you saw that when doing bperm.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #63 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #60)
>  161                     with m.If(a_i[MSR_PR]):
>  162                         msr_o.data[MSR_EE].eq(1)
>  163                         msr_o.data[MSR_IR].eq(1)
>  164                         msr_o.data[MSR_DR].eq(1)
> 
> and at line 185 comb += is missing

fixed

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #64 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #62)
> > Or is this  the one that is
> > generated from parsing the csv files?
> 
> yes.  hence the need for the pseudocode.  until that exists there *is* no
> mfmsr (etc) to test against!
> 
> in this case even the TRAP function has to be written.
> 
> this would (in python) move the SPRs about, set NIA to 0x700 blah blah.

This makes so much sense now and is very, very cool! Especially in light of
your comments from comment #59 "actually i don't [completely understand
pywriter.py]: it has been several months, and i wrote it very fast,
to perform a minimal job!"

Regarding your comment on today's kanban daily update, "put a preliminary
version of mtmsr into the mdwn for Cole to check", how do I go about checking
the mdwn pseudo code with the emulator and the nmigen module?

> the syntax is python-indented (that was a pig to implement), and borrowed
> python concepts such as brackets.  i replaced operators such as = with <-
> and so on.
> 
> subscripted ranges were obviously not possible to do in ASCII so i did
> straight brackets python slices but kept the POWER numbering.
> 
> so the translator pushes an extra +1 out on the "end" of the slice.
> 
> you saw that when doing bperm.

Thanks this helps me understand the 'problem' even better than I did from your
earlier comments. Also very ingenious.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #65 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #63)
> (In reply to Luke Kenneth Casson Leighton from comment #60)
> >  161                     with m.If(a_i[MSR_PR]):
> >  162                         msr_o.data[MSR_EE].eq(1)
> >  163                         msr_o.data[MSR_IR].eq(1)
> >  164                         msr_o.data[MSR_DR].eq(1)
> > 
> > and at line 185 comb += is missing
> 
> fixed

superb.  i moved that to a separate function (msr_check_pr) because
it's duplicated.  note that i used the fact that in *both* cases,
the m.If() check comes from the argument that just got copied.

   comb += msr_o.data.eq(a_i)
   with m.If(a_i[MSR_PR]):

is exactly the same as:

   comb += msr_o.eq(a_i)
   with m.If(msr_o[MSR_PR]):

and therefore it is not necessary to pass a_i *and* msr_o into
msr_check_pr().

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #66 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #65)
> superb.  i moved that to a separate function (msr_check_pr) because
> it's duplicated.  note that i used the fact that in *both* cases,
> the m.If() check comes from the argument that just got copied.
> 
>    comb += msr_o.data.eq(a_i)
>    with m.If(a_i[MSR_PR]):
> 
> is exactly the same as:
> 
>    comb += msr_o.eq(a_i)
>    with m.If(msr_o[MSR_PR]):
> 
> and therefore it is not necessary to pass a_i *and* msr_o into
> msr_check_pr().

Fantatsic!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #67 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #64)
> (In reply to Luke Kenneth Casson Leighton from comment #62)
> > > Or is this  the one that is
> > > generated from parsing the csv files?
> > 
> > yes.  hence the need for the pseudocode.  until that exists there *is* no
> > mfmsr (etc) to test against!
> > 
> > in this case even the TRAP function has to be written.
> > 
> > this would (in python) move the SPRs about, set NIA to 0x700 blah blah.
> 
> This makes so much sense now and is very, very cool! Especially in light of
> your comments from comment #59 "actually i don't [completely understand
> pywriter.py]: it has been several months, and i wrote it very fast,
> to perform a minimal job!"
> 
> Regarding your comment on today's kanban daily update, "put a preliminary
> version of mtmsr into the mdwn for Cole to check", how do I go about
> checking the mdwn pseudo code with the emulator and the nmigen module?

in the libreriscv submodule first to "git pull origin master" - watch out
because submodules are a pain - then you can generate the emulator code.

run pywriter.py (see top-level Makefile).  then - and only then - will
the simulator "understand" mtmsr.

you can inspect the results by looking at... errr... what did we say
it was added to?  sprset.mdwn?

so... pywriter.py will.. err.. put that into... 1sec....
soc/decoder/isa/sprset.py

[btw do *NOT* "git add" that to the repository (it's auto-generated.  we
 do *NOT* add auto-generated files to the git repository, because they
 change).]

example:  mcrxrx, from the sprset.mdwn file

* mcrxrx BF

    CR[4*BF+32:4*BF+35] <-  XER[OV] || XER[OV32] || XER[CA] || XER[CA32]

---> is translated to, in sprset.py --->

    @inject()
    def op_mcrxrx(self, CR):
        CR[4 * BF + 32:4 * BF + 35 + 1] = concat(XER[OV], XER[OV32], XER[CA],
XER[CA32]
            )
        return (CR,)


at that point, you *should* be able to add something to
soc/fu/trap/test/test_pipe_caller.py in class TrapTestCase

which i see you deleted all the unit tests (i usually leave one
in there on cookie-cutting so that it's less typing when it comes
to creating one.  now you will have to re-open one of the
test_pipe_caller.py files to cut/paste an example from.  this is
more work for you)


here's the thing: it is highly likely that op_trap() from sprset.py
will fail.  this because it's literally the first time that the emulator
has ever seen the "trap" instruction, and that code also has to be written.

do not let this stop you from actually writing the unit test!

the unit test *is* the way to highlight that the code needs to be written!
[this is called test-driven development]
https://en.wikipedia.org/wiki/Test-driven_development


> > so the translator pushes an extra +1 out on the "end" of the slice.
> > 
> > you saw that when doing bperm.
> 
> Thanks this helps me understand the 'problem' even better than I did from
> your earlier comments. Also very ingenious.

just lazy :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #68 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
actually... cole, can you do the same thing as i just did with msr_check_pr()
create a function called trap(m, addr, nia)?

except this time it is a member function of the class, so trap(self, m, addr,
nia)

and just as you see i redid comb=m.d.comb in msr_check_pr, repeat/copy the
convenience variables that allow you to set self.o.nia etc etc

the reason for making this function is because you can see it is used twice
already.

also i am thinking it may be a good idea to add the address (0x700, etc)
actually to the trap_input_record and pass it in from the *decode* phase.

that would allow us to do exceptions in a micro-code fashion, and also when it
comes to illegal instructions or privileged ones, in the *decode* phase
(PowerDecoder2) we *CHANGE* the opcode from whatever it is from the incoming
instruction, into an OP_TRAP, set the trap address to 0x700 (or whatever)
manually, and let the trap pipeline execute it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #69 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
see https://bugs.libre-soc.org/show_bug.cgi?id=325#c8

there, the only difference between OP_TRAP and that code is: one of the bits of
SRR is changed (to indicate "priv execution")

we can pass that in as a flag to CompTrapOpSubset, and change the instruction
to OP_TRAP.

illegal instruction trap happens. ta-daaa

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #70 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #67)
> in the libreriscv submodule first to "git pull origin master" - watch out
> because submodules are a pain - then you can generate the emulator code.
> 
> run pywriter.py (see top-level Makefile).  then - and only then - will
> the simulator "understand" mtmsr.
> 
> you can inspect the results by looking at... errr... what did we say
> it was added to?  sprset.mdwn?
> 
> so... pywriter.py will.. err.. put that into... 1sec....
> soc/decoder/isa/sprset.py
> 
> [btw do *NOT* "git add" that to the repository (it's auto-generated.  we
>  do *NOT* add auto-generated files to the git repository, because they
>  change).]
> 
> example:  mcrxrx, from the sprset.mdwn file
> 
> * mcrxrx BF
> 
>     CR[4*BF+32:4*BF+35] <-  XER[OV] || XER[OV32] || XER[CA] || XER[CA32]
> 
> ---> is translated to, in sprset.py --->
> 
>     @inject()
>     def op_mcrxrx(self, CR):
>         CR[4 * BF + 32:4 * BF + 35 + 1] = concat(XER[OV], XER[OV32],
> XER[CA], XER[CA32]
>             )
>         return (CR,)
> 
> 
> at that point, you *should* be able to add something to
> soc/fu/trap/test/test_pipe_caller.py in class TrapTestCase
> 
> which i see you deleted all the unit tests (i usually leave one
> in there on cookie-cutting so that it's less typing when it comes
> to creating one.  now you will have to re-open one of the
> test_pipe_caller.py files to cut/paste an example from.  this is
> more work for you)
> 
> 
> here's the thing: it is highly likely that op_trap() from sprset.py
> will fail.  this because it's literally the first time that the emulator
> has ever seen the "trap" instruction, and that code also has to be written.
> 
> do not let this stop you from actually writing the unit test!
> 
> the unit test *is* the way to highlight that the code needs to be written!
> [this is called test-driven development]
> https://en.wikipedia.org/wiki/Test-driven_development

Very helpful, thank you. Will get to work on this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #71 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #68)
> actually... cole, can you do the same thing as i just did with
> msr_check_pr() create a function called trap(m, addr, nia)?
> 
> except this time it is a member function of the class, so trap(self, m,
> addr, nia)
> 
> and just as you see i redid comb=m.d.comb in msr_check_pr, repeat/copy the
> convenience variables that allow you to set self.o.nia etc etc
> 
> the reason for making this function is because you can see it is used twice
> already.
> 
> also i am thinking it may be a good idea to add the address (0x700, etc)
> actually to the trap_input_record and pass it in from the *decode* phase.

Sorry, I'm very shaky on the dynamic input records and how they work with the
decoder.

One difference between OP_TRAP and OP_SC is that the end of the OP_TRAP
function is:

```
# take a copy of the current PC in SRR0
comb += srr0_o.data.eq(cia_i)   # old PC
comb += srr0_o.ok.eq(1)
```
While the end of the OP_SC function is:

```
# and store the (next-after-return) PC in SRR0
comb += srr0_o.data.eq(cia_i+4) # addr to begin from on return
comb += srr0_o.ok.eq(1)
```

So should the function be:

```
def trap(self, m, addr, nia_o, srr0_o, trap_addr):
    comb = m.d.comb
    comb += nia_o.data.eq(trap_addr)
    comb += nia_o.ok.eq(1)

    comb += srr0_o.data.eq(addr) # addr to begin from on return
    comb += srr0_o.ok.eq(1)
```

The below is where my shakiness on the CompXOpSubset and the decoder starts to
confuse me. If you can briefly explain that to me here, I can use this when
doing the documentation after the tape-out deadline.

> that would allow us to do exceptions in a micro-code fashion, and also when
> it comes to illegal instructions or privileged ones, in the *decode* phase
> (PowerDecoder2) we *CHANGE* the opcode from whatever it is from the incoming
> instruction, into an OP_TRAP, set the trap address to 0x700 (or whatever)
> manually, and let the trap pipeline execute it.

(In reply to Luke Kenneth Casson Leighton from comment #69)
> see https://bugs.libre-soc.org/show_bug.cgi?id=325#c8
> 
> there, the only difference between OP_TRAP and that code is: one of the bits
> of SRR is changed (to indicate "priv execution")
> 
> we can pass that in as a flag to CompTrapOpSubset, and change the
> instruction to OP_TRAP.
> 
> illegal instruction trap happens. ta-daaa

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #72 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #67)
> in the libreriscv submodule first to "git pull origin master" - watch out
> because submodules are a pain - then you can generate the emulator code.
> 
> run pywriter.py (see top-level Makefile).  then - and only then - will
> the simulator "understand" mtmsr.
> 
> you can inspect the results by looking at... errr... what did we say
> it was added to?  sprset.mdwn?
> 
> so... pywriter.py will.. err.. put that into... 1sec....
> soc/decoder/isa/sprset.py
> 
> [btw do *NOT* "git add" that to the repository (it's auto-generated.  we
>  do *NOT* add auto-generated files to the git repository, because they
>  change).]
> 
> example:  mcrxrx, from the sprset.mdwn file
> 
> * mcrxrx BF
> 
>     CR[4*BF+32:4*BF+35] <-  XER[OV] || XER[OV32] || XER[CA] || XER[CA32]
> 
> ---> is translated to, in sprset.py --->
> 
>     @inject()
>     def op_mcrxrx(self, CR):
>         CR[4 * BF + 32:4 * BF + 35 + 1] = concat(XER[OV], XER[OV32],
> XER[CA], XER[CA32]
>             )
>         return (CR,)
> 
> 
> at that point, you *should* be able to add something to
> soc/fu/trap/test/test_pipe_caller.py in class TrapTestCase
> 
> which i see you deleted all the unit tests (i usually leave one
> in there on cookie-cutting so that it's less typing when it comes
> to creating one.  now you will have to re-open one of the
> test_pipe_caller.py files to cut/paste an example from.  this is
> more work for you)
> 
> 
> here's the thing: it is highly likely that op_trap() from sprset.py
> will fail.  this because it's literally the first time that the emulator
> has ever seen the "trap" instruction, and that code also has to be written.
> 
> do not let this stop you from actually writing the unit test!
> 
> the unit test *is* the way to highlight that the code needs to be written!
> [this is called test-driven development]
> https://en.wikipedia.org/wiki/Test-driven_development

I'm having a difficult time understanding how to write the first test for class
TrapTestCase looking both at cr/test/test_pipe_caller and
logical/test/test_pipe_caller... Do I have to translate all the code that was
set up for CR into setting up for TRAP? Trying to think through it I can't
figure it out, and I suspect it is related to my previous comment about not
understanding how the test_pipe_caller, XXXInput/OutputData, CompALUOpSubset,
and CompTrapOpSubset, and the decoder, relate to and interact with each
other... I have a little idea of each but I'm doing the 'freeze cause I don't
understand' right now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #73 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #71)
> (In reply to Luke Kenneth Casson Leighton from comment #68)
> > actually... cole, can you do the same thing as i just did with
> > msr_check_pr() create a function called trap(m, addr, nia)?
> > 
> > except this time it is a member function of the class, so trap(self, m,
> > addr, nia)
> > 
> > and just as you see i redid comb=m.d.comb in msr_check_pr, repeat/copy the
> > convenience variables that allow you to set self.o.nia etc etc
> > 
> > the reason for making this function is because you can see it is used twice
> > already.
> > 
> > also i am thinking it may be a good idea to add the address (0x700, etc)
> > actually to the trap_input_record and pass it in from the *decode* phase.
> 
> Sorry, I'm very shaky on the dynamic input records and how they work with
> the decoder.


will explain tomorrow when it is not 4am.
briefyly: every Record has a dictionary called fields.  by walking this
dictionary we can cheat and copy *only* a subset of fields... as long as the
names all match up.

see eq_from_execute1 and grep source code for where it is used.


> One difference between OP_TRAP and OP_SC is that the end of the OP_TRAP
> function is:
> 
> ```
> # take a copy of the current PC in SRR0
> comb += srr0_o.data.eq(cia_i)   # old PC
> comb += srr0_o.ok.eq(1)
> ```
> While the end of the OP_SC function is:
> 
> ```
> # and store the (next-after-return) PC in SRR0
> comb += srr0_o.data.eq(cia_i+4) # addr to begin from on return
> comb += srr0_o.ok.eq(1)
> ```
> 
> So should the function be:
> 
> ```
> def trap(self, m, addr, nia_o, srr0_o, trap_addr):
>     comb = m.d.comb
>     comb += nia_o.data.eq(trap_addr)
>     comb += nia_o.ok.eq(1)
> 
>     comb += srr0_o.data.eq(addr) # addr to begin from on return
>     comb += srr0_o.ok.eq(1)

yes! well done.  ok i would cut out srr0_o from those args and just redo them
inside the fn.

so now also cookie cut srr0_0 and nia_o from lines 89 and 90 "convenience"
variables.  see how that works?

so OP_SC should call self.trap(0xc00, cia_i+4) and OP_TRAP should be obvious.


> ```
> 
> The below is where my shakiness on the CompXOpSubset and the decoder starts
> to confuse me. If you can briefly explain that to me here, I can use this
> when doing the documentation after the tape-out deadline.

tomorrow.

late.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #74 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #72)

> I'm having a difficult time understanding how to write the first test for
> class TrapTestCase looking both at cr/test/test_pipe_caller and
> logical/test/test_pipe_caller... Do I have to translate all the code that
> was set up for CR into setting up for TRAP? Trying to think through it I
> can't figure it out, and I suspect it is related to my previous comment
> about not understanding how the test_pipe_caller, XXXInput/OutputData,
> CompALUOpSubset, and CompTrapOpSubset, and the decoder, relate to and
> interact with each other... I have a little idea of each but I'm doing the
> 'freeze cause I don't understand' right now.

ok.  suggestion.  take alu test_pipe_caller.py and cut out absolutely every
test_* except for one, make sure to pick one with only one assembly
instruction.

(or take copy of tpc.py, call it tpc2.py)

then run it and load the generated alu_simulator.gtk in gtkwave.

at the top level you will see an instruction.

add that to the window.

then just go through the hierarchy adding signals.

look especially for these

fn_unit
dest1
dest2
src1_i
src2_i
issue_i
busy_o
rd_go_i
rd_rel_o
wr go req as well

then go *back* to the source code (remember have SEVERAL files open at once)

note that "hey anywhere i have m.submodules those show up in the hierarchy!"

note that the Record contents also show up in the gtkwave output.

look at the debug output and note the instruction assembly code 0xNnnnff1234
etc got outputted and that it also matches that toplevel signal in gtkwave.

the tree hierarchy in gtkwave will start to give you an idea of the
interrelationships of the modules, in ways that staring at the static code
simply cannot give you, and the  "time" dimension will show you valuable
insights too.

once you have got used to this, add *one* more unit test back in, rerun
tpc2.py, and hit ctrl-shift-r in gtkwave.

you should be able to track the change in outputs, the result from the
operation, with what the debug output shows.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #75 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
commit d2e0e6bea57795fb522e0805b16e6f2852472f98
Author: Luke Kenneth Casson Leighton <lkcl@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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #76 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
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)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #77 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #73)
> will explain tomorrow when it is not 4am.

You are very bad at taking your own advice :) Thank you for explaining... the
entire process I should follow to gain MUCH greater understanding of the SOC
and how it works... all at 4 am!!

> briefyly: every Record has a dictionary called fields.  by walking this
> dictionary we can cheat and copy *only* a subset of fields... as long as the
> names all match up.
> 
> see eq_from_execute1 and grep source code for where it is used.
> 
> 
> > One difference between OP_TRAP and OP_SC is that the end of the OP_TRAP
> > function is:
> > 
> > ```
> > # take a copy of the current PC in SRR0
> > comb += srr0_o.data.eq(cia_i)   # old PC
> > comb += srr0_o.ok.eq(1)
> > ```
> > While the end of the OP_SC function is:
> > 
> > ```
> > # and store the (next-after-return) PC in SRR0
> > comb += srr0_o.data.eq(cia_i+4) # addr to begin from on return
> > comb += srr0_o.ok.eq(1)
> > ```
> > 
> > So should the function be:
> > 
> > ```
> > def trap(self, m, addr, nia_o, srr0_o, trap_addr):
> >     comb = m.d.comb
> >     comb += nia_o.data.eq(trap_addr)
> >     comb += nia_o.ok.eq(1)
> > 
> >     comb += srr0_o.data.eq(addr) # addr to begin from on return
> >     comb += srr0_o.ok.eq(1)
> 
> yes! well done.  ok i would cut out srr0_o from those args and just redo
> them inside the fn.

Thanks! Will do.

> so now also cookie cut srr0_0 and nia_o from lines 89 and 90 "convenience"
> variables.  see how that works?
> 
> so OP_SC should call self.trap(0xc00, cia_i+4) and OP_TRAP should be obvious.
> 
> 
> > ```
> > 
> > The below is where my shakiness on the CompXOpSubset and the decoder starts
> > to confuse me. If you can briefly explain that to me here, I can use this
> > when doing the documentation after the tape-out deadline.
> 
> tomorrow.
> 
> late.

Hehe :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #78 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #74)
> (In reply to Cole Poirier from comment #72)
> 
> > I'm having a difficult time understanding how to write the first test for
> > class TrapTestCase looking both at cr/test/test_pipe_caller and
> > logical/test/test_pipe_caller... Do I have to translate all the code that
> > was set up for CR into setting up for TRAP? Trying to think through it I
> > can't figure it out, and I suspect it is related to my previous comment
> > about not understanding how the test_pipe_caller, XXXInput/OutputData,
> > CompALUOpSubset, and CompTrapOpSubset, and the decoder, relate to and
> > interact with each other... I have a little idea of each but I'm doing the
> > 'freeze cause I don't understand' right now.
> 
> ok.  suggestion.  take alu test_pipe_caller.py and cut out absolutely every
> test_* except for one, make sure to pick one with only one assembly
> instruction.
> 
> (or take copy of tpc.py, call it tpc2.py)
> 
> then run it and load the generated alu_simulator.gtk in gtkwave.
> 
> at the top level you will see an instruction.
> 
> add that to the window.
> 
> then just go through the hierarchy adding signals.
> 
> look especially for these
> 
> fn_unit
> dest1
> dest2
> src1_i
> src2_i
> issue_i
> busy_o
> rd_go_i
> rd_rel_o
> wr go req as well
> 
> then go *back* to the source code (remember have SEVERAL files open at once)
> 
> note that "hey anywhere i have m.submodules those show up in the hierarchy!"
> 
> note that the Record contents also show up in the gtkwave output.
> 
> look at the debug output and note the instruction assembly code 0xNnnnff1234
> etc got outputted and that it also matches that toplevel signal in gtkwave.
> 
> the tree hierarchy in gtkwave will start to give you an idea of the
> interrelationships of the modules, in ways that staring at the static code
> simply cannot give you, and the  "time" dimension will show you valuable
> insights too.
> 
> once you have got used to this, add *one* more unit test back in, rerun
> tpc2.py, and hit ctrl-shift-r in gtkwave.
> 
> you should be able to track the change in outputs, the result from the
> operation, with what the debug output shows.

Thank you, this is the process for MUCH greater understanding I mentioned
above. I plan on working on this today after doing a more polished draft of the
b-deck, and fixing the trap() convenience function. Probably will work on this
for a few days until I feel like I'm starting to get a handle on things. Will
also work on translating psuedo code to nmigen for SPR tomorrow.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #79 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #75)
> commit d2e0e6bea57795fb522e0805b16e6f2852472f98
> Author: Luke Kenneth Casson Leighton <lkcl@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? Is this something I
can help with or are you handling it?

So is this TRAP function added in sort of ad hoc via caller.py, because it
isn't contained in fixedtrap.mdwn? Is it absent from fixedtrap.mdwn because
this is a different kind of trap?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #80 from Luke Kenneth Casson Leighton <lkcl@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@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.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #81 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #80)
> (In reply to Cole Poirier from comment #79)
> > 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?

No indeed it seems more similar to a keyword. Ah, so just translating that
psuedo code into the TRAP method of ISACaller?

> 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).

Aha, this is actually starting to make A LOT of sense :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #82 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #79)
> (In reply to Luke Kenneth Casson Leighton from comment #75)

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

yes please.

> What should I say in the bug description?

that we need one example unit test of how to run some assembly code
"qemu vs simulator" rather than "qemu vs hardware"

or, even just "qemu with some asserts" but looking *exactly* like how
it's done in the simulator, right now.

and that ultimately it should be possible to have a runtime switch
(or a suite of tests) that allow us to verify *aaalll* the simulator
test_pipe_caller.py tests, in the following way:

* simulator vs qemu
* qemu vs hardware
* hardware vs simulator

later i would very much like to be able to add microwatt to that list.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #83 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #81)
> (In reply to Luke Kenneth Casson Leighton from comment #80)
> > it is... however look at the PDF SPEC (or see comment #1 which contains
> > the pseudo-code.  that's not a function, is it?
> 
> No indeed it seems more similar to a keyword. 

i basically disregarded entirely the statement at the top of the POWER v3.0B
PDF, "this pseudocode is in no way intended to be an executable language"
and did exactly that.  teehee


> Ah, so just translating that
> psuedo code into the TRAP method of ISACaller?

yeeees :)

> >     @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).
> 
> Aha, this is actually starting to make A LOT of sense :)

ta-daaaa :)

so i saw the latest commit, and added some TODO comments.  if you
can do them *at the same time* as actually adding things in
caller.py ISACAller.TRAP, then you will see clearly the direct connection
between the two.

oh - yes, add a test_twi (or test_tdi) as well, you will have to
set an initial register RA, such as:

            initial_regs = [0] * 32
            initial_regs[2] = random.randint(0, (1<<32)-1)

or maybe do a fixed number, initially, so you know exactly what
you are testing against.  remember if you set initial_regs[2]
then that means that "RA" in the instruction has to be 2.
from fixedtrap.mdwn:

D-Form

* twi TO,RA,SI

therefore, what you put in the listing, would have to be twi TO,-->2<--,SI


TO is a bitfield, saying whether you want to compare equals, greater, less-than
etc. etc.

SI is an immediate that you want to compare against register RA.

so just pick something that, *manually*, you know will be "equal", or
something.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #84 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #82)
> (In reply to Cole Poirier from comment #79)
> > (In reply to Luke Kenneth Casson Leighton from comment #75)
> 
> > > 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?
> 
> yes please.
> 
> > What should I say in the bug description?
> 
> that we need one example unit test of how to run some assembly code
> "qemu vs simulator" rather than "qemu vs hardware"
> 
> or, even just "qemu with some asserts" but looking *exactly* like how
> it's done in the simulator, right now.
> 
> and that ultimately it should be possible to have a runtime switch
> (or a suite of tests) that allow us to verify *aaalll* the simulator
> test_pipe_caller.py tests, in the following way:
> 
> * simulator vs qemu
> * qemu vs hardware
> * hardware vs simulator
> 
> later i would very much like to be able to add microwatt to that list.

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #85 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #83)
> (In reply to Cole Poirier from comment #81)
> > (In reply to Luke Kenneth Casson Leighton from comment #80)
> i basically disregarded entirely the statement at the top of the POWER v3.0B
> PDF, "this pseudocode is in no way intended to be an executable language"
> and did exactly that.  teehee

Seems to have saved us many months of work!

> > Ah, so just translating that
> > psuedo code into the TRAP method of ISACaller?
> 
> yeeees :)

Makes sense :)

> so i saw the latest commit, and added some TODO comments.  if you
> can do them *at the same time* as actually adding things in
> caller.py ISACAller.TRAP, then you will see clearly the direct connection
> between the two.

Perfect, will do.

> oh - yes, add a test_twi (or test_tdi) as well, you will have to
> set an initial register RA, such as:
> 
>             initial_regs = [0] * 32
>             initial_regs[2] = random.randint(0, (1<<32)-1)
> 
> or maybe do a fixed number, initially, so you know exactly what
> you are testing against.  remember if you set initial_regs[2]
> then that means that "RA" in the instruction has to be 2.
> from fixedtrap.mdwn:
> 
> D-Form
> 
> * twi TO,RA,SI
> 
> therefore, what you put in the listing, would have to be twi TO,-->2<--,SI
> 
> 
> TO is a bitfield, saying whether you want to compare equals, greater,
> less-than etc. etc.
> 
> SI is an immediate that you want to compare against register RA.
> 
> so just pick something that, *manually*, you know will be "equal", or
> something.

Thanks, very helpful, will do as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #86 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
hi michael, apologies i couldn't help it, i did some of the TODO
comments on trap main_stage:

-        # TODO: MSR (into srr1)
+        # take a copy of the current MSR in SRR1
+        comb += msr_copy(srr1_o.data, msr_i) # old MSR
+        comb += srr1_o.ok.eq(1)

also i wandered through the 3.0B PDF and found the section that
covers "Program Interrupts" - Book III 7.5.9

i therefore added these defines:

PI_TRAP = (63 - 46)    # 1 if exception is "trap" type

and changed the setting of the relevant SRR1 bit to use that definition:

                    self.trap(0x700, cia_i)
                    comb += srr1_o.data[PI_TRAP].eq(1)

now we have words instead of numbers when it comes to reading through the
code.  we can see, in two lines of code:

1. "it's a trap" (self.trap - duh). 
2. execution continues at address 0x700
3. the trap handler (in software) can read SRR1 and know exactly what to do

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #87 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #86)
> hi michael,

cole!  gaah :)   names... massive headache (again) at the moment.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #88 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #86)
> hi michael, apologies i couldn't help it, i did some of the TODO
> comments on trap main_stage:
> 
> -        # TODO: MSR (into srr1)
> +        # take a copy of the current MSR in SRR1
> +        comb += msr_copy(srr1_o.data, msr_i) # old MSR
> +        comb += srr1_o.ok.eq(1)
>  
> also i wandered through the 3.0B PDF and found the section that
> covers "Program Interrupts" - Book III 7.5.9
> 
> i therefore added these defines:
> 
> PI_TRAP = (63 - 46)    # 1 if exception is "trap" type
> 
> and changed the setting of the relevant SRR1 bit to use that definition:
> 
>                     self.trap(0x700, cia_i)
>                     comb += srr1_o.data[PI_TRAP].eq(1)
> 
> now we have words instead of numbers when it comes to reading through the
> code.  we can see, in two lines of code:
> 
> 1. "it's a trap" (self.trap - duh). 
> 2. execution continues at address 0x700
> 3. the trap handler (in software) can read SRR1 and know exactly what to do

(In reply to Luke Kenneth Casson Leighton from comment #87)
> (In reply to Luke Kenneth Casson Leighton from comment #86)
> > hi michael,
> 
> cole!  gaah :)   names... massive headache (again) at the moment.

Hehe no problem :) I took a look at this yesterday evening, and I was going to
ask you for help because I was stuck, so, so much the better!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #89 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
ok so i added two new signals to Decode2Execute1Type, called
traptype and trapaddr.  the idea is that rather than get main_stage.py
to *hard-code* what type of trap it is, and *hard-code* the address to
jump to, the *decoder* says what the trap type is, and where to jump to.

in this way we can detect interrupts, privileged instructions, and so on,
in the *decoder*.

unfortunately... this means that the decoder needs access to MSR.  whoops.
this is slightly unfortunate, because up until now, PowerDecoder2 needed
absolutely nothing - no information *at all* - about the "state".  didn't
need the PC, didn't need anything.


+        with m.If(op.internal_op == InternalOp.OP_TRAP):
+            comb += e.traptype.eq(TT_TRAP) # request trap interrupt
+            comb += e.trapaddr.eq(0x70)    # addr=0x700 (strip first nibble)
+
+        return m

+        # privileged instruction
+        with m.If(instr_is_privileged(m, op.internal_op, e.insn) &
+                  msr[MSR_PR]):
+            # privileged instruction trap
+            comb += op.internal_op.eq(InternalOp.OP_TRAP)
+            comb += e.traptype.eq(TT_PRIV) # request privileged instruction
+            comb += e.trapaddr.eq(0x70)    # addr=0x700 (strip first nibble)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #90 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #89)
> ok so i added two new signals to Decode2Execute1Type, called
> traptype and trapaddr.  the idea is that rather than get main_stage.py
> to *hard-code* what type of trap it is, and *hard-code* the address to
> jump to, the *decoder* says what the trap type is, and where to jump to.
> 
> in this way we can detect interrupts, privileged instructions, and so on,
> in the *decoder*.
> 
> unfortunately... this means that the decoder needs access to MSR.  whoops.
> this is slightly unfortunate, because up until now, PowerDecoder2 needed
> absolutely nothing - no information *at all* - about the "state".  didn't
> need the PC, didn't need anything.
> 
> 
> +        with m.If(op.internal_op == InternalOp.OP_TRAP):
> +            comb += e.traptype.eq(TT_TRAP) # request trap interrupt
> +            comb += e.trapaddr.eq(0x70)    # addr=0x700 (strip first nibble)
> +
> +        return m
>  
> +        # privileged instruction
> +        with m.If(instr_is_privileged(m, op.internal_op, e.insn) &
> +                  msr[MSR_PR]):
> +            # privileged instruction trap
> +            comb += op.internal_op.eq(InternalOp.OP_TRAP)
> +            comb += e.traptype.eq(TT_PRIV) # request privileged instruction
> +            comb += e.trapaddr.eq(0x70)    # addr=0x700 (strip first nibble)

Very cool. Can you comment on the implications of the decoder needing access to
MSR here? or is that meant to be a comment on a different bug report. If so,
please link it here, because I'd like to understand the decoder better. Going
to finally get to try the learning process involving gtkwave today!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[bugzilla-daemon]

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

--- Comment #91 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #90)
> (In reply to Luke Kenneth Casson Leighton from comment #89)
> > ok so i added two new signals to Decode2Execute1Type, called
> > traptype and trapaddr.  the idea is that rather than get main_stage.py
> > to *hard-code* what type of trap it is, and *hard-code* the address to
> > jump to, the *decoder* says what the trap type is, and where to jump to.
> > 
> > in this way we can detect interrupts, privileged instructions, and so on,
> > in the *decoder*.
> > 
> > unfortunately... this means that the decoder needs access to MSR.  whoops.
> > this is slightly unfortunate, because up until now, PowerDecoder2 needed
> > absolutely nothing - no information *at all* - about the "state".  didn't
> > need the PC, didn't need anything.
> > 
> > 
> > +        with m.If(op.internal_op == InternalOp.OP_TRAP):
> > +            comb += e.traptype.eq(TT_TRAP) # request trap interrupt
> > +            comb += e.trapaddr.eq(0x70)    # addr=0x700 (strip first nibble)
> > +
> > +        return m
> >  
> > +        # privileged instruction
> > +        with m.If(instr_is_privileged(m, op.internal_op, e.insn) &
> > +                  msr[MSR_PR]):
> > +            # privileged instruction trap
> > +            comb += op.internal_op.eq(InternalOp.OP_TRAP)
> > +            comb += e.traptype.eq(TT_PRIV) # request privileged instruction
> > +            comb += e.trapaddr.eq(0x70)    # addr=0x700 (strip first nibble)
> 
> Very cool. Can you comment on the implications of the decoder needing access
> to MSR here?

sigh it's annoying. however given that we gave to pass state information
around, containing the PC, adding the MSR to that,state is not so bad.  it's
just that it messes with dependency tracking.

> or is that meant to be a comment on a different bug report. If
> so, please link it here, because I'd like to understand the decoder better.

the decoder's really not difficult.  funnily enough i updated this page

https://libre-soc.org/Documentation/SOC/index/

it links to PowerDecoder.  the thing yo remember is that there is no hardcoded
list of junk.  i will edit the page further, or we discuss on list. thus
bugrrport us intended for TRAP

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev