From: lkcl Date: Sun, 10 Jan 2021 00:28:52 +0000 (+0000) Subject: (no commit message) X-Git-Tag: convert-csv-opcode-to-binary~497 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=8d177c36b72a86bb389bff8b2a237ada9c2fb7f6;p=libreriscv.git --- diff --git a/openpower/sv/overview.mdwn b/openpower/sv/overview.mdwn index 517bdf0ef..aa0498a0e 100644 --- a/openpower/sv/overview.mdwn +++ b/openpower/sv/overview.mdwn @@ -466,10 +466,9 @@ bits will be *unaltered*. Note that things such as zero/sign-extension (and predication) have been left out to illustrate the elwidth concept. Also note that it turns -out to be important to perform the operation at the maximum bitwidth - -`max(srcwid, destwid)` - such that any truncation, rounding errors or +out to be important to perform the operation internally at effectively an *infinite* bitwidth such that any truncation, rounding errors or other artefacts may all be ironed out. This turns out to be important -when applying Saturation for Audio DSP workloads. +when applying Saturation for Audio DSP workloads, particularly for multiply and IEEE754 FP rounding. By "infinite" this is conceptual only: in reality, the application of the different truncations and width-extensions set a fixed deterministic practical limit on the internal precision needed, on a per-operation basis. Other than that, element width overrides, which can be applied to *either* source or destination or both, are pretty straightforward, conceptually.