From: lkcl <lkcl@web>
Date: Tue, 10 Sep 2019 19:16:51 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: convert-csv-opcode-to-binary~4126
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=8324897d196c05f9afff1c02ad69b9e13327dd03;p=libreriscv.git

---

diff --git a/ztrans_proposal.mdwn b/ztrans_proposal.mdwn
index f8d7974dd..82c967c81 100644
--- a/ztrans_proposal.mdwn
+++ b/ztrans_proposal.mdwn
@@ -413,6 +413,57 @@ FATANH      | inverse hyperbolic tan   | rd = atanh(rs1)         | Zfhyp |
 
 Note (1): FATAN/FATANPI is a pseudo-op expanding to FATAN2/FATAN2PI (needs deciding)
 
+# Subsets
+
+## Zftrans
+
+Zftrans contains standard transcendentals best suited to 3D. They are also the minimum subset for synthesising atan, acos and so on.
+
+
+
+## ZftransExt
+
+LOG, EXP, EXP10, LOG10
+
+These are extra transcendental functions that are useful, not generally needed for 3D, however for Numerical Computation they may be useful.
+
+Although they can be synthesised using Ztrans (LOG2 multiplied by a constant), there is both a performance penalty as well as an accuracy penalty towards the limits, which for IEEE754 compliance is unacceptable.
+
+Their forced inclusion would be inappropriate as it would penalise embedded systems with tight power and area budgets.  However if they were completely excluded the HPC applications would be penalised on performance and accuracy.
+
+Therefore they are their own subset extension.
+
+## Ztrigpi vs Ztrignpi
+
+* **Ztrigpi**: trig. xxx-pi sinpi cospi tanpi
+* **Ztrignpi**: trig non-xxx-pi sin cos tan
+
+Ztrignpi are the basic trigonometric functions through which all others could be synthesised. However as can be seen from other sections, there is an accuracy penalty for doing so which will not be acceptable for IEEE754 compliance.
+
+In the case of the Ztrigpi subset, these are commonly used in for loops with a power of two number of subdivisions, and the cost of multiplying by PI is not an acceptable one.
+
+In for example CORDIC the multiplication by PI may be moved outside of the hardware algorithm as a loop invariant, with no power or area penalty.
+
+Thus again, the same argument applies to give Ztrignpi and Ztrigpi as subsets.
+
+## Zarctrigpi and Zarctrignpi
+
+* **Zarctrigpi**: arc-trig. a-xxx-pi: atan2pi asinpi acospi
+* **Zarctrignpi**: arc-trig. non-a-xxx-pi: atan2, asin, acos
+
+These are extra trigonometric functions that are useful in some applications.
+
+Although they can be synthesised using Ztrigpi and Ztrignpi, there is both a performance penalty as well as an accuracy penalty towards the limits, which for IEEE754 compliance is unacceptable, yet is acceptable for 3D.
+
+Their forced inclusion would be inappropriate as it would penalise embedded systems with tight power and area budgets.  However if they were completely excluded the HPC applications would be penalised on performance and accuracy.
+
+Therefore they are their own subset extension.
+
+* **Zfhyp**: hyperbolic/inverse-hyperbolic.  sinh, cosh, tanh, asinh,
+  acosh, atanh (can be synthesised - see below)
+* **ZftransAdv**: much more complex to implement in hardware
+* **Zfrsqrt**: Reciprocal square-root.
+
 # Synthesis, Pseudo-code ops and macro-ops
 
 The pseudo-ops are best left up to the compiler rather than being actual