From: lkcl Date: Thu, 11 May 2023 16:14:45 +0000 (+0100) Subject: (no commit message) X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=0177df8f2bba2996defe8411f19d74438f0514d0;p=libreriscv.git --- diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn index 1293ccf17..0f198f13e 100644 --- a/openpower/sv/svp64.mdwn +++ b/openpower/sv/svp64.mdwn @@ -372,7 +372,7 @@ the example having VL=5. Thus on "wrapping" - sequential progression from GPR(1) into GPR(2) - the 5th result modifies **only** the bottom 16 LSBs of GPR(1). -Hardware Architectural note: to avoid a Read-Modify-Write at the register +*Engineering note: to avoid a Read-Modify-Write at the register file it is strongly recommended to implement byte-level write-enable lines exactly as has been implemented in DRAM ICs for many decades. Additionally the predicate mask bit is advised to be associated with the element @@ -384,8 +384,8 @@ predicate mask bit corresponds directly with one single byte-level write-enable line. It is up to the Hardware Architect to then amortise (merge) elements together into both PredicatedSIMD Pipelines as well as simultaneous non-overlapping Register File writes, to achieve High -Performance designs. Overall it helps to think of the register files -as being much more akin to a byte-level-addressable SRAM. +Performance designs. Overall it helps to think of the GPR and FPR +register files as being much more akin to a 64-bit-wide byte-level-addressable SRAM.* If the 16-bit operation were to be followed up with a 32-bit Vectorised Operation, the exact same contents would be viewed as follows: