[libre-riscv-dev] microwatt decoder tables: M-Form and X-Form switched RS and RB

[libre-riscv-dev] microwatt decoder tables: M-Form and X-Form switched RS and RB

[Luke Kenneth Casson Leighton]

anton, paul, and team, hi,

we noticed that in microwatt decode1.vhdl tables, M-Form has:

* op1 is RA
* op2 is a constant or RB, which is in the *3rd* field (M-Form) position
* op3 is RS, which is in the *second* Form position

where in X-Form it is:

* op1 is RA
* op2 is a constant or RB, where RB is from the *2nd* field
* op3 is RS (or RC), which is in the 3rd position.

so decode1.vhdl has this, for rldcl:
0b1000,SHIFT_ROT,OP_RLCL,NONE,RB,RS,RA

we're going to flip that to:
0b1000,SHIFT_ROT,OP_RLCL,NONE,RS,RB,RA

this will put the shift-rot pipeline "in line" with the arithmetic
(and logical) ones.

it *might* be the case that if you did the same thing, you would be
able to cut at least one pair of 64-bit MUXes from microwatt, because
RS and RB (2nd and 3rd operands) would no longer be
special-case-swapped for any Shift-Rot operations.  i mention it
because microwatt is intended to be tiny.

best,

l.

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [OpenPOWER-HDL-Cores] microwatt decoder tables: M-Form and X-Form switched RS and RB

[Paul Mackerras]

Hi Luke,

On Mon, Jun 01, 2020 at 01:20:45PM +0100, Luke Kenneth Casson Leighton wrote:
> anton, paul, and team, hi,
> 
> we noticed that in microwatt decode1.vhdl tables, M-Form has:
> 
> * op1 is RA
> * op2 is a constant or RB, which is in the *3rd* field (M-Form) position
> * op3 is RS, which is in the *second* Form position
> 
> where in X-Form it is:
> 
> * op1 is RA
> * op2 is a constant or RB, where RB is from the *2nd* field
> * op3 is RS (or RC), which is in the 3rd position.

I'm not quite following, sorry.  When you talk about the second or
third position or field, are you talking about where they are in the
instruction word (and if so, are you counting left to right, or right
to left), or are you talking about the input_reg_a/b/c entries in
microwatt's decode tables?

If you're talking about positions in the instruction word, then either
I'm misunderstanding your paragraph about X-form above, or it is
incorrect, because instructions such as "and" and "or" take their
inputs from RS and RB, so op1 is not RA for them, though it is for the
arithmetic instructions.

(I asked some of the original Power architects why there was this
nonuniformity in the Power ISA where rotate and logical instructions
use RS and RB as their inputs, whereas arithmetic instructions use RA
and RB as inputs.  The answer was that in the Power1 implementation,
they were very short of gates, so they made the logic for rotating and
masking data for store instructions also serve as the logic for doing
the rotate and mask instructions.  Since stores take their data from
RS, that meant that the rotate and shift instructions also took the
data to be rotated or shifted from RS.)

Regards,
Paul.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] microwatt decoder tables: M-Form and X-Form switched RS and RB

[Luke Kenneth Casson Leighton]

On Tuesday, June 2, 2020, Paul Mackerras <paulus@ozlabs.org> wrote:

>
> I'm not quite following, sorry.  When you talk about the second or
> third position or field, are you talking about where they are in the
> instruction word (and if so, are you counting left to right, or right
> to left),


there is the field names RA, RB, RC, RS, RT

there is the order (left to right) in which these occur in an X-Form,
M-Form etc.

then, in microwatt, there are 3 input regs, a/b/c.

these do not match up consistently, neither across Forms, nor in microwatt
input reg ordering when it comes to RA, RS and reg a and reg c.

* OP_EXTS for example places RS into microwatt reg c





> or are you talking about the input_reg_a/b/c entries in
> microwatt's decode tables?
>
> If you're talking about positions in the instruction word, then either
> I'm misunderstanding your paragraph about X-form above, or it is
> incorrect, because instructions such as "and" and "or" take their
> inputs from RS and RB, so op1 is not RA for them, though it is for the
> arithmetic instructions.


