Envelope-to: publicinbox@libre-riscv.org
Delivery-date: Tue, 19 May 2020 13:30:31 +0100
Message-ID: <a4306686aa33a177b2c3c3668d740a50fece0f9d.camel@fibraservi.eu>
From: Staf Verhaegen <staf@fibraservi.eu>
To: Libre-RISCV General Development <libre-riscv-dev@lists.libre-riscv.org>
Date: Tue, 19 May 2020 14:30:23 +0200
In-Reply-To: <CAPweEDyF42ND9xF=Rat1yv2+M1+VtrX1bgRSrMJbAyaThcjfnw@mail.gmail.com>
References: <CAPweEDyF42ND9xF=Rat1yv2+M1+VtrX1bgRSrMJbAyaThcjfnw@mail.gmail.com>
Organization: FibraServi bvba
Mime-Version: 1.0
Subject: Re: [libre-riscv-dev] daily kan-ban update 18may2020
Precedence: list
Reply-To: Libre-RISCV General Development
 <libre-riscv-dev@lists.libre-riscv.org>
Content-Type: multipart/mixed; boundary="===============9015389145604249614=="
Errors-To: libre-riscv-dev-bounces@lists.libre-riscv.org
Sender: "libre-riscv-dev" <libre-riscv-dev-bounces@lists.libre-riscv.org>


--===============9015389145604249614==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-xK/O/tGs5dCealA5HP1p"


--=-xK/O/tGs5dCealA5HP1p
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Luke Kenneth Casson Leighton schreef op ma 18-05-2020 om 12:45 [+0100]:
> * and had a fascinating conversation thanks to yehowshua and jeremy(also =
welcome!), which resulted in this(https://libre-soc.org/3d_gpu/architecture=
/tomasulo_transformation/).

If I understand this correct the big architectural difference between exten=
ded scoreboarding and Tomasulo is that in the former the register content i=
s stored in a central register file and for the latter it is distributed ov=
er several 'reservation stations'. In order to scale to for example multi-i=
ssue you need to go to higher order nRmW register files for scoreboarding a=
nd for Tomasulo you increase the number of reservation stations together wi=
th a more complex tracker of the register tagging/aliasing.
So some 2 cents from me.
=46rom physical implementation point of view the central high order nRmW regi=
ster file and scoreboard does worry me. Higher order nRmW register files wi=
ll become power and area hungry compared to multiple lower order reservatio=
n stations.
I have seen numbers of a few tens of functional units in your design. I thi=
nk it will become also a nightmare to connect and route all the input and o=
utputs of all the functional units to the central register file and scorebo=
ard. So at first sight, from physical implementation point for smaller node=
s, the Tomasulo algorithm seems more scalable than extended scoreboarding. =
I indicated before that in smaller nodes power consumption and delay is mai=
nly determined by the length of the interconnects and not by the input load=
 of the logic gates itself; in 180nm it will be more fifty/fifty. As Jeremy=
 indicated this is next to the power consumption in the register files and =
cache which scales with the total bit count of the block and the nRmW order=
 of the block.
Also the travialness of a big fan-in NOR or NAND gate may be deceptive, the=
se gates are not feasible and will be synthesized to trees of NAND/NOR gate=
s. In that respect a high fan-in NOR/NAND can have similar time/power consu=
mption than a seemingly more complex case of if statement. In zero order, f=
or single output block, delay and power is determined by the number of inpu=
ts independent of the complexity of the RTL/HDL code. In first order one ha=
s to account that NAND/NOR logic is more efficient than XOR/XNOR logic but =
for bigger trees this difference is less pronounced as XOR/XNOR trees will =
be synthesized to more efficient trees using AOI (and-or-invert) cells.

greets,
Staf.


--=-xK/O/tGs5dCealA5HP1p--


--===============9015389145604249614==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlicmUtcmlz
Y3YtZGV2IG1haWxpbmcgbGlzdApsaWJyZS1yaXNjdi1kZXZAbGlzdHMubGlicmUtcmlzY3Yub3Jn
Cmh0dHA6Ly9saXN0cy5saWJyZS1yaXNjdi5vcmcvbWFpbG1hbi9saXN0aW5mby9saWJyZS1yaXNj
di1kZXYK

--===============9015389145604249614==--