Automatic commit of irc logs
[ipdf/documents.git] / LiteratureNotes.tex
index 08b23e1..1d4fe12 100644 (file)
@@ -45,9 +45,8 @@
 \lstset{showstringspaces=false}
 \lstset{basicstyle=\small}
 
-
-
-
+\newcommand{\shell}[1]{\texttt{#1}}
+\newcommand{\code}[1]{\texttt{#1}}
 
 \begin{document}
 
@@ -453,6 +452,60 @@ It also mentions VHDL.
 So whenever hardware papers come up, VHDL gets involved...
 I guess it's time to try and work out how to use the Opensource VHDL implementations.
 
+This is about reduction of error in hardware operations rather than the precision or range of floats.
+But it is probably still relevant.
+
+\section{Floating Point Unit from JOP\cite{jop}}
+
+This is a 32 bit floating point unit developed for JOP in VHDL.
+I have been able to successfully compile it and the test program using GHDL\cite{ghdl}. 
+
+Whilst there are constants (eg: \verb/FP_WIDTH = 32, EXP_WIDTH = 8, FRAC_WIDTH = 23/) defined, the actual implementation mostly uses magic numbers, so 
+some investigation is needed into what, for example, the "52" bits used in the sqrt units are for.
+
+\section{GHDL\cite{ghdl}}
+
+GHDL is an open source GPL licensed VHDL compiler written in Ada. It had packages in debian up until wheezy when it was removed. However the sourceforge site still provides a \shell{deb} file for wheezy.
+
+This reference explains how to use the \shell{ghdl} compiler, but not the VHDL language itself.
+
+GHDL is capable of compiling a ``testbench'' - essentially an executable which simulates the design and ensures it meets test conditions.
+A common technique is using a text file to provide the inputs/outputs of the test. The testbench executable can be supplied an argument to save a \shell{vcd} file which can be viewed in \shell{gtkwave} to see timing diagrams.
+
+Sam has successfully compiled the VHDL design for an FPU in JOP\cite{jop} into a ``testbench'' executable which uses standard i/o instead of a regular file.
+Using unix domain sockets we can execute the FPU as a child process and communicate with it from our document viewing test software. This means we can potentially simulate alternate hardware designs for FPUs and witness the effect they will have on precision in the document viewer.
+
+Using \shell{ghdl} the testbench can also be linked as part a C/C++ program and run using a function; however there is still no way to communicate with it other than forking a child process and using a unix domain socket anyway. Also, compiling the VHDL FPU as part of our document viewer would clutter the code repository and probably be highly unportable. The VHDL FPU has been given a seperate repository.
+
+\section{On the design of fast IEEE floating-point adders\cite{seidel2001onthe}}
+
+This paper gives an overview of the ``Naive'' floating point addition/subtraction algorithm and gives several optimisation techniques:
+
+TODO: Actually understand these...
+
+\begin{itemize}
+       \item Use parallel paths (based on exponent)
+       \item Unification of significand result ranges
+       \item Reduction of IEEE rounding modes
+       \item Sign-magnitude computation of a difference
+       \item Compound Addition
+       \item Approximate counting of leading zeroes
+       \item Pre-computation of post-normalization shift
+\end{itemize}
+
+They then give an implementation that uses these optimisation techniques including very scary looking block diagrams.
+
+They simulated the FPU. Does not mention what simulation method was used directly, but cites another paper (TODO: Look at this. I bet it was VHDL).
+
+The paper concludes by summarising the optimisation techniques used by various adders in production (in 2001).
+
+This paper does not specifically mention the precision of the operations, but may be useful because a faster adder design might mean you can increase the precision.
+
+
+% Back to software
+\section{Basic Issues in Floating Point Arithmetic and Error Analysis\cite{demmel1996basic}}
+
+These are lecture notes from U.C Berkelye CS267 in 1996.
 
 
 \pagebreak

UCC git Repository :: git.ucc.asn.au