yet OP_EXTS, which is also arithmetic, take inputs ftom RS but place it
into the *third* microwatt register, c, despite microwatt positions 1 and 2
(reg a and reg b) being empty.

in the intervening time (good morning to you, btw) i worked out a couple of
things:

* i was wrong about fixedshift operations: the way that microwatt allocates
them to internal reg a/b/c is very sensible.

  these cannot be reordered.

* anything from fixedlogical (and, or, xor), fixedarith (specifically exts)
and mtcrf, these all use RS which goes into microwatt reg c, *all* whilst
also having microwatt reg a NONE.

  consequently these *can* be swapped.  whereever in decode1.vhdl there is
"NONE, NONE, RS" this can be replaced "RS, NONE, NONE" and reg a used
instead of reg c.

  whilst this has no significance at the moment, because everything is
primarily global in nature (in execute1.vhdl), if all fixedarith ALU
functions were moved to a separate module, that module would require
*three* 63 bit paths (reg a b c) where only 2 of those are ever active at
any one time.

by making the change above, the hypothetical fixedarith.vhdl module needs
only 2 input operands, not 3.




> (I asked some of the original Power architects why there was this
> nonuniformity in the Power ISA where rotate and logical instructions
> use RS and RB as their inputs, whereas arithmetic instructions use RA
> and RB as inputs.  The answer was that in the Power1 implementation,
> they were very short of gates, so they made the logic for rotating and
> masking data for store instructions also serve as the logic for doing
> the rotate and mask instructions.


ooo efficient microcoding.  niiice.  and ah now i see why the masking
exists: it would have been used to perform the insertion of (or extraction
of) offset bytes into or out of a LD/ST operand.

i love it.


Since stores take their data from
> RS, that meant that the rotate and shift instructions also took the
> data to be rotated or shifted from RS.)


i like it.  the paths would be straight: no crossover MUXes to get RS to 2
different ports.


i seriously considered making the LD/ST Function Unit also capable of ADD
operations.  the add is there, you still need an immediate, so why not.

the reason why not: ADD in POWER9, by being broken into carry, negation
etc, would have added quite a lot of logic to LD/ST.  and be able to
read/write carry, and CR0 and it gets too much.

i may however still get it to do "straight" (non carry, non invert) ADD and
ADDI.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] microwatt decoder tables: M-Form and X-Form switched RS and RB

[Luke Kenneth Casson Leighton]

ok.  interesting.  i start to see how POWER's design hangs together,
from a RISC / architectural perspective.  RA, RB, RC, RT, RS - these
would have been divided into "lanes" - effectively register file and
inter-Function-Unit "broadcast" buses: 5 of them.

RA, RB, RC and RS were probably also connected to 4 read ports (on a
4R1W regfile), and i suspect that RA and RS were multiplexed onto the
same regfile write port (with stall signals or careful scheduling).
those broadcast bus lanes would have been shared between:

* read regfile ports
* write regfile ports
* Function Unit incoming and outgoing ports.

just as for LD/ST, RS/RB would have been "laned" so that the
part-result could be "broadcast" onto those buses (without needing
MUXes to do so), such that the Shift Function Unit can pick it up as
if the information had come from the register file ports, OP_EXTS was
also put onto "lane RC" because it can then be likewise used as a
micro-code block in exactly the same way.

likewise, the OR, AND and XOR operations, to allow direct inter-FU
communication without any kind of lane cross-over.

it's really elegant, because it basically encodes "operand forwarding"
into the actual architecture.


however the _normal_ focus of RISC is on the instruction encoding.  in
the CDC 6600, there's 3 bits which are quite literally hard-wired to
enable a given Function Unit (of which there are, as might be obvious
from the 3-bits used: 8 types).  a few extra gates - again directly
from the opcode - says whether the instruction is 1-operand or
2-operands.

i believe in the CDC 6600 it's something ridiculous like under 15
gates for the entire instruction decoder.  now *that's* R(educed)
I(nstruction) S(et) C(oding)!

this therefore leaves me wondering if something similar was done for
POWER, where we've simply missed these patterns because they're just
not documented.

