Libre RISC-V Mailing list Archives (accessible via public-inbox)
 help / color / Atom feed
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Libre-RISCV General Development <libre-riscv-dev@lists.libre-riscv.org>
Subject: Re: [libre-riscv-dev] cache SRAM organisation
Date: Thu, 26 Mar 2020 21:37:12 +0000
Message-ID: <CAPweEDwznLD5o6rHfWsSXR-8e1hbAfAB04f5O+YkL6pCwGsNfQ@mail.gmail.com> (raw)
In-Reply-To: <b18283c7e7a93fa8afdef2f0a8679b26e4569528.camel@fibraservi.eu>

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

  reply index

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 22:32 Luke Kenneth Casson Leighton
2020-03-25 10:54 ` Staf Verhaegen
2020-03-25 12:33   ` Luke Kenneth Casson Leighton
2020-03-25 13:46     ` Staf Verhaegen
2020-03-25 15:53       ` Luke Kenneth Casson Leighton
2020-03-25 17:49         ` Jacob Lifshay
2020-03-26 12:18         ` Staf Verhaegen
2020-03-26 12:31           ` Staf Verhaegen
2020-03-26 15:15             ` Luke Kenneth Casson Leighton
2020-03-26 15:15           ` Luke Kenneth Casson Leighton
2020-03-26 20:08             ` Staf Verhaegen
2020-03-26 21:28               ` Luke Kenneth Casson Leighton
2020-03-27  9:08                 ` Staf Verhaegen
2020-03-27  9:16                   ` Luke Kenneth Casson Leighton
2020-03-27  9:40                     ` Staf Verhaegen
2020-03-27  9:46                       ` Luke Kenneth Casson Leighton
2020-03-27  9:52                         ` Luke Kenneth Casson Leighton
2020-03-26 12:27         ` Staf Verhaegen
2020-03-26 13:05           ` Luke Kenneth Casson Leighton
2020-03-26 20:18             ` Staf Verhaegen
2020-03-26 21:37               ` Luke Kenneth Casson Leighton [this message]
2020-03-27  9:25                 ` Staf Verhaegen
2020-03-27  9:44                   ` Luke Kenneth Casson Leighton
2020-03-27 10:03                     ` Lauri Kasanen
2020-03-27 10:10                       ` Luke Kenneth Casson Leighton
2020-03-27 10:36                     ` Staf Verhaegen
2020-03-27 10:59                       ` Luke Kenneth Casson Leighton
2020-03-28 14:08                         ` [libre-riscv-dev] Clock Gating (was cache SRAM organisation) Staf Verhaegen
2020-03-28 14:26                           ` Luke Kenneth Casson Leighton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPweEDwznLD5o6rHfWsSXR-8e1hbAfAB04f5O+YkL6pCwGsNfQ@mail.gmail.com \
    --to=lkcl@lkcl.net \
    --cc=libre-riscv-dev@lists.libre-riscv.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Libre RISC-V Mailing list Archives (accessible via public-inbox)

Archives are clonable: git clone --mirror https://inbox.libre-soc.org/libre-riscv-dev

Example config snippet for mirrors


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git