From 2e432d1ddf8ef828803d17d218e99868557012e3 Mon Sep 17 00:00:00 2001 From: Staf Verhaegen Date: Wed, 25 Mar 2020 14:46:38 +0100 Subject: [PATCH] Re: [libre-riscv-dev] cache SRAM organisation --- 5b/15fc37dd069db57cab23724bc8322e5e3f50c4 | 114 ++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 5b/15fc37dd069db57cab23724bc8322e5e3f50c4 diff --git a/5b/15fc37dd069db57cab23724bc8322e5e3f50c4 b/5b/15fc37dd069db57cab23724bc8322e5e3f50c4 new file mode 100644 index 0000000..a82d831 --- /dev/null +++ b/5b/15fc37dd069db57cab23724bc8322e5e3f50c4 @@ -0,0 +1,114 @@ +Return-path: +Envelope-to: publicinbox@libre-riscv.org +Delivery-date: Wed, 25 Mar 2020 13:46:48 +0000 +Received: from localhost ([::1] helo=libre-riscv.org) + by libre-riscv.org with esmtp (Exim 4.89) + (envelope-from ) + id 1jH6Mp-00089v-2r; Wed, 25 Mar 2020 13:46:47 +0000 +Received: from vps2.stafverhaegen.be ([85.10.201.15]) + by libre-riscv.org with esmtp (Exim 4.89) + (envelope-from ) id 1jH6Mn-00089p-KY + for libre-riscv-dev@lists.libre-riscv.org; Wed, 25 Mar 2020 13:46:45 +0000 +Received: from hpdc7800 (hpdc7800 [10.0.0.1]) + by vps2.stafverhaegen.be (Postfix) with ESMTP id 0B10E11C05D7 + for ; + Wed, 25 Mar 2020 14:46:45 +0100 (CET) +Message-ID: <6fa40cb78b3f8c013ca4953ccb4daa5c23e3b501.camel@fibraservi.eu> +From: Staf Verhaegen +To: libre-riscv-dev@lists.libre-riscv.org +Date: Wed, 25 Mar 2020 14:46:38 +0100 +In-Reply-To: +References: + <29b1a9ecedda151dc9c8da6516c3691dfede62ef.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="===============8740498451903336715==" +Errors-To: libre-riscv-dev-bounces@lists.libre-riscv.org +Sender: "libre-riscv-dev" + + +--===============8740498451903336715== +Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; + boundary="=-O0Ns1JbYWRcANIlKQerj" + + +--=-O0Ns1JbYWRcANIlKQerj +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Luke Kenneth Casson Leighton schreef op wo 25-03-2020 om 12:33 [+0000]: +> On Wednesday, March 25, 2020, Staf Verhaegen wrote: +> > A single port SRAM has one port where you can do a read or a write each= +clock cycle. The 2-port one has one read port and one write port so you can= +do a read and write each clock cycle. The dual port one now has two portsth= +at each can do a read or write each clock cycle. So you can do two reads,tw= +o write or a read+write each clock cycle.For each of them you can have a sy= +nchronous or an asynchronous version. Asynchronous RAM has a clock input an= +d the address and data inputs arelatched on that clock signal. It thus mean= +s that the FFs are integrated inthe SRAM, e.g. thus very close :) . The RAM= + currently being developed in myNLNet project is a synchronous SRAM as this= + is easier from timing point ofview because all the timing can be related t= +o the clock. A synchronous RAMactually functions as an addressable bunch of= + FFs and the synthesis and P&Rtools know how to handle them. +>=20 +> ok. later, we will definitely need an aysynchronous version. + +Keep the discussion on development of other types til after the prototype t= +ape-out in October. I know there is other development ongoing for dual port= + RAM in the OpenRAM community so likely it is more clear what extra still h= +as to happen. +BTW, I think there also is possibility to have register files block with 2R= +1W RAM blocks. + +> this because it turns out that asynchronous SRAM can act, when used in aR= +egister File, as if it was a (separate) Register Bypass / ForwardingPort. = +with the Out-of-Order Engine being a huge cyclic feedback loopbetween ALUs = +and RegFile, clock delays are an impediment, and havingcompletely separate = +(extra) Regfile Bypass ports dramatically increases thenumber of wires and = +Multiplexers. + +Could detail more on how the adress, data and output signals of this asynch= +ronous block would be used and switched between synchronous and asynchronou= +s functioning. To me it seems that it would just place of the multiplexers,= + not the amount. + +greets, +Staf. + +--=-O0Ns1JbYWRcANIlKQerj-- + + + +--===============8740498451903336715== +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: base64 +Content-Disposition: inline + +X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlicmUtcmlz +Y3YtZGV2IG1haWxpbmcgbGlzdApsaWJyZS1yaXNjdi1kZXZAbGlzdHMubGlicmUtcmlzY3Yub3Jn +Cmh0dHA6Ly9saXN0cy5saWJyZS1yaXNjdi5vcmcvbWFpbG1hbi9saXN0aW5mby9saWJyZS1yaXNj +di1kZXYK + +--===============8740498451903336715==-- + + + -- 2.30.2