Re: [libre-riscv-dev] cache SRAM organisation

diff --git a/5b/15fc37dd069db57cab23724bc8322e5e3f50c4 b/5b/15fc37dd069db57cab23724bc8322e5e3f50c4
new file mode 100644 (file)
index 0000000..a82d831
--- /dev/null
+++ b/5b/15fc37dd069db57cab23724bc8322e5e3f50c4
@@ -0,0 +1,114 @@
+Return-path: <libre-riscv-dev-bounces@lists.libre-riscv.org>
+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 <libre-riscv-dev-bounces@lists.libre-riscv.org>)
+       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 <staf@fibraservi.eu>) 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 <libre-riscv-dev@lists.libre-riscv.org>;
+ Wed, 25 Mar 2020 14:46:45 +0100 (CET)
+Message-ID: <6fa40cb78b3f8c013ca4953ccb4daa5c23e3b501.camel@fibraservi.eu>
+From: Staf Verhaegen <staf@fibraservi.eu>
+To: libre-riscv-dev@lists.libre-riscv.org
+Date: Wed, 25 Mar 2020 14:46:38 +0100
+In-Reply-To: <CAPweEDwfqMczPjg=5Fvt1J_S8nx1YK44XhyBY8H1abuTNF6=xg@mail.gmail.com>
+References: <CAPweEDx5QCCKxSr1gfuyuw_2D68Ld8fK85bEmmMTZi8S3w2E9g@mail.gmail.com>
+ <29b1a9ecedda151dc9c8da6516c3691dfede62ef.camel@fibraservi.eu>
+ <CAPweEDwfqMczPjg=5Fvt1J_S8nx1YK44XhyBY8H1abuTNF6=xg@mail.gmail.com>
+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
+ <libre-riscv-dev.lists.libre-riscv.org>
+List-Unsubscribe: <http://lists.libre-riscv.org/mailman/options/libre-riscv-dev>, 
+ <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=unsubscribe>
+List-Archive: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/>
+List-Post: <mailto:libre-riscv-dev@lists.libre-riscv.org>
+List-Help: <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=help>
+List-Subscribe: <http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev>, 
+ <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=subscribe>
+Reply-To: Libre-RISCV General Development
+ <libre-riscv-dev@lists.libre-riscv.org>
+Content-Type: multipart/mixed; boundary="===============8740498451903336715=="
+Errors-To: libre-riscv-dev-bounces@lists.libre-riscv.org
+Sender: "libre-riscv-dev" <libre-riscv-dev-bounces@lists.libre-riscv.org>
+
+
+--===============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 <staf@fibraservi.eu> 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==--
+
+
+