ed/cb0f44ea28f288113bd97549c5f456cf24388f

   1 Return-path: <libre-riscv-dev-bounces@lists.libre-riscv.org>
   2 Envelope-to: publicinbox@libre-riscv.org
   3 Delivery-date: Fri, 27 Mar 2020 09:25:39 +0000
   4 Received: from localhost ([::1] helo=libre-riscv.org)
   5         by libre-riscv.org with esmtp (Exim 4.89)
   6         (envelope-from <libre-riscv-dev-bounces@lists.libre-riscv.org>)
   7         id 1jHlFC-0002wu-RM; Fri, 27 Mar 2020 09:25:38 +0000
   8 Received: from vps2.stafverhaegen.be ([85.10.201.15])
   9  by libre-riscv.org with esmtp (Exim 4.89)
  10  (envelope-from <staf@fibraservi.eu>) id 1jHlFB-0002wo-1Q
  11  for libre-riscv-dev@lists.libre-riscv.org; Fri, 27 Mar 2020 09:25:37 +0000
  12 Received: from hpdc7800 (hpdc7800 [10.0.0.1])
  13  by vps2.stafverhaegen.be (Postfix) with ESMTP id C48B511C05D7
  14  for <libre-riscv-dev@lists.libre-riscv.org>;
  15  Fri, 27 Mar 2020 10:25:36 +0100 (CET)
  16 Message-ID: <6fbfb2a3258be77f4fce69661b283dc31a683f7b.camel@fibraservi.eu>
  17 From: Staf Verhaegen <staf@fibraservi.eu>
  18 To: libre-riscv-dev@lists.libre-riscv.org
  19 Date: Fri, 27 Mar 2020 10:25:24 +0100
  20 In-Reply-To: <CAPweEDwznLD5o6rHfWsSXR-8e1hbAfAB04f5O+YkL6pCwGsNfQ@mail.gmail.com>
  21 References: <CAPweEDx5QCCKxSr1gfuyuw_2D68Ld8fK85bEmmMTZi8S3w2E9g@mail.gmail.com>
  22  <29b1a9ecedda151dc9c8da6516c3691dfede62ef.camel@fibraservi.eu>
  23  <CAPweEDwfqMczPjg=5Fvt1J_S8nx1YK44XhyBY8H1abuTNF6=xg@mail.gmail.com>
  24  <6fa40cb78b3f8c013ca4953ccb4daa5c23e3b501.camel@fibraservi.eu>
  25  <CAPweEDxiyTEsneXN65Kq0HsEsdL3wdY=NYayq2tz5egXJNCVfg@mail.gmail.com>
  26  <e430ea6587d292166fd58460adf4dfebfad20c6d.camel@fibraservi.eu>
  27  <CAPweEDzEvtPYGKvGMvebmQzhJDhSgfvUOVZvB2WXxSbv_ebE8A@mail.gmail.com>
  28  <b18283c7e7a93fa8afdef2f0a8679b26e4569528.camel@fibraservi.eu>
  29  <CAPweEDwznLD5o6rHfWsSXR-8e1hbAfAB04f5O+YkL6pCwGsNfQ@mail.gmail.com>
  30 Organization: FibraServi bvba
  31 X-Mailer: Evolution 3.28.5 (3.28.5-5.el7)
  32 Mime-Version: 1.0
  33 X-Content-Filtered-By: Mailman/MimeDel 2.1.23
  34 Subject: Re: [libre-riscv-dev] cache SRAM organisation
  35 X-BeenThere: libre-riscv-dev@lists.libre-riscv.org
  36 X-Mailman-Version: 2.1.23
  37 Precedence: list
  38 List-Id: Libre-RISCV General Development
  39  <libre-riscv-dev.lists.libre-riscv.org>
  40 List-Unsubscribe: <http://lists.libre-riscv.org/mailman/options/libre-riscv-dev>,
  41  <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=unsubscribe>
  42 List-Archive: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/>
  43 List-Post: <mailto:libre-riscv-dev@lists.libre-riscv.org>
  44 List-Help: <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=help>
  45 List-Subscribe: <http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev>,
  46  <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=subscribe>
  47 Reply-To: Libre-RISCV General Development
  48  <libre-riscv-dev@lists.libre-riscv.org>
  49 Content-Type: multipart/mixed; boundary="===============2592891676999365254=="
  50 Errors-To: libre-riscv-dev-bounces@lists.libre-riscv.org
  51 Sender: "libre-riscv-dev" <libre-riscv-dev-bounces@lists.libre-riscv.org>
  52
  53
  54 --===============2592891676999365254==
  55 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
  56         boundary="=-VGIfDE4gJhKTDrBI5//N"
  57
  58
  59 --=-VGIfDE4gJhKTDrBI5//N
  60 Content-Type: text/plain; charset="UTF-8"
  61 Content-Transfer-Encoding: quoted-printable
  62
  63 Luke Kenneth Casson Leighton schreef op do 26-03-2020 om 21:37 [+0000]:
  64 > ---crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma6=
  65 8
  66 >=20
  67 > On Thu, Mar 26, 2020 at 8:18 PM Staf Verhaegen <staf@fibraservi.eu> wrote=
  68 :
  69 > > Luke Kenneth Casson Leighton schreef op do 26-03-2020 om 13:05 [+0000]:
  70 > > > On Thursday, March 26, 2020, Staf Verhaegen <staf@fibraservi.eu> wrot=
  71 e:
  72 > > > > Would like to make separate side remark here. In ASICs MUXes are re=
  73 lativeexpensive gates with respect to delay and power. So if this principle=
  74  isgenerally applied over the whole design it will make it difficult to mak=
  75 e achip that is competitive in power/performance compared to ARM/x86 CPUs.
  76 > > >=20
  77 > > >=20
  78 > > > just the ALU pipeline registers.  we felt that the advantage of being=
  79  ableto drop to say 500mhz and halve the number of pipeline stages to say 5=
  80 , andalso be able to ramp up to 1.6ghz and double bavk up to 10 stages, was=
  81 worth considering.
  82 > >=20
  83 > > What would be the advantage over running at 800Mhz with 5 pipeline stag=
  84 es ?
  85 >=20
  86 > i assume you mean fixed 5-pipeline stages.
  87 > the problem is, if you *want* to run at 1.6ghz and have complexpipeline s=
  88 tages, you simply can't: 5 stages are too long, the gatepropagation delay i=
  89 s too large.  the only way to get to 1.6hz is:split those 5 stages into 10 =
  90 smaller stages.
  91 > the problem with _that_ is: if you then run those 10 stages at say800mhz,=
  92  or say even 400 mhz or 100mhz (because you are in power-savingmode), you j=
  93 ust *massively* increased the latency for completion ofany given operation.
  94 > so even though those 10 stages are so fast (because you are in 14nm)that,=
  95  at 100mhz, they complete in under 5% of a 100mhz clock rate, ifyou have a =
  96 fixed 10-stage pipeline you are absolutely screwed, you*have* to have the p=
  97 enalty of the 10-stage pipeline latency.
  98 > screwed 1:  5-stage pipeline FORCES you to ONLY be able to run atBELOW (e=
  99 .g) 800mhz
 100 > screwed 2: 10-stage pipeline FORCES you to have massive instructioncomple=
 101 tion latency at below (e.g.) 800mhz.
 102 > solution: give every other pipeline stage's registers a "combinatorial by=
 103 pass".
 104 > un-screwed 1: when speed is above 800mhz, switch off the combinatorialbyp=
 105 ass, pipeline becomes 10-stage.
 106 > un-screwed 2: when speed is below 800mhz, switch ON the combinatorialbypa=
 107 ss, latency due to slower clock rate DISAPPEARS because allpipelines are no=
 108 w only 5-stage, not 10.
 109
 110 My point is that you will have the same performance for the fixed 5-stage p=
 111 ipeline running @ 800MHz as for the 10-stage pipeline running @ 1600MHz. Wh=
 112 y do want to run @1600MHz ?
 113 Actually the fixed 5-stage 800MHz capable pipeline will not be able to run =
 114 @1600MHz when converted to configurable 5/10-stage pipeline due to the addi=
 115 tional delay from the MUXes inserted in the path plus the fact that you lik=
 116 ely can't split up each stage in two stages with each exact the half of the=
 117  delay.
 118 greets,
 119 Staf.
 120
 121
 122
 123
 124 --=-VGIfDE4gJhKTDrBI5//N--
 125
 126
 127
 128 --===============2592891676999365254==
 129 Content-Type: text/plain; charset="utf-8"
 130 MIME-Version: 1.0
 131 Content-Transfer-Encoding: base64
 132 Content-Disposition: inline
 133
 134 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlicmUtcmlz
 135 Y3YtZGV2IG1haWxpbmcgbGlzdApsaWJyZS1yaXNjdi1kZXZAbGlzdHMubGlicmUtcmlzY3Yub3Jn
 136 Cmh0dHA6Ly9saXN0cy5saWJyZS1yaXNjdi5vcmcvbWFpbG1hbi9saXN0aW5mby9saWJyZS1yaXNj
 137 di1kZXYK
 138
 139 --===============2592891676999365254==--
 140
 141
 142