[libre-riscv-dev] cache SRAM organisation

[libre-riscv-dev] cache SRAM organisation

[Luke Kenneth Casson Leighton]

https://groups.google.com/d/msg/comp.arch/cbGAlcCjiZE/mgMZVINVIAAJ

Staf can i ask you the favour of reviewing Mitch's comments about cache
design?

in particular the comments about the possibility of using multiported SRAM
cells as long as only 1R or 1W is done on any given cell?

also something about doing the FFs yourself, close to the SRAM cells?

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] cache SRAM organisation

[Staf Verhaegen]

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

Libre-SOC developers,

That discussion is mainly on system level and I don't want to get too deep into this as I don't have time for that.
I am providing the SRAM blocks and then it is up to the system guys to see how they use them. In this case you guys (libre-soc + LIP6) are the system guys.

On ASICs commonly three types of SRAM are provided: a single port RAM, a 2-port RAM and a dual port RAM. Currently for NLNet only a single port SRAM is foreseen as this is the most common, the smallest in area per bit and the fastest.
A single port SRAM has one port where you can do a read or a write each clock cycle. The 2-port one has one read port and one write port so you can do a read and write each clock cycle. The dual port one now has two ports that each can do a read or write each clock cycle. So you can do two reads, two write or a read+write each clock cycle.
For each of them you can have a synchronous or an asynchronous version. A synchronous RAM has a clock input and the address and data inputs are latched on that clock signal. It thus means that the FFs are integrated in the SRAM, e.g. thus very close :) . The RAM currently being developed in my NLNet project is a synchronous SRAM as this is easier from timing point of view because all the timing can be related to the clock. A synchronous RAM actually functions as an addressable bunch of FFs and the synthesis and P&R tools know how to handle them.

Given this building block you can now make blocks that look to the outside world as higher number port blocks. You do this by instantiating multiple RAM blocks and make sure that the content is mirrored between all the blocks. This way you can read from the different blocks in parallel. Writing in the blocks still has to happen to all the blocks at the same time.

So if you take four single port SRAM blocks you can make a four port SRAM block. Each cycle you can do 1-4 reads or 1 write but you can't read and write at the same time. With four 2-port RAMs you can do 4 reads and 1 write each clock cycle. With four dual port RAMs you can do 4 reads or 3 reads + 1 write or 2 reads + 2 writes each cycle.
I will provide the single block, the combining of the block has to happen in RTL/HDL. For Libre-SOC this means in nmigen and using Coriolis for placement and connecting the single blocks.

Although the SRAM does an operation each clock cycle the clock frequency could be different from the rest of the logic. If the RAM is fast enough it could run at double the frequency of the core so basically a single port RAM could look like a dual port RAM to the rest of the logic which is running at half the frequency. If the RAM is not fast enough wait  states need to be implemented for each operation. The maximum clock frequency will go down when you increase the size of a RAM block. So on CPU typically L1 cache runs at the same clock frequency as the core without any wait states and higher level caches are bigger but also introduce more wait states for accessing them.
If you are thinking about having different clock frequencies in your design you have to first discuss this with Jean-Paul/LIP6 as doing multi clock designs is opening it's own can of worms (cross clock domain problems etc). For the October prototype I feel we need to stick with use of single port SRAM block and run the whole chip from the same clock. IMO, on this prototype you should take any performance implication this has.

greets,
Staf.
Luke Kenneth Casson Leighton schreef op di 24-03-2020 om 22:32 [+0000]:
> https://groups.google.com/d/msg/comp.arch/cbGAlcCjiZE/mgMZVINVIAAJ
> Staf can i ask you the favour of reviewing Mitch's comments about cache design?
> in particular the comments about the possibility of using multiported SRAM cells as long as only 1R or 1W is done on any given cell?
> also something about doing the FFs yourself, close to the SRAM cells?
> l.
> 
> 




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

Re: [libre-riscv-dev] cache SRAM organisation

[Luke Kenneth Casson Leighton]

On Wednesday, March 25, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:

> Libre-SOC developers,
>
> That discussion is mainly on system level and I don't want to get too deep
> into this as I don't have time for that.
>

implicitly understood, it's why i linked to the (two) relevant discussions
in which Mitch mentioned Cache SRAM design, and summarised.

if you are busy, no need to reply below, it is mostly "informative" for
other readers.


> I am providing the SRAM blocks and then it is up to the system guys to see
> how they use them. In this case you guys (libre-soc + LIP6) are the system
> guys.
>

appreciated and accepted.


> On ASICs commonly three types of SRAM are provided: a single port RAM, a
> 2-port RAM and a dual port RAM. Currently for NLNet only a single port SRAM
> is foreseen as this is the most common, the smallest in area per bit and
> the fastest.
>

yes.  i deduced that from Mitch's description: appreciate the summary.


> A single port SRAM has one port where you can do a read or a write each
> clock cycle. The 2-port one has one read port and one write port so you can
> do a read and write each clock cycle. The dual port one now has two ports
> that each can do a read or write each clock cycle. So you can do two reads,
> two write or a read+write each clock cycle.
> For each of them you can have a synchronous or an asynchronous version. A
> synchronous RAM has a clock input and the address and data inputs are
> latched on that clock signal. It thus means that the FFs are integrated in
> the SRAM, e.g. thus very close :) . The RAM currently being developed in my
> NLNet project is a synchronous SRAM as this is easier from timing point of
> view because all the timing can be related to the clock. A synchronous RAM
> actually functions as an addressable bunch of FFs and the synthesis and P&R
> tools know how to handle them.
>

ok.  later, we will definitely need an aysynchronous version.

this because it turns out that asynchronous SRAM can act, when used in a
Register File, as if it was a (separate) Register Bypass / Forwarding
Port.  with the Out-of-Order Engine being a huge cyclic feedback loop
between ALUs and RegFile, clock delays are an impediment, and having
completely separate (extra) Regfile Bypass ports dramatically increases the
number of wires and Multiplexers.

(actually it is highly likely that we will need to do the Register File as
FFs, initially, because we need i think a minimum 3R1W, plus the
forwarding.  also we *may* do unary addressing - not binary addressing -
which i understand it is pointless to use SRAM cells when you have unary
individual row-enable, already).


> Given this building block you can now make blocks that look to the outside
> world as higher number port blocks. You do this by instantiating multiple
> RAM blocks and make sure that the content is mirrored between all the
> blocks. This way you can read from the different blocks in parallel.
> Writing in the blocks still has to happen to all the blocks at the same
> time.
>

i've heard of this trick being used in FPGAs, usually combining pairs of
2R1W to get 4R1W.


> So if you take four single port SRAM blocks you can make a four port SRAM
> block. Each cycle you can do 1-4 reads or 1 write but you can't read and
> write at the same time. With four 2-port RAMs you can do 4 reads and 1
> write each clock cycle. With four dual port RAMs you can do 4 reads or 3
> reads + 1 write or 2 reads + 2 writes each cycle.
>

ok i always wondered how you'd get 4R2W.

ok so actually we *could* do 3R1W or 4R1W with the single-port SRAM blocks,
for the Regfile.

I will provide the single block, the combining of the block has to happen
> in RTL/HDL. For Libre-SOC this means in nmigen and using Coriolis for
> placement and connecting the single blocks.
>

ok.  one for Jean-Paul to help advise with, when we get to it.


> Although the SRAM does an operation each clock cycle the clock frequency
> could be different from the rest of the logic. If the RAM is fast enough it
> could run at double the frequency of the core so basically a single port
> RAM could look like a dual port RAM to the rest of the logic which is
> running at half the frequency. If the RAM is not fast enough wait  states
> need to be implemented for each operation. The maximum clock frequency will
> go down when you increase the size of a RAM block. So on CPU typically L1
> cache runs at the same clock frequency as the core without any wait states
> and higher level caches are bigger but also introduce more wait states for
> accessing them.
>

hmmm...


> If you are thinking about having different clock frequencies in your
> design you have to first discuss this with Jean-Paul/LIP6 as doing multi
> clock designs is opening it's own can of worms (cross clock domain problems
> etc).


yes.  no, we're not crossing that chasm in the first chip.  i know nmigen
can do it: we *may* be forced to do it for some peripherals, and i know
nmigen supports clock domains, however the main core? no, we reaaally want
to avoid it.

For the October prototype I feel we need to stick with use of single port
> SRAM block and run the whole chip from the same clock. IMO, on this
> prototype you should take any performance implication this has.
>

yes.  we have enough to deal with.  the important thing for the 180nm ASIC
is to cover as much ground as is practical, and prove several aspects of
the design without taking on too much.

thanks for clarifying, Staf - we'll adapt accordingly.  will let you get on.

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] cache SRAM organisation

[Staf Verhaegen]

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

Luke Kenneth Casson Leighton schreef op wo 25-03-2020 om 12:33 [+0000]:
> On Wednesday, March 25, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:
> > A single port SRAM has one port where you can do a read or a write eachclock cycle. The 2-port one has one read port and one write port so you cando a read and write each clock cycle. The dual port one now has two portsthat each can do a read or write each clock cycle. So you can do two reads,two write or a read+write each clock cycle.For each of them you can have a synchronous or an asynchronous version. Asynchronous RAM has a clock input and the address and data inputs arelatched on that clock signal. It thus means that the FFs are integrated inthe SRAM, e.g. thus very close :) . The RAM currently being developed in myNLNet project is a synchronous SRAM as this is easier from timing point ofview because all the timing can be related to the clock. A synchronous RAMactually functions as an addressable bunch of FFs and the synthesis and P&Rtools know how to handle them.
> 
> ok.  later, we will definitely need an aysynchronous version.

Keep the discussion on development of other types til after the prototype tape-out in October. I know there is other development ongoing for dual port RAM in the OpenRAM community so likely it is more clear what extra still has to happen.
BTW, I think there also is possibility to have register files block with 2R1W RAM blocks.

> this because it turns out that asynchronous SRAM can act, when used in aRegister File, as if it was a (separate) Register Bypass / ForwardingPort.  with the Out-of-Order Engine being a huge cyclic feedback loopbetween ALUs and RegFile, clock delays are an impediment, and havingcompletely separate (extra) Regfile Bypass ports dramatically increases thenumber of wires and Multiplexers.

Could detail more on how the adress, data and output signals of this asynchronous block would be used and switched between synchronous and asynchronous functioning. To me it seems that it would just place of the multiplexers, not the amount.

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

Re: [libre-riscv-dev] cache SRAM organisation

[Luke Kenneth Casson Leighton]

On Wed, Mar 25, 2020 at 1:46 PM Staf Verhaegen <staf@fibraservi.eu> wrote:

> Keep the discussion on development of other types til after the prototype tape-out in October.

good idea.

> I know there is other development ongoing for dual port RAM in the OpenRAM community so likely it is more clear what extra still has to happen.
> BTW, I think there also is possibility to have register files block with 2R1W RAM blocks.

ah that's good.  we can combine two of them to create 4R1W (we need
minimum 3R1W, however the design does not critically depend on this:
it just takes 2 cycles to read all operands for 3-operand instructions
such as FMAC).

> > this because it turns out that asynchronous SRAM can act, when used in aRegister File, as if it was a (separate) Register Bypass / ForwardingPort.  with the Out-of-Order Engine being a huge cyclic feedback loopbetween ALUs and RegFile, clock delays are an impediment, and havingcompletely separate (extra) Regfile Bypass ports dramatically increases thenumber of wires and Multiplexers.
>
> Could detail more on how the adress, data and output signals of this asynchronous block would be used and switched between synchronous and asynchronous functioning. To me it seems that it would just place of the multiplexers, not the amount.

ok i will try to outine it, there is quite a lot of detail, i apologise.

it's basically the "pass-through" system used in nmigen FIFOs, and the
"synchronous" mode of nmigen Memory.  the requirements are: what is
written has to be available *combinatorially* - i.e. on the same clock
cycle - if simultaneously read via another port.

now, yes i took note that this is not supposed to be permitted: you're
not normally permitted to be able to read *and* write to an SRAM cell
at the same time.  however, that's exactly what we need.

a workaround (fallback position) is, we use DFF latches.  i created a
"bypass latch" function which creates DFF latches with such a
combinatorial bypass: we actually use them quite a lot (including
between pipeline stages so that we can programmatically cut the number
of pipeline stages in half at the flick of a switch).

however for the Register File we would not "switch" between
synchronous / asynchronous mode.  the reason why we need the
synchronous mode is because some Function Units will be sitting idle,
waiting for their input operands, which have to come from other
Function Units as "results".

these "results" of course have to go into the Register File, however
in a large number of cases, there are FUs waiting for a "read" of that
exact register - the one that's just been written - and to make that
FU wait *another* clock cycle is just wasting time.

btw, also: the synchronous "Read" mode also allows us to transfer data
from the Regfile into Function Unit input latches on that same cycle,
rather than (again) waiting yet another cycle, unnecessarily.  in some
cases, where a pipeline has an immediate free slot, we can actually
proceed directly to executing stage 1 of the pipeline, *in* the same
cycle as the actual Regfile Read.

the other aspect of the Dependency Matrices is: each register has
already been given a "single line" (one "enable" bit per Reg #).  the
binary register number is *gone*.

if we use a "standard" binary-addressable Register File, we actually
have to *recreate* that binary register number / address, using
unary-to-binary converters!

so my point is: if we have all the register numbers *already* encoded
in unary (one "enable" bit per reg #), we actually don't *want* a
binary-addressing mux-map on the Regfile, at all!

we actually just want a Priority-Picker, directly onto the SRAM port
write/read enable lines, where each SRAM row has *no* binary-address
decoder on it.

i hope that was enough to explain what is going on?  if not please do
ask to clarify, when you have time.

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] cache SRAM organisation

[Jacob Lifshay]

On Wed, Mar 25, 2020, 08:54 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Wed, Mar 25, 2020 at 1:46 PM Staf Verhaegen <staf@fibraservi.eu> wrote:
>
> > Keep the discussion on development of other types til after the
> prototype tape-out in October.
>
> good idea.
>
> > I know there is other development ongoing for dual port RAM in the
> OpenRAM community so likely it is more clear what extra still has to happen.
> > BTW, I think there also is possibility to have register files block with
> 2R1W RAM blocks.
>
> ah that's good.  we can combine two of them to create 4R1W (we need
> minimum 3R1W, however the design does not critically depend on this:
> it just takes 2 cycles to read all operands for 3-operand instructions
> such as FMAC).
>
> > > this because it turns out that asynchronous SRAM can act, when used in
> aRegister File, as if it was a (separate) Register Bypass /
> ForwardingPort.  with the Out-of-Order Engine being a huge cyclic feedback
> loopbetween ALUs and RegFile, clock delays are an impediment, and
> havingcompletely separate (extra) Regfile Bypass ports dramatically
> increases thenumber of wires and Multiplexers.
> >
> > Could detail more on how the adress, data and output signals of this
> asynchronous block would be used and switched between synchronous and
> asynchronous functioning. To me it seems that it would just place of the
> multiplexers, not the amount.
>
> ok i will try to outine it, there is quite a lot of detail, i apologise.
>
> it's basically the "pass-through" system used in nmigen FIFOs, and the
> "synchronous" mode of nmigen Memory.  the requirements are: what is
> written has to be available *combinatorially* - i.e. on the same clock
> cycle - if simultaneously read via another port.
>
> now, yes i took note that this is not supposed to be permitted: you're
> not normally permitted to be able to read *and* write to an SRAM cell
> at the same time.  however, that's exactly what we need.
>

It seems obvious to me that you just add a mux on each read port to bypass
directly from the write ports when the address matches -- that way you
don't have to worry about needing both read and write to the same cell.

Also, assuming I'm not missing something, grouping two 1R or 1W srams
doesn't give 2R1W, it gives 2R or 1W since each cycle that you write, you
write to all srams meaning all srams can't read.

Jacob

>
_______________________________________________
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] cache SRAM organisation

[Staf Verhaegen]

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

Luke Kenneth Casson Leighton schreef op wo 25-03-2020 om 15:53 [+0000]:
> On Wed, Mar 25, 2020 at 1:46 PM Staf Verhaegen <staf@fibraservi.eu> wrote:
> 
> > > this because it turns out that asynchronous SRAM can act, when used in aRegister File, as if it was a (separate) Register Bypass / ForwardingPort.  with the Out-of-Order Engine being a huge cyclic feedback loopbetween ALUs and RegFile, clock delays are an impediment, and havingcompletely separate (extra) Regfile Bypass ports dramatically increases thenumber of wires and Multiplexers.
> > 
> > Could detail more on how the adress, data and output signals of this asynchronous block would be used and switched between synchronous and asynchronous functioning. To me it seems that it would just place of the multiplexers, not the amount.
> 
> ok i will try to outine it, there is quite a lot of detail, i apologise.
> it's basically the "pass-through" system used in nmigen FIFOs, and the"synchronous" mode of nmigen Memory.  the requirements are: what iswritten has to be available *combinatorially* - i.e. on the same clockcycle - if simultaneously read via another port.
> now, yes i took note that this is not supposed to be permitted: you'renot normally permitted to be able to read *and* write to an SRAM cellat the same time.  however, that's exactly what we need.

You seem to mixing up two different concepts, e.g. synchronicity and write-through. Synchronous means signals are synced with an edge of a (clock) signal. SRAM write-through means that after a write operation you also get on the Q output the data you have just written. These two concepts are orthogonal to each other.
The current synchronous SRAM being developed will most likely have write-through behavior; will be confirmed before May test chip tape-out. It will cause delay on the signal though. I need to check if it has changed but in the OpenRAM 0.35um test tape-out I did the address and data input was latched on rising edge and the Q output was updated on falling edge of the clock. So the delay on the Q output is half a clock cycle plus the internal delay on the output latch enable signal.
So if timing of the write-through is critical it is still best to still include MUXs as said in Jacob's reply to allow the bypass ofsignal. I have seen SRAM that did include a AWT (asynchronous write through) but this just moved the MUXs inside the SRAM block and also adds them if you don't need this AWT. So I would like to keep these MUX be added added externally is needed.
In theory on a single port SRAM
> a workaround (fallback position) is, we use DFF latches.  i created a"bypass latch" function which creates DFF latches with such acombinatorial bypass: we actually use them quite a lot (includingbetween pipeline stages so that we can programmatically cut the numberof pipeline stages in half at the flick of a switch).
> however for the Register File we would not "switch" betweensynchronous / asynchronous mode.  the reason why we need thesynchronous mode is because some Function Units will be sitting idle,waiting for their input operands, which have to come from otherFunction Units as "results".

I can understand you do this to implement functional units with configurable pipeline length but I would strongly discourage to pipeline register files after each other . If the latter is excluded would you still need an asynchronous RAM block ?

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

Re: [libre-riscv-dev] cache SRAM organisation

[Staf Verhaegen]

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

(Sorry send to early)


> .In theory on a single port SRAM

In theory on a single port SRAM the write data input and the Q data output could be on opposite sides of the block but I will make sure that these pins are on the same side of the block and close together so you don't need much wire to connect a pass-through MUX.

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

Re: [libre-riscv-dev] cache SRAM organisation

[Luke Kenneth Casson Leighton]

On Thursday, March 26, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:

> (Sorry send to early)
>
>
> > .In theory on a single port SRAM
>
> In theory on a single port SRAM the write data input and the Q data output
> could be on opposite sides of the block but I will make sure that these
> pins are on the same side of the block and close together so you don't need
> much wire to connect a pass-through MUX.


ah fantastic, really appreciated.

that will help keep it small.

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] cache SRAM organisation

[Luke Kenneth Casson Leighton]

On Thursday, March 26, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:
>
>
> You seem to mixing up two different concepts, e.g. synchronicity and
> write-through.


ah ok.  i didn't realise that SRAMs would have these as separate concepts.
perhaps i would get it immediately if i saw a gate level schematic.


> Synchronous means signals are synced with an edge of a (clock) signal.
> SRAM write-through means that after a write operation you also get on the Q
> output the data you have just written. These two concepts are orthogonal to
> each other.
> The current synchronous SRAM being developed will most likely have
> write-through behavior;


ah good


> will be confirmed before May test chip tape-out.


ah May not March.


>
>  It will cause delay on the signal though. I need to check if it has
> changed but in the OpenRAM 0.35um test tape-out I did the address and data
> input was latched on rising edge and the Q output was updated on falling
> edge of the clock. So the delay on the Q output is half a clock cycle plus
> the internal delay on the output latch enable signal.


fascinating.  that's pretty much exactly what the CDC6600 did on its
register file.


> So if timing of the write-through is critical it is still best to still
> include MUXs as said in Jacob's reply to allow the bypass ofsignal. I have
> seen SRAM that did include a AWT (asynchronous write through) but this just
> moved the MUXs inside the SRAM block and also adds them if you don't need
> this AWT. So I would like to keep these MUX be added added externally is
> needed.


ok

> > mode.  the reason why we need the synchronous mode is because some
> > Function Units will be sitting idle,waiting for their input operands,
which have to come from
> > otherFunction Units as "results".


> I can understand you do this to implement functional units with
> configurable pipeline length but I would strongly discourage to pipeline
> register files after each other .


"pipeline register files after each other"? apologies i am not clear what
you mean, here.  do you mean "don't do write-thru on the Regfile"?

this design is not like an InOrder system where it is very risky to change
pipeline lengths or do any kind of fancy work.

the (parallel) OoO design has all data dependencies sorted out, all units
*know exactly* which units they are waiting for, they can be arbitrary
completion time, they can be FSMs, and the Dependency Matrices just don't
care because they record completion *not* completion *time*.

therefore the only thing stopping them from proceeding is how fast they can
get a result, so that other FUs can get at it as an input operand as quick
as possible.

that means either: a Register Forwarding Bus, or it means a write to the
Regfile followed by a read.

therefore anything we can do to reduce the number of clock cycles between
that regfile write and subsequent read is a good thing.

if write-thru is available, we can use it to reduce delay by one cycle.
however yes i note that because it is on the falling edge we might not be
able to take full advantage of it.



If the latter is excluded would you still need an asynchronous RAM block ?


i can't tell, yet, apologies.  i believe the answer is no.

Staf it would help enormously i think if you could let us know, in terms of
what options to nmigen Memory module, are permitted.  i am assuming that
nmigen Memory actually supports the options correctly!

we can then "wrap" the Memory module (or hook it) and throw asserts if we
ever use options that are not supported.

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] cache SRAM organisation

[Staf Verhaegen]

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

Luke Kenneth Casson Leighton schreef op do 26-03-2020 om 15:15 [+0000]:
> On Thursday, March 26, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:
> > I can understand you do this to implement functional units withconfigurable pipeline length but I would strongly discourage to pipelineregister files after each other .
> 
> 
> "pipeline register files after each other"? apologies i am not clear whatyou mean, here.  do you mean "don't do write-thru on the Regfile"?

No I meant for example connecting the output of one port of an asynchronous RAM to for example the address input of another port of an asynchronous RAM.

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

Re: [libre-riscv-dev] cache SRAM organisation

[Luke Kenneth Casson Leighton]

On Thu, Mar 26, 2020 at 8:08 PM Staf Verhaegen <staf@fibraservi.eu> wrote:

> Luke Kenneth Casson Leighton schreef op do 26-03-2020 om 15:15 [+0000]:
> > On Thursday, March 26, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:
> > > I can understand you do this to implement functional units withconfigurable pipeline length but I would strongly discourage to pipelineregister files after each other .
> >
> >
> > "pipeline register files after each other"? apologies i am not clear whatyou mean, here.  do you mean "don't do write-thru on the Regfile"?
>
> No I meant for example connecting the output of one port of an asynchronous RAM to for example the address input of another port of an asynchronous RAM.

ah right, no definitely not.  the connections are:

RegisterFile readport[0..R] ==> FunctionUnit[0..M] operand latches
                                            pipeline stage 0
                                            pipeline stage 1
                                            ...
                                            pipeline stage N
RegisterFile writeport[0..W] <== FunctionUnit[0..M] result latches

(and also: )
register file bypass forwardingbus <== FunctionUnit result latches
register file bypass forwardingbus ==> FunctionUnit operand latches

so the asynchronous SRAMs will definitely *only* be connected to SFF
latches.  *not* to other asynchronous SRAMs.

appreciated the clarification.

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] cache SRAM organisation

[Staf Verhaegen]

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

Luke Kenneth Casson Leighton schreef op do 26-03-2020 om 21:28 [+0000]:
> On Thu, Mar 26, 2020 at 8:08 PM Staf Verhaegen <staf@fibraservi.eu> wrote:
> > Luke Kenneth Casson Leighton schreef op do 26-03-2020 om 15:15 [+0000]:
> > > On Thursday, March 26, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:
> > > > I can understand you do this to implement functional units withconfigurable pipeline length but I would strongly discourage to pipelineregister files after each other .
> > > 
> > > 
> > > "pipeline register files after each other"? apologies i am not clear whatyou mean, here.  do you mean "don't do write-thru on the Regfile"?
> > 
> > No I meant for example connecting the output of one port of an asynchronous RAM to for example the address input of another port of an asynchronous RAM.
> 
> ah right, no definitely not.  the connections are:
> RegisterFile readport[0..R] ==> FunctionUnit[0..M] operand latches                                            pipeline stage 0                                            pipeline stage 1                                            ...                                            pipeline stage NRegisterFile writeport[0..W] <== FunctionUnit[0..M] result latches
> (and also: )register file bypass forwardingbus <== FunctionUnit result latchesregister file bypass forwardingbus ==> FunctionUnit operand latches
> so the asynchronous SRAMs will definitely *only* be connected to SFFlatches.  *not* to other asynchronous SRAMs.

I still feel you intermix synchronous and write-through in this statement, the above seems to be possible with synchronous SRAMs.

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

Re: [libre-riscv-dev] cache SRAM organisation

[Luke Kenneth Casson Leighton]

On Fri, Mar 27, 2020 at 9:09 AM Staf Verhaegen <staf@fibraservi.eu> wrote:

> I still feel you intermix synchronous and write-through in this statement, the above seems to be possible with synchronous SRAMs.

this would be good.  what would help clarify immensely is if you could
let us know what options to nmigen Memory class are "supported".
then it is really clear.

best,

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] cache SRAM organisation

[Staf Verhaegen]

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

Luke Kenneth Casson Leighton schreef op vr 27-03-2020 om 09:16 [+0000]:
> On Fri, Mar 27, 2020 at 9:09 AM Staf Verhaegen <staf@fibraservi.eu> wrote:
> > I still feel you intermix synchronous and write-through in this statement, the above seems to be possible with synchronous SRAMs.
> 
> this would be good.  what would help clarify immensely is if you couldlet us know what options to nmigen Memory class are "supported".then it is really clear.

The nmigen Memory abstraction does not seem to allow a good representation of a write-through SRAM. AFAICS it does not allow to have the output of the read port be changed by what you write on the write port.

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

Re: [libre-riscv-dev] cache SRAM organisation

[Luke Kenneth Casson Leighton]

On Fri, Mar 27, 2020 at 9:40 AM Staf Verhaegen <staf@fibraservi.eu> wrote:
>
> Luke Kenneth Casson Leighton schreef op vr 27-03-2020 om 09:16 [+0000]:
> > On Fri, Mar 27, 2020 at 9:09 AM Staf Verhaegen <staf@fibraservi.eu> wrote:
> > > I still feel you intermix synchronous and write-through in this statement, the above seems to be possible with synchronous SRAMs.
> >
> > this would be good.  what would help clarify immensely is if you couldlet us know what options to nmigen Memory class are "supported".then it is really clear.
>
> The nmigen Memory abstraction does not seem to allow a good representation of a write-through SRAM. AFAICS it does not allow to have the output of the read port be changed by what you write on the write port.

urk, that's an important oversight.  we'll need to raise a bugreport
with whitequark about it.

jacob: was that other bug you found with nmigen Memory simulation ever fixed?

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] cache SRAM organisation

[Luke Kenneth Casson Leighton]

On Fri, Mar 27, 2020 at 9:46 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Fri, Mar 27, 2020 at 9:40 AM Staf Verhaegen <staf@fibraservi.eu> wrote:

> > The nmigen Memory abstraction does not seem to allow a good representation of a write-through SRAM. AFAICS it does not allow to have the output of the read port be changed by what you write on the write port.
>
> urk, that's an important oversight.  we'll need to raise a bugreport
> with whitequark about it.

ok raised a bugreport here.

if nothing else, Staf, we just augment the SRAM with external MUX
logic, or we simply use SFFs for the RegFile.  it'll be big, but it
will work.

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] cache SRAM organisation

[Staf Verhaegen]

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

Luke Kenneth Casson Leighton schreef op wo 25-03-2020 om 15:53 [+0000]:
> On Wed, Mar 25, 2020 at 1:46 PM Staf Verhaegen <staf@fibraservi.eu> wrote:
> a workaround (fallback position) is, we use DFF latches.  i created a"bypass latch" function which creates DFF latches with such acombinatorial bypass: we actually use them quite a lot (includingbetween pipeline stages so that we can programmatically cut the numberof pipeline stages in half at the flick of a switch).

Would like to make separate side remark here. In ASICs MUXes are relative expensive gates with respect to delay and power. So if this principle is generally applied over the whole design it will make it difficult to make a chip that is competitive in power/performance compared to ARM/x86 CPUs.
In general if you are trying to optimize power/performance of your chip the KISS (keep it simple stupid) is your friend. In that respect your complex dual ISA decoder will have a power cost.

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

Re: [libre-riscv-dev] cache SRAM organisation

[Luke Kenneth Casson Leighton]

On Thursday, March 26, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:

>
> Would like to make separate side remark here. In ASICs MUXes are relative
> expensive gates with respect to delay and power. So if this principle is
> generally applied over the whole design it will make it difficult to make a
> chip that is competitive in power/performance compared to ARM/x86 CPUs.


just the ALU pipeline registers.  we felt that the advantage of being able
to drop to say 500mhz and halve the number of pipeline stages to say 5, and
also be able to ramp up to 1.6ghz and double bavk up to 10 stages, was
worth considering.


> In general if you are trying to optimize power/performance of your chip
> the KISS (keep it simple stupid) is your friend. In that respect your
> complex dual ISA decoder will have a power cost.


sigh yes i know.  however i do not know if you've seen the POWER ISA
decoder, it is *five* levels deep in some places, decoding different field
ranges in a dependent cascade!

adding RV would be trivial by comparison!

 but yes we are generally getting the message from various sources that
dual ISA isn't a good idea.

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] cache SRAM organisation

[Staf Verhaegen]

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

Luke Kenneth Casson Leighton schreef op do 26-03-2020 om 13:05 [+0000]:
> On Thursday, March 26, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:
> > Would like to make separate side remark here. In ASICs MUXes are relativeexpensive gates with respect to delay and power. So if this principle isgenerally applied over the whole design it will make it difficult to make achip that is competitive in power/performance compared to ARM/x86 CPUs.
> 
> 
> just the ALU pipeline registers.  we felt that the advantage of being ableto drop to say 500mhz and halve the number of pipeline stages to say 5, andalso be able to ramp up to 1.6ghz and double bavk up to 10 stages, wasworth considering.

What would be the advantage over running at 800Mhz with 5 pipeline stages ?

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

Re: [libre-riscv-dev] cache SRAM organisation

[Luke Kenneth Casson Leighton]

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

On Thu, Mar 26, 2020 at 8:18 PM Staf Verhaegen <staf@fibraservi.eu> wrote:
>
> Luke Kenneth Casson Leighton schreef op do 26-03-2020 om 13:05 [+0000]:
> > On Thursday, March 26, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:
> > > Would like to make separate side remark here. In ASICs MUXes are relativeexpensive gates with respect to delay and power. So if this principle isgenerally applied over the whole design it will make it difficult to make achip that is competitive in power/performance compared to ARM/x86 CPUs.
> >
> >
> > just the ALU pipeline registers.  we felt that the advantage of being ableto drop to say 500mhz and halve the number of pipeline stages to say 5, andalso be able to ramp up to 1.6ghz and double bavk up to 10 stages, wasworth considering.
>
> What would be the advantage over running at 800Mhz with 5 pipeline stages ?

i assume you mean fixed 5-pipeline stages.

the problem is, if you *want* to run at 1.6ghz and have complex
pipeline stages, you simply can't: 5 stages are too long, the gate
propagation delay is too large.  the only way to get to 1.6hz is:
split those 5 stages into 10 smaller stages.

the problem with _that_ is: if you then run those 10 stages at say
800mhz, or say even 400 mhz or 100mhz (because you are in power-saving
mode), you just *massively* increased the latency for completion of
any given operation.

so even though those 10 stages are so fast (because you are in 14nm)
that, at 100mhz, they complete in under 5% of a 100mhz clock rate, if
you have a fixed 10-stage pipeline you are absolutely screwed, you
*have* to have the penalty of the 10-stage pipeline latency.

screwed 1:  5-stage pipeline FORCES you to ONLY be able to run at
BELOW (e.g) 800mhz

screwed 2: 10-stage pipeline FORCES you to have massive instruction
completion latency at below (e.g.) 800mhz.

solution: give every other pipeline stage's registers a "combinatorial bypass".

un-screwed 1: when speed is above 800mhz, switch off the combinatorial
bypass, pipeline becomes 10-stage.

un-screwed 2: when speed is below 800mhz, switch ON the combinatorial
bypass, latency due to slower clock rate DISAPPEARS because all
pipelines are now only 5-stage, not 10.

according to some people on comp.arch, the first time this appeared in
commercial processors was in the 1990s, done by IBM.

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] cache SRAM organisation

[Staf Verhaegen]

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

Luke Kenneth Casson Leighton schreef op do 26-03-2020 om 21:37 [+0000]:
> ---crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Thu, Mar 26, 2020 at 8:18 PM Staf Verhaegen <staf@fibraservi.eu> wrote:
> > Luke Kenneth Casson Leighton schreef op do 26-03-2020 om 13:05 [+0000]:
> > > On Thursday, March 26, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:
> > > > Would like to make separate side remark here. In ASICs MUXes are relativeexpensive gates with respect to delay and power. So if this principle isgenerally applied over the whole design it will make it difficult to make achip that is competitive in power/performance compared to ARM/x86 CPUs.
> > > 
> > > 
> > > just the ALU pipeline registers.  we felt that the advantage of being ableto drop to say 500mhz and halve the number of pipeline stages to say 5, andalso be able to ramp up to 1.6ghz and double bavk up to 10 stages, wasworth considering.
> > 
> > What would be the advantage over running at 800Mhz with 5 pipeline stages ?
> 
> i assume you mean fixed 5-pipeline stages.
> the problem is, if you *want* to run at 1.6ghz and have complexpipeline stages, you simply can't: 5 stages are too long, the gatepropagation delay is too large.  the only way to get to 1.6hz is:split those 5 stages into 10 smaller stages.
> the problem with _that_ is: if you then run those 10 stages at say800mhz, or say even 400 mhz or 100mhz (because you are in power-savingmode), you just *massively* increased the latency for completion ofany given operation.
> so even though those 10 stages are so fast (because you are in 14nm)that, at 100mhz, they complete in under 5% of a 100mhz clock rate, ifyou have a fixed 10-stage pipeline you are absolutely screwed, you*have* to have the penalty of the 10-stage pipeline latency.
> screwed 1:  5-stage pipeline FORCES you to ONLY be able to run atBELOW (e.g) 800mhz
> screwed 2: 10-stage pipeline FORCES you to have massive instructioncompletion latency at below (e.g.) 800mhz.
> solution: give every other pipeline stage's registers a "combinatorial bypass".
> un-screwed 1: when speed is above 800mhz, switch off the combinatorialbypass, pipeline becomes 10-stage.
> un-screwed 2: when speed is below 800mhz, switch ON the combinatorialbypass, latency due to slower clock rate DISAPPEARS because allpipelines are now only 5-stage, not 10.

My point is that you will have the same performance for the fixed 5-stage pipeline running @ 800MHz as for the 10-stage pipeline running @ 1600MHz. Why do want to run @1600MHz ?
Actually the fixed 5-stage 800MHz capable pipeline will not be able to run @1600MHz when converted to configurable 5/10-stage pipeline due to the additional delay from the MUXes inserted in the path plus the fact that you likely can't split up each stage in two stages with each exact the half of the delay.
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

Re: [libre-riscv-dev] cache SRAM organisation

[Luke Kenneth Casson Leighton]

On Fri, Mar 27, 2020 at 9:25 AM Staf Verhaegen <staf@fibraservi.eu> wrote:

> My point is that you will have the same performance for the fixed 5-stage pipeline running @ 800MHz

no, it won't: it'll be half the clock speed.  it won't be double the
number of computations: it'll be the exact same number of
computations.  therefore, half the speed means half the number of
computations because the *throughput* is the same

when you use "cpufreq-set" to change the clock rate, if the clock rate
is halved, the computer is twice as slow.

yes it's confusing :)

you may be thinking that the pipeline is split into *two halves*, each
half processing separate computations.  this is not the case.


> as for the 10-stage pipeline running @ 1600MHz. Why do want to run @1600MHz ?

because you get double the performance by doing so (with increase in
power consumption of course).

when bypass latches are closed:

* maximum speed: 800 mhz
* stages: 5
* latency (completion time): 1.25e-9 times 5 = 6.25e-9
* throughput: 800 MOPS

when bypass latches are open:

* maximum speed: 1600 mhz (double - appx)
* stages: 10 (double)
* latency (completion time): 6.25e-10 times *10* = 6.25e-9 *EXACTLY THE SAME*
* throughput: 1600 MOPS *DOUBLE THE MOPS*

when bypass latches are open and we run at 800mhz:

* actual speed: 800 mhz
* stages: 10 (double)
* latency (completion time): 1.25e-9 times *10* = 1.25e-8 *HALF THE LATENCY*
* throughput: 800 MOPS *SAME*

so this should show why we want to do this: you get better latency,
which in turn means that there is less pressure on us to have massive
number of Function Units (particularly Branch Prediction Units), to
compensate for huge pipeline lengths.


> Actually the fixed 5-stage 800MHz capable pipeline will not be able to
> run @1600MHz when converted to configurable 5/10-stage pipeline
> due to the additional delay from the MUXes inserted in the path
> plus the fact that you likely can't split up each stage in two stages with
> each exact the half of the delay.

yes, very much agreed.  we will need to do some careful analysis (when
there is time!  this is very much for "revision 2") right down at the
gate level.

also, it may turn out that we simply can't run certain stages at that
kind of speed, or other factors which we haven't anticipated.

in the meantime, however, things like the MUL code (which is based on
a Wallace Multiplier and needs converting to Dadda) have been
*specifically* designed as easy-to-connect combinatorial blocks, with
the "joining" part done as nmigen OO classes that can be *dynamically
replaced* by us, as programmers.

and we are currently using that flexibility to combine *multiple
combinatorial blocks* in a chain... *and* to combine those further
blocks into pipeline-latched blocks.

so if we find that one particular combinatorial chain is too long to
fit into a single 1600mhz pipeline phase, then "oh dear, whoops", all
we do is, find that code, tweak a couple of parameters in a few files,
and the combinatorial chain is now split into additional pipeline
stages.

not, "argh we have a massive redesign to do".


it's a new idea: we just have to experiment, see what happens.
honestly, if we hit even 1200mhz for a first ASIC (in 45 or 28 nm)
that would be absolutely fantastic.

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] cache SRAM organisation

[Lauri Kasanen]

On Fri, 27 Mar 2020 09:44:30 +0000
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> when bypass latches are open and we run at 800mhz:
>
> * actual speed: 800 mhz
> * stages: 10 (double)
> * latency (completion time): 1.25e-9 times *10* = 1.25e-8 *HALF THE LATENCY*

Sorry, but isn't that double the latency?

- Lauri

_______________________________________________
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] cache SRAM organisation

[Luke Kenneth Casson Leighton]

On Fri, Mar 27, 2020 at 10:02 AM Lauri Kasanen <cand@gmx.com> wrote:
>
> On Fri, 27 Mar 2020 09:44:30 +0000
> Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>
> > when bypass latches are open and we run at 800mhz:
> >
> > * actual speed: 800 mhz
> > * stages: 10 (double)
> > * latency (completion time): 1.25e-9 times *10* = 1.25e-8 *HALF THE LATENCY*
>
> Sorry, but isn't that double the latency?

sigh, yeeees :)

_______________________________________________
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] cache SRAM organisation

[Staf Verhaegen]

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

Luke Kenneth Casson Leighton schreef op vr 27-03-2020 om 09:44 [+0000]:
> On Fri, Mar 27, 2020 at 9:25 AM Staf Verhaegen <staf@fibraservi.eu> wrote:
> > My point is that you will have the same performance for the fixed 5-stage pipeline running @ 800MHz
> 
> no, it won't: it'll be half the clock speed.  it won't be double thenumber of computations: it'll be the exact same number ofcomputations.  therefore, half the speed means half the number ofcomputations because the *throughput* is the same
> when you use "cpufreq-set" to change the clock rate, if the clock rateis halved, the computer is twice as slow.

You are right.

> yes it's confusing :)

Yes and no, it is the basic functionality of a pipeline :(
You have the same latency but can have double the number of operations in flight.

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

Re: [libre-riscv-dev] cache SRAM organisation

[Luke Kenneth Casson Leighton]

On Fri, Mar 27, 2020 at 10:36 AM Staf Verhaegen <staf@fibraservi.eu> wrote:

> Yes and no, it is the basic functionality of a pipeline :(

yes.

> You have the same latency but can have double the number of operations in flight.

yes.  hence why it is so important to have, because double the number
of operations means that we need double the number of Function Units
in the Dependency Matrix in order to keep the entire out-of-order
engine occupied.

also, double the number of operations in flight means that we need
double the number of Branch Prediction Units, and much more complex
BPUs at that, just to deal with the (now very likely) scenario of
having far more overlapping inner loops "in flight".

all this from just extending the pipeline length(s) from 5 to 10.  so
it's not just a "nice-to-have" feature, it's actually really important
to keeping the overall size of the chip down.

l.

_______________________________________________
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] Clock Gating (was cache SRAM organisation)

[Staf Verhaegen]

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

Luke Kenneth Casson Leighton schreef op vr 27-03-2020 om 10:59 [+0000]:
> On Fri, Mar 27, 2020 at 10:36 AM Staf Verhaegen <staf@fibraservi.eu> wrote:
> > Yes and no, it is the basic functionality of a pipeline :(
> 
> yes.
> > You have the same latency but can have double the number of operations in flight.
> 
> yes.  hence why it is so important to have, because double the numberof operations means that we need double the number of Function Unitsin the Dependency Matrix in order to keep the entire out-of-orderengine occupied.
> also, double the number of operations in flight means that we needdouble the number of Branch Prediction Units, and much more complexBPUs at that, just to deal with the (now very likely) scenario ofhaving far more overlapping inner loops "in flight".
> all this from just extending the pipeline length(s) from 5 to 10.  soit's not just a "nice-to-have" feature, it's actually really importantto keeping the overall size of the chip down.

There is an (IMO better) alternative for what you are doing with your pass-through registers and that is clock gating (wikipedia, allaboutcircuits).
The principle is that you save power by not clocking the parts of the circuit that don't have to do any computing. I think this could be a more general way to only enable the stages in your pipeline who actually are doing computation.
In the above example you would always use a 10 stage pipeline running at 1600MHz but to mimic the 5-stage pipeline you only submit an operation every other clock cycle and intermittently enable the odd and even stages in your pipeline. This way the MUXes are removed from the computation path.
Using a shift register it could be easily generalized to only enable the stages for which there is an operation going through the pipeline. When an operation is submitted you set the first bit in the shift register to enable the first stage in the pipeline. With each cycle you then shift this bit so the stage that is needed for the execution of that operation is active.
This is generalized power optimization because it means that if you are running a program that only uses integer operations your FPU and GPU with use almost no power.

The way to implement it is using EnableInserter. Some untested code how I think it can be done:

	stages_en = Signal(10)
	stage1 = EnableInserter(stages_en[0])(Stage1())
	stage2 = EnableInserter(stages_en[1])(Stage2())
	...

	m.d.sync += stages_en.eq(Cat(newop, stages_en[0:9]))

That said I think this feature does not fit in the MVP scope of the October prototype so that chip should IMO not use clock gating nor the pass-through register feature from the original discussion. Reason is that implementing it is easier said than done. Several things need to be done:
- You first need a clock gating cell. This is not available in nsxlib and is currently not planned to be implemented. I don't want to commit to something extra for the May test chip tape-out either.
- nmigen/yosys needs to properly support clock gating for ASICs. Likely this means work in yosys that insert the clock gates from if clauses in the RTL.
- Your P&R tool (e.g. Coriolis) needs to support the clock gates. It means your clock tree synthesis (CTS) needs to support more than just buffers in the clock tree. This is not a simple task and has to be discussed with Jean-Paul & co.

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

Re: [libre-riscv-dev] Clock Gating (was cache SRAM organisation)

[Luke Kenneth Casson Leighton]

On Sat, Mar 28, 2020 at 2:08 PM Staf Verhaegen <staf@fibraservi.eu> wrote:

> There is an (IMO better) alternative for what you are doing with your pass-through registers and that is clock gating (wikipedia, allaboutcircuits).

ok that's very valuable and appreciated.  will reply here
http://bugs.libre-riscv.org/show_bug.cgi?id=270

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