example: we know that ADD, NEG, SUB and even CMP can all use the exact
same underlying add hardware, with A-inversion, Out-inversion,
carry-in and carry-out detection engaged, optionally, to "augment" the
operation and turn what would otherwise be a plain add into a NEG, or
a SUB, and so on.

however... is this fact encoded *in the instructions*?  i.e. is the
instruction set encoded such that:

* "bit 8 indicates invert A"
* "bit 9 indicates invert output"
* "pattern of bits in positions X thru Y indicate an *underlying*
generic ADD hardware is to be used"

Rc and OE definitely fall into this category, however my question is:
does this pattern go much deeper?

if this principle has been applied across the board, in the ISA
design, the POWER instruction decoder phase could be drastically
simplified.  right now, the decoder is a massive 4 deep nested series
of Switch/Case statements, and consequently the number of gates
involved is enormous compared to other RISC architectures.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [OpenPOWER-HDL-Cores] microwatt decoder tables: M-Form and X-Form switched RS and RB

[Paul Mackerras]

On Tue, Jun 02, 2020 at 01:10:37PM +0100, Luke Kenneth Casson Leighton wrote:
> ok.  interesting.  i start to see how POWER's design hangs together,
> from a RISC / architectural perspective.  RA, RB, RC, RT, RS - these
> would have been divided into "lanes" - effectively register file and
> inter-Function-Unit "broadcast" buses: 5 of them.
> 
> RA, RB, RC and RS were probably also connected to 4 read ports (on a
> 4R1W regfile), and i suspect that RA and RS were multiplexed onto the
> same regfile write port (with stall signals or careful scheduling).
> those broadcast bus lanes would have been shared between:
> 
> * read regfile ports
> * write regfile ports
> * Function Unit incoming and outgoing ports.
> 
> just as for LD/ST, RS/RB would have been "laned" so that the
> part-result could be "broadcast" onto those buses (without needing
> MUXes to do so), such that the Shift Function Unit can pick it up as
> if the information had come from the register file ports, OP_EXTS was
> also put onto "lane RC" because it can then be likewise used as a
> micro-code block in exactly the same way.
> 
> likewise, the OR, AND and XOR operations, to allow direct inter-FU
> communication without any kind of lane cross-over.
> 
> it's really elegant, because it basically encodes "operand forwarding"
> into the actual architecture.
> 
> 
> however the _normal_ focus of RISC is on the instruction encoding.  in
> the CDC 6600, there's 3 bits which are quite literally hard-wired to
> enable a given Function Unit (of which there are, as might be obvious
> from the 3-bits used: 8 types).  a few extra gates - again directly
> from the opcode - says whether the instruction is 1-operand or
> 2-operands.
> 
> i believe in the CDC 6600 it's something ridiculous like under 15
> gates for the entire instruction decoder.  now *that's* R(educed)
> I(nstruction) S(et) C(oding)!
> 
> this therefore leaves me wondering if something similar was done for
> POWER, where we've simply missed these patterns because they're just
> not documented.

As far as I can see, there are patterns like this to some extent, but
not uniformly, and not as much as one would like.

For example, with the condition register logical ops (crand etc.),
there are 4 bits of the instruction word that give the truth table for
the operation.  However, the fixed-point logical ops don't have that.

> example: we know that ADD, NEG, SUB and even CMP can all use the exact
> same underlying add hardware, with A-inversion, Out-inversion,
> carry-in and carry-out detection engaged, optionally, to "augment" the
> operation and turn what would otherwise be a plain add into a NEG, or
> a SUB, and so on.
> 
> however... is this fact encoded *in the instructions*?  i.e. is the
> instruction set encoded such that:
> 
> * "bit 8 indicates invert A"
> * "bit 9 indicates invert output"
> * "pattern of bits in positions X thru Y indicate an *underlying*
> generic ADD hardware is to be used"

Appendix D (Opcode Maps) of the ISA is useful for investigating this
sort of question.  The add and sub instructions are on page 1365, with
sub instructions in the first column (bits 1-5 of the instruction word
being 01000) and add instructions in the third column (01010).  The
ops that use CA for the carry input seem to be in rows 5-8 and 21-24
(instruction bits 6-10 containing x01xx).  The ops that have the carry
input set to one all have bit 6 of the instruction word = 1.

