From: Staf Verhaegen Date: Thu, 26 Mar 2020 12:18:53 +0000 (+0100) Subject: Re: [libre-riscv-dev] cache SRAM organisation X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=de4ee9363cded25d4b56e0b87c6e9221451d7aff;p=libre-riscv-dev.git Re: [libre-riscv-dev] cache SRAM organisation --- diff --git a/ed/598b014a04c4c101eab61cba5dd4865a6e37ce b/ed/598b014a04c4c101eab61cba5dd4865a6e37ce new file mode 100644 index 0000000..2a28705 --- /dev/null +++ b/ed/598b014a04c4c101eab61cba5dd4865a6e37ce @@ -0,0 +1,141 @@ +Return-path: +Envelope-to: publicinbox@libre-riscv.org +Delivery-date: Thu, 26 Mar 2020 12:19:01 +0000 +Received: from localhost ([::1] helo=libre-riscv.org) + by libre-riscv.org with esmtp (Exim 4.89) + (envelope-from ) + id 1jHRTP-0005nQ-Va; Thu, 26 Mar 2020 12:18:59 +0000 +Received: from vps2.stafverhaegen.be ([85.10.201.15]) + by libre-riscv.org with esmtp (Exim 4.89) + (envelope-from ) id 1jHRTO-0005nK-AE + for libre-riscv-dev@lists.libre-riscv.org; Thu, 26 Mar 2020 12:18:58 +0000 +Received: from hpdc7800 (hpdc7800 [10.0.0.1]) + by vps2.stafverhaegen.be (Postfix) with ESMTP id 9FFAC11C05B7 + for ; + Thu, 26 Mar 2020 13:18:57 +0100 (CET) +Message-ID: +From: Staf Verhaegen +To: libre-riscv-dev@lists.libre-riscv.org +Date: Thu, 26 Mar 2020 13:18:53 +0100 +In-Reply-To: +References: + <29b1a9ecedda151dc9c8da6516c3691dfede62ef.camel@fibraservi.eu> + + <6fa40cb78b3f8c013ca4953ccb4daa5c23e3b501.camel@fibraservi.eu> + +Organization: FibraServi bvba +X-Mailer: Evolution 3.28.5 (3.28.5-5.el7) +Mime-Version: 1.0 +X-Content-Filtered-By: Mailman/MimeDel 2.1.23 +Subject: Re: [libre-riscv-dev] cache SRAM organisation +X-BeenThere: libre-riscv-dev@lists.libre-riscv.org +X-Mailman-Version: 2.1.23 +Precedence: list +List-Id: Libre-RISCV General Development + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +Reply-To: Libre-RISCV General Development + +Content-Type: multipart/mixed; boundary="===============2305731690204497899==" +Errors-To: libre-riscv-dev-bounces@lists.libre-riscv.org +Sender: "libre-riscv-dev" + + +--===============2305731690204497899== +Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; + boundary="=-ikvahZFcA7Cn0qEbbFmM" + + +--=-ikvahZFcA7Cn0qEbbFmM +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +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 wrote= +: +>=20 +> > > this because it turns out that asynchronous SRAM can act, when used i= +n aRegister File, as if it was a (separate) Register Bypass / ForwardingPor= +t. with the Out-of-Order Engine being a huge cyclic feedback loopbetween A= +LUs and RegFile, clock delays are an impediment, and havingcompletely separ= +ate (extra) Regfile Bypass ports dramatically increases thenumber of wires = +and Multiplexers. +> >=20 +> > Could detail more on how the adress, data and output signals of this as= +ynchronous block would be used and switched between synchronous and asynchr= +onous functioning. To me it seems that it would just place of the multiplex= +ers, not the amount. +>=20 +> 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"sy= +nchronous" mode of nmigen Memory. the requirements are: what iswritten has= + to be available *combinatorially* - i.e. on the same clockcycle - if simul= +taneously 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 sa= +me 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) sig= +nal. 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 orthogo= +nal to each other. +The current synchronous SRAM being developed will most likely have write-th= +rough behavior; will be confirmed before May test chip tape-out. It will ca= +use delay on the signal though. I need to check if it has changed but in th= +e 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 inc= +lude MUXs as said in Jacob's reply to allow the bypass ofsignal. I have see= +n SRAM that did include a AWT (asynchronous write through) but this just mo= +ved the MUXs inside the SRAM block and also adds them if you don't need thi= +s AWT. So I would like to keep these MUX be added added externally is neede= +d. +In theory on a single port SRAM +> a workaround (fallback position) is, we use DFF latches. i created a"byp= +ass latch" function which creates DFF latches with such acombinatorial bypa= +ss: we actually use them quite a lot (includingbetween pipeline stages so t= +hat 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 s= +ome Function Units will be sitting idle,waiting for their input operands, w= +hich have to come from otherFunction Units as "results". + +I can understand you do this to implement functional units with configurabl= +e pipeline length but I would strongly discourage to pipeline register file= +s after each other . If the latter is excluded would you still need an asyn= +chronous RAM block ? + +greets, +Staf. + + + +--=-ikvahZFcA7Cn0qEbbFmM-- + + + +--===============2305731690204497899== +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: base64 +Content-Disposition: inline + +X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlicmUtcmlz +Y3YtZGV2IG1haWxpbmcgbGlzdApsaWJyZS1yaXNjdi1kZXZAbGlzdHMubGlicmUtcmlzY3Yub3Jn +Cmh0dHA6Ly9saXN0cy5saWJyZS1yaXNjdi5vcmcvbWFpbG1hbi9saXN0aW5mby9saWJyZS1yaXNj +di1kZXYK + +--===============2305731690204497899==-- + + +