[libre-riscv-dev] daily kan-ban update 18may2020

[libre-riscv-dev] daily kan-ban update 18may2020

[Luke Kenneth Casson Leighton]

over the weekend i:

* continued to help michael with the pipelines (and moved them to
soc.fu this morning).
* also helped cole.
* and a new team member cesar (welcome!).
* and got LDSTCompUnit working (maybe).
* and had a fascinating conversation thanks to yehowshua and jeremy
(also welcome!), which resulted in this
(https://libre-soc.org/3d_gpu/architecture/tomasulo_transformation/).
* and did a preliminary first cut at a pinmux for the 180nm chip.
* and probably some other things i've forgotten about as i was up late
enough that my neuro-electrical memory is slightly shot.
* also this morning i reviewed the XER register and added some tables
from p45-6 of V3.0B spec to determine when the bits are set.
documented here https://libre-soc.org/openpower/pipeline_operands/

this latter is going to be a bit of a pig.  if we don't treat the XER
bits - each *bit* - as an actual separate and distinct "register" -
protected by a Dependency Matrix column - we might as well give up -
and no, doing an in-order design will not help on any level of
performance because all of those operations which set XER bits *still*
need to stall.  microwatt only gets away with this because it is only
a 2-stage pipeline.

today i will see how it goes because am still recovering from the
effects of three disrupted sleep nights in a row.

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] daily kan-ban update 18may2020

[Tobias Platen]

Today I was reading and trying to understand Chapter 2. Branch Facility.

Tobias

On Mon, 18 May 2020 12:45:26 +0100
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> over the weekend i:
> 
> * continued to help michael with the pipelines (and moved them to
> soc.fu this morning).
> * also helped cole.
> * and a new team member cesar (welcome!).
> * and got LDSTCompUnit working (maybe).
> * and had a fascinating conversation thanks to yehowshua and jeremy
> (also welcome!), which resulted in this
> (https://libre-soc.org/3d_gpu/architecture/tomasulo_transformation/).
> * and did a preliminary first cut at a pinmux for the 180nm chip.
> * and probably some other things i've forgotten about as i was up late
> enough that my neuro-electrical memory is slightly shot.
> * also this morning i reviewed the XER register and added some tables
> from p45-6 of V3.0B spec to determine when the bits are set.
> documented here https://libre-soc.org/openpower/pipeline_operands/
> 
> this latter is going to be a bit of a pig.  if we don't treat the XER
> bits - each *bit* - as an actual separate and distinct "register" -
> protected by a Dependency Matrix column - we might as well give up -
> and no, doing an in-order design will not help on any level of
> performance because all of those operations which set XER bits *still*
> need to stall.  microwatt only gets away with this because it is only
> a 2-stage pipeline.
> 
> today i will see how it goes because am still recovering from the
> effects of three disrupted sleep nights in a row.
> 
> l.
> 
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev


-- 
Tobias Platen <libre-soc[at]platen-software[dot]de>

_______________________________________________
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] daily kan-ban update 18may2020

[Luke Kenneth Casson Leighton]

On Mon, May 18, 2020 at 7:18 PM Tobias Platen
<libre-soc@platen-software.de> wrote:

> Today I was reading and trying to understand Chapter 2. Branch Facility.

you mean section 11.5.1 of Mitch's book?  it's very simple: the Branch
Function Unit holds a "shadow" - write-hazard - over anything that is
added after the Branch instruction was issued.  this "shadow" hooks
into all GO_WRITE phases of all instructions so "shadowed".  this
allows those units to *generate* results but NOT write them.

that Branch Unit may have a register it needs to read which happens to
be blocked because another (past) unit - one that was issued *before*
the branch - is due to write to it.  therefore, quite a few
instructions may build up with that "shadow" preventing them from
writing.

eventually, the register that the Branch Unit is waiting for will be
written to.  at that point, the Branch Unit can compute the outcome of
the Branch.  if it was "correct as predicted", the "shadow" is simply
dropped: all units with write-blocks now demand access to Regfile (and
memory).

if however it was wrong, the "GO_DIE" signal of the Shadow is pulled,
all those results get trashed immediately, and the Branch Unit sets a
new PC, down the "other" path, with new instruction issue beginning
from that new (correct) point.

so, to reiterate:

* some prior instructions happen to write to registers that the Branch
needs.  this takes time
* the Branch is issued with
  (A) a "Read-after-Write" Hazard on the instruction that is writing
to the register it needs and
  (B) a "Shadow" enabled which activates on *any* future instruction
* future instructions note that shadow and DISABLE "write commit"
capability but CONTINUE execution
* Branch Unit eventually gets the register it needs, completes its
decision-making, and either pulls "OK" or "DIE" on the Shadow.

it's pretty straightforward.

the exact same scheme is used for exceptions, interrupts and predication.

necessary modifications to the diagram on p55 are shown here:
https://libre-soc.org/3d_gpu/shadow.jpg

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] daily kan-ban update 18may2020

[Staf Verhaegen]

[-- Attachment #1.1: Type: text/plain, Size: 2490 bytes --]

Luke Kenneth Casson Leighton schreef op ma 18-05-2020 om 12:45 [+0100]:
> * and had a fascinating conversation thanks to yehowshua and jeremy(also welcome!), which resulted in this(https://libre-soc.org/3d_gpu/architecture/tomasulo_transformation/).

If I understand this correct the big architectural difference between extended scoreboarding and Tomasulo is that in the former the register content is stored in a central register file and for the latter it is distributed over several 'reservation stations'. In order to scale to for example multi-issue you need to go to higher order nRmW register files for scoreboarding and for Tomasulo you increase the number of reservation stations together with a more complex tracker of the register tagging/aliasing.
So some 2 cents from me.
From physical implementation point of view the central high order nRmW register file and scoreboard does worry me. Higher order nRmW register files will become power and area hungry compared to multiple lower order reservation stations.
I have seen numbers of a few tens of functional units in your design. I think it will become also a nightmare to connect and route all the input and outputs of all the functional units to the central register file and scoreboard. So at first sight, from physical implementation point for smaller nodes, the Tomasulo algorithm seems more scalable than extended scoreboarding. I indicated before that in smaller nodes power consumption and delay is mainly determined by the length of the interconnects and not by the input load of the logic gates itself; in 180nm it will be more fifty/fifty. As Jeremy indicated this is next to the power consumption in the register files and cache which scales with the total bit count of the block and the nRmW order of the block.
Also the travialness of a big fan-in NOR or NAND gate may be deceptive, these gates are not feasible and will be synthesized to trees of NAND/NOR gates. In that respect a high fan-in NOR/NAND can have similar time/power consumption than a seemingly more complex case of if statement. In zero order, for single output block, delay and power is determined by the number of inputs independent of the complexity of the RTL/HDL code. In first order one has to account that NAND/NOR logic is more efficient than XOR/XNOR logic but for bigger trees this difference is less pronounced as XOR/XNOR trees will be synthesized to more efficient trees using AOI (and-or-invert) cells.

greets,
Staf.



[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

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