I can't see much more structure to the layout than that, though others
might.

> Rc and OE definitely fall into this category, however my question is:
> does this pattern go much deeper?
> 
> if this principle has been applied across the board, in the ISA
> design, the POWER instruction decoder phase could be drastically
> simplified.  right now, the decoder is a massive 4 deep nested series
> of Switch/Case statements, and consequently the number of gates
> involved is enormous compared to other RISC architectures.

I don't know of such a principle being applied in recent times, though
there may have been such a principle in the very early days (early
90s).  I had hoped that the logic simplification algorithms that the
synthesis tools have would automatically detect the patterns, but
maybe that's asking a bit much.  It would probably help if our decode
tables indicated the don't-care entries rather than just putting 0 for
table entries that have no effect.

Paul.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [OpenPOWER-HDL-Cores] microwatt decoder tables: M-Form and X-Form switched RS and RB

[Luke Kenneth Casson Leighton]

On Wed, Jun 3, 2020 at 1:41 AM Paul Mackerras <paulus@ozlabs.org> wrote:
> On Tue, Jun 02, 2020 at 01:10:37PM +0100, Luke Kenneth Casson Leighton wrote:
> > this therefore leaves me wondering if something similar was done for
> > POWER, where we've simply missed these patterns because they're just
> > not documented.
>
> As far as I can see, there are patterns like this to some extent, but
> not uniformly, and not as much as one would like.
>
> For example, with the condition register logical ops (crand etc.),
> there are 4 bits of the instruction word that give the truth table for
> the operation.

yes i saw that trick: utterly cool :)  actually using the instruction
field as a 4-bit lookup.

>  However, the fixed-point logical ops don't have that.

possibly because all permutations (particularly if you include immediates)
would simply have taken up too much of the major opcode space.

> > however... is this fact encoded *in the instructions*?  i.e. is the
> > instruction set encoded such that:
>
> Appendix D (Opcode Maps) of the ISA is useful for investigating this
> sort of question.

ah good point.

> The add and sub instructions are on page 1365, with
> sub instructions in the first column (bits 1-5 of the instruction word
> being 01000) and add instructions in the third column (01010).  The
> ops that use CA for the carry input seem to be in rows 5-8 and 21-24
> (instruction bits 6-10 containing x01xx).  The ops that have the carry
> input set to one all have bit 6 of the instruction word = 1.

interesting.

> > if this principle has been applied across the board, in the ISA
> > design, the POWER instruction decoder phase could be drastically
> > simplified.  right now, the decoder is a massive 4 deep nested series
> > of Switch/Case statements, and consequently the number of gates
> > involved is enormous compared to other RISC architectures.
>
> I don't know of such a principle being applied in recent times, though
> there may have been such a principle in the very early days (early
> 90s).

RISC-V was based on the principle of "learning from past mistakes",
and a thorough analysis shows that one hell of a lot of thought has
gone into the ISA design.  i can say that it does indeed make for
a much simpler decoder.  the 16-bit C encoding for example, on first
sight, looks like a mess (bits all over the place), however when
implemented in hardware, several bits fall straight through without
needing to be MUXed, regardless of which Function Unit actually
needs those registers / sub-operations / etc.

unfortunately they did not leave enough room for future extension.
LD-with-update is not possible to add, without some inconvenience,
for example.

>  I had hoped that the logic simplification algorithms that the
> synthesis tools have would automatically detect the patterns, but
> maybe that's asking a bit much.

if you're paying USD $90m (or renting the tools @ USD 250,000 a week)
it's perfectly reasonable!  the rest of us - using yosys?  mmmm... :)

i've found that yosys can do a reasonable job of reducing gate delay.
(reducing longest paths).  however that *increases* gate count, not
reduces it.

i did wonder if there is a special mode for yosys "synth" command
to ask it to optimise for reduced gate count, instead.

>  It would probably help if our decode
> tables indicated the don't-care entries rather than just putting 0 for
> table entries that have no effect.

when converting to CSV format, i went over all of them: i didn't find
many opportunities.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev