4d/308ca4191db4ebbab634351025cd3a566c71d3

   1 Return-path: <libre-riscv-dev-bounces@lists.libre-riscv.org>
   2 Envelope-to: publicinbox@libre-riscv.org
   3 Delivery-date: Wed, 25 Mar 2020 10:54:33 +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 1jH3g8-0006Xs-H7; Wed, 25 Mar 2020 10:54:32 +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 1jH3g7-0006Xm-BV
  11  for libre-riscv-dev@lists.libre-riscv.org; Wed, 25 Mar 2020 10:54:31 +0000
  12 Received: from hpdc7800 (hpdc7800 [10.0.0.1])
  13  by vps2.stafverhaegen.be (Postfix) with ESMTP id 96CA511C027D
  14  for <libre-riscv-dev@lists.libre-riscv.org>;
  15  Wed, 25 Mar 2020 11:54:30 +0100 (CET)
  16 Message-ID: <29b1a9ecedda151dc9c8da6516c3691dfede62ef.camel@fibraservi.eu>
  17 From: Staf Verhaegen <staf@fibraservi.eu>
  18 To: Libre RISC-V dev list <libre-riscv-dev@lists.libre-riscv.org>
  19 Date: Wed, 25 Mar 2020 11:54:20 +0100
  20 In-Reply-To: <CAPweEDx5QCCKxSr1gfuyuw_2D68Ld8fK85bEmmMTZi8S3w2E9g@mail.gmail.com>
  21 References: <CAPweEDx5QCCKxSr1gfuyuw_2D68Ld8fK85bEmmMTZi8S3w2E9g@mail.gmail.com>
  22 Organization: FibraServi bvba
  23 X-Mailer: Evolution 3.28.5 (3.28.5-5.el7)
  24 Mime-Version: 1.0
  25 X-Content-Filtered-By: Mailman/MimeDel 2.1.23
  26 Subject: Re: [libre-riscv-dev] cache SRAM organisation
  27 X-BeenThere: libre-riscv-dev@lists.libre-riscv.org
  28 X-Mailman-Version: 2.1.23
  29 Precedence: list
  30 List-Id: Libre-RISCV General Development
  31  <libre-riscv-dev.lists.libre-riscv.org>
  32 List-Unsubscribe: <http://lists.libre-riscv.org/mailman/options/libre-riscv-dev>,
  33  <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=unsubscribe>
  34 List-Archive: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/>
  35 List-Post: <mailto:libre-riscv-dev@lists.libre-riscv.org>
  36 List-Help: <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=help>
  37 List-Subscribe: <http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev>,
  38  <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=subscribe>
  39 Reply-To: Libre-RISCV General Development
  40  <libre-riscv-dev@lists.libre-riscv.org>
  41 Content-Type: multipart/mixed; boundary="===============2511390821872612374=="
  42 Errors-To: libre-riscv-dev-bounces@lists.libre-riscv.org
  43 Sender: "libre-riscv-dev" <libre-riscv-dev-bounces@lists.libre-riscv.org>
  44
  45
  46 --===============2511390821872612374==
  47 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
  48         boundary="=-hcKE8vRVlmNXPJh1IKgI"
  49
  50
  51 --=-hcKE8vRVlmNXPJh1IKgI
  52 Content-Type: text/plain; charset="UTF-8"
  53 Content-Transfer-Encoding: quoted-printable
  54
  55 Libre-SOC developers,
  56
  57 That discussion is mainly on system level and I don't want to get too deep =
  58 into this as I don't have time for that.
  59 I am providing the SRAM blocks and then it is up to the system guys to see =
  60 how they use them. In this case you guys (libre-soc + LIP6) are the system =
  61 guys.
  62
  63 On ASICs commonly three types of SRAM are provided: a single port RAM, a 2-=
  64 port RAM and a dual port RAM. Currently for NLNet only a single port SRAM i=
  65 s foreseen as this is the most common, the smallest in area per bit and the=
  66  fastest.
  67 A single port SRAM has one port where you can do a read or a write each clo=
  68 ck cycle. The 2-port one has one read port and one write port so you can do=
  69  a read and write each clock cycle. The dual port one now has two ports tha=
  70 t each can do a read or write each clock cycle. So you can do two reads, tw=
  71 o write or a read+write each clock cycle.
  72 For each of them you can have a synchronous or an asynchronous version. A s=
  73 ynchronous RAM has a clock input and the address and data inputs are latche=
  74 d on that clock signal. It thus means that the FFs are integrated in the SR=
  75 AM, e.g. thus very close :) . The RAM currently being developed in my NLNet=
  76  project is a synchronous SRAM as this is easier from timing point of view =
  77 because all the timing can be related to the clock. A synchronous RAM actua=
  78 lly functions as an addressable bunch of FFs and the synthesis and P&R tool=
  79 s know how to handle them.
  80
  81 Given this building block you can now make blocks that look to the outside =
  82 world as higher number port blocks. You do this by instantiating multiple R=
  83 AM blocks and make sure that the content is mirrored between all the blocks=
  84 . This way you can read from the different blocks in parallel. Writing in t=
  85 he blocks still has to happen to all the blocks at the same time.
  86
  87 So if you take four single port SRAM blocks you can make a four port SRAM b=
  88 lock. Each cycle you can do 1-4 reads or 1 write but you can't read and wri=
  89 te at the same time. With four 2-port RAMs you can do 4 reads and 1 write e=
  90 ach clock cycle. With four dual port RAMs you can do 4 reads or 3 reads + 1=
  91  write or 2 reads + 2 writes each cycle.
  92 I will provide the single block, the combining of the block has to happen i=
  93 n RTL/HDL. For Libre-SOC this means in nmigen and using Coriolis for placem=
  94 ent and connecting the single blocks.
  95
  96 Although the SRAM does an operation each clock cycle the clock frequency co=
  97 uld be different from the rest of the logic. If the RAM is fast enough it c=
  98 ould run at double the frequency of the core so basically a single port RAM=
  99  could look like a dual port RAM to the rest of the logic which is running =
 100 at half the frequency. If the RAM is not fast enough wait  states need to b=
 101 e implemented for each operation. The maximum clock frequency will go down =
 102 when you increase the size of a RAM block. So on CPU typically L1 cache run=
 103 s at the same clock frequency as the core without any wait states and highe=
 104 r level caches are bigger but also introduce more wait states for accessing=
 105  them.
 106 If you are thinking about having different clock frequencies in your design=
 107  you have to first discuss this with Jean-Paul/LIP6 as doing multi clock de=
 108 signs is opening it's own can of worms (cross clock domain problems etc). F=
 109 or the October prototype I feel we need to stick with use of single port SR=
 110 AM block and run the whole chip from the same clock. IMO, on this prototype=
 111  you should take any performance implication this has.
 112
 113 greets,
 114 Staf.
 115 Luke Kenneth Casson Leighton schreef op di 24-03-2020 om 22:32 [+0000]:
 116 > https://groups.google.com/d/msg/comp.arch/cbGAlcCjiZE/mgMZVINVIAAJ
 117 > Staf can i ask you the favour of reviewing Mitch's comments about cache d=
 118 esign?
 119 > in particular the comments about the possibility of using multiported SRA=
 120 M cells as long as only 1R or 1W is done on any given cell?
 121 > also something about doing the FFs yourself, close to the SRAM cells?
 122 > l.
 123 >=20
 124 >=20
 125
 126
 127
 128
 129 --=-hcKE8vRVlmNXPJh1IKgI--
 130
 131
 132
 133 --===============2511390821872612374==
 134 Content-Type: text/plain; charset="utf-8"
 135 MIME-Version: 1.0
 136 Content-Transfer-Encoding: base64
 137 Content-Disposition: inline
 138
 139 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlicmUtcmlz
 140 Y3YtZGV2IG1haWxpbmcgbGlzdApsaWJyZS1yaXNjdi1kZXZAbGlzdHMubGlicmUtcmlzY3Yub3Jn
 141 Cmh0dHA6Ly9saXN0cy5saWJyZS1yaXNjdi5vcmcvbWFpbG1hbi9saXN0aW5mby9saWJyZS1yaXNj
 142 di1kZXYK
 143
 144 --===============2511390821872612374==--
 145
 146
 147