ed/598b014a04c4c101eab61cba5dd4865a6e37ce

   1 Return-path: <libre-riscv-dev-bounces@lists.libre-riscv.org>
   2 Envelope-to: publicinbox@libre-riscv.org
   3 Delivery-date: Thu, 26 Mar 2020 12:19:01 +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 1jHRTP-0005nQ-Va; Thu, 26 Mar 2020 12:18:59 +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 1jHRTO-0005nK-AE
  11  for libre-riscv-dev@lists.libre-riscv.org; Thu, 26 Mar 2020 12:18:58 +0000
  12 Received: from hpdc7800 (hpdc7800 [10.0.0.1])
  13  by vps2.stafverhaegen.be (Postfix) with ESMTP id 9FFAC11C05B7
  14  for <libre-riscv-dev@lists.libre-riscv.org>;
  15  Thu, 26 Mar 2020 13:18:57 +0100 (CET)
  16 Message-ID: <db557324bcb76a999d8f66c75b9319974a1a1e08.camel@fibraservi.eu>
  17 From: Staf Verhaegen <staf@fibraservi.eu>
  18 To: libre-riscv-dev@lists.libre-riscv.org
  19 Date: Thu, 26 Mar 2020 13:18:53 +0100
  20 In-Reply-To: <CAPweEDxiyTEsneXN65Kq0HsEsdL3wdY=NYayq2tz5egXJNCVfg@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 Organization: FibraServi bvba
  27 X-Mailer: Evolution 3.28.5 (3.28.5-5.el7)
  28 Mime-Version: 1.0
  29 X-Content-Filtered-By: Mailman/MimeDel 2.1.23
  30 Subject: Re: [libre-riscv-dev] cache SRAM organisation
  31 X-BeenThere: libre-riscv-dev@lists.libre-riscv.org
  32 X-Mailman-Version: 2.1.23
  33 Precedence: list
  34 List-Id: Libre-RISCV General Development
  35  <libre-riscv-dev.lists.libre-riscv.org>
  36 List-Unsubscribe: <http://lists.libre-riscv.org/mailman/options/libre-riscv-dev>,
  37  <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=unsubscribe>
  38 List-Archive: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/>
  39 List-Post: <mailto:libre-riscv-dev@lists.libre-riscv.org>
  40 List-Help: <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=help>
  41 List-Subscribe: <http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev>,
  42  <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=subscribe>
  43 Reply-To: Libre-RISCV General Development
  44  <libre-riscv-dev@lists.libre-riscv.org>
  45 Content-Type: multipart/mixed; boundary="===============2305731690204497899=="
  46 Errors-To: libre-riscv-dev-bounces@lists.libre-riscv.org
  47 Sender: "libre-riscv-dev" <libre-riscv-dev-bounces@lists.libre-riscv.org>
  48
  49
  50 --===============2305731690204497899==
  51 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
  52         boundary="=-ikvahZFcA7Cn0qEbbFmM"
  53
  54
  55 --=-ikvahZFcA7Cn0qEbbFmM
  56 Content-Type: text/plain; charset="UTF-8"
  57 Content-Transfer-Encoding: quoted-printable
  58
  59 Luke Kenneth Casson Leighton schreef op wo 25-03-2020 om 15:53 [+0000]:
  60 > On Wed, Mar 25, 2020 at 1:46 PM Staf Verhaegen <staf@fibraservi.eu> wrote=
  61 :
  62 >=20
  63 > > > this because it turns out that asynchronous SRAM can act, when used i=
  64 n aRegister File, as if it was a (separate) Register Bypass / ForwardingPor=
  65 t.  with the Out-of-Order Engine being a huge cyclic feedback loopbetween A=
  66 LUs and RegFile, clock delays are an impediment, and havingcompletely separ=
  67 ate (extra) Regfile Bypass ports dramatically increases thenumber of wires =
  68 and Multiplexers.
  69 > >=20
  70 > > Could detail more on how the adress, data and output signals of this as=
  71 ynchronous block would be used and switched between synchronous and asynchr=
  72 onous functioning. To me it seems that it would just place of the multiplex=
  73 ers, not the amount.
  74 >=20
  75 > ok i will try to outine it, there is quite a lot of detail, i apologise.
  76 > it's basically the "pass-through" system used in nmigen FIFOs, and the"sy=
  77 nchronous" mode of nmigen Memory.  the requirements are: what iswritten has=
  78  to be available *combinatorially* - i.e. on the same clockcycle - if simul=
  79 taneously read via another port.
  80 > now, yes i took note that this is not supposed to be permitted: you'renot=
  81  normally permitted to be able to read *and* write to an SRAM cellat the sa=
  82 me time.  however, that's exactly what we need.
  83
  84 You seem to mixing up two different concepts, e.g. synchronicity and write-=
  85 through. Synchronous means signals are synced with an edge of a (clock) sig=
  86 nal. SRAM write-through means that after a write operation you also get on =
  87 the Q output the data you have just written. These two concepts are orthogo=
  88 nal to each other.
  89 The current synchronous SRAM being developed will most likely have write-th=
  90 rough behavior; will be confirmed before May test chip tape-out. It will ca=
  91 use delay on the signal though. I need to check if it has changed but in th=
  92 e OpenRAM 0.35um test tape-out I did the address and data input was latched=
  93  on rising edge and the Q output was updated on falling edge of the clock. =
  94 So the delay on the Q output is half a clock cycle plus the internal delay =
  95 on the output latch enable signal.
  96 So if timing of the write-through is critical it is still best to still inc=
  97 lude MUXs as said in Jacob's reply to allow the bypass ofsignal. I have see=
  98 n SRAM that did include a AWT (asynchronous write through) but this just mo=
  99 ved the MUXs inside the SRAM block and also adds them if you don't need thi=
 100 s AWT. So I would like to keep these MUX be added added externally is neede=
 101 d.
 102 In theory on a single port SRAM
 103 > a workaround (fallback position) is, we use DFF latches.  i created a"byp=
 104 ass latch" function which creates DFF latches with such acombinatorial bypa=
 105 ss: we actually use them quite a lot (includingbetween pipeline stages so t=
 106 hat we can programmatically cut the numberof pipeline stages in half at the=
 107  flick of a switch).
 108 > however for the Register File we would not "switch" betweensynchronous / =
 109 asynchronous mode.  the reason why we need thesynchronous mode is because s=
 110 ome Function Units will be sitting idle,waiting for their input operands, w=
 111 hich have to come from otherFunction Units as "results".
 112
 113 I can understand you do this to implement functional units with configurabl=
 114 e pipeline length but I would strongly discourage to pipeline register file=
 115 s after each other . If the latter is excluded would you still need an asyn=
 116 chronous RAM block ?
 117
 118 greets,
 119 Staf.
 120
 121
 122
 123 --=-ikvahZFcA7Cn0qEbbFmM--
 124
 125
 126
 127 --===============2305731690204497899==
 128 Content-Type: text/plain; charset="utf-8"
 129 MIME-Version: 1.0
 130 Content-Transfer-Encoding: base64
 131 Content-Disposition: inline
 132
 133 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlicmUtcmlz
 134 Y3YtZGV2IG1haWxpbmcgbGlzdApsaWJyZS1yaXNjdi1kZXZAbGlzdHMubGlicmUtcmlzY3Yub3Jn
 135 Cmh0dHA6Ly9saXN0cy5saWJyZS1yaXNjdi5vcmcvbWFpbG1hbi9saXN0aW5mby9saWJyZS1yaXNj
 136 di1kZXYK
 137
 138 --===============2305731690204497899==--
 139
 140
 141