[Oberon] Floating Point in PFPGA Oberon

Skulski, Wojciech skulski at pas.rochester.edu
Tue Oct 6 05:08:28 CEST 2020


let me throw in a few observations on the floating point in FPGA Oberon. 

1) You said that erroneous conversion from internal binary to the ASCII string is "surprisingly an extremely difficult task". Fortunately, printing the numbers is "just software" which can be fixed, though I am not sure when and by whom. 

2) But you also said that "floating-point hardware itself isn't fit for IEEE 754". This looks more serious to me. The FP *firmware* in FPGA Oberon consists of FPAdder.v, FPMultiplier.v, and FPDivider.v. The documentation in Chapter 16 of PO.Computer consists of only two pages (starts on page 8). These pages do not look like comprehensive a proof that the algorithm has been accurately and correctly expressed in the Verilog code.

3) I am not aware of test results proving the correct operation of these Verilog modules in corner cases. How sure can we be that the results are always correct, if there are no test results to prove it?

An alternative to present firmware might consist of using well tested cores, either open source or commercial. I made a quick search for floating point firmware implementations. I searched Google for "xilinx floating point dsp slice".

Here are some results.

An interesting paper "ITERATIVE FLOATING POINT COMPUTATION USING FPGA DSP BLOCKS" by Fredrik Brosser, Hui Yan Cheah, Suhaib A. Fahmy is available from the web. It mentions FloPoCo among other topics. Their implementation is worth looking at because quite likely Wirth's implementation is quite similar. (Search the web for

Open source arithmetic and floating point cores.

4) A comprehensive open source website "FPGA Arithmetic the way it should be". The documentation is very comprehensive and the code itself is supported by the authors. 

4.1.  Home page http://flopoco.gforge.inria.fr/  
4.2.  Operator list for FloPoCo version 4.1.2 http://flopoco.gforge.inria.fr/operators_4.1.2.html
4.3.  Two page "Reflections on 10 years of FloPoCo" is linked in the 1st paragraph of 4.1.

Xilinx cores available for free under either ISE or Vivado.

Neither one is open source, but they can be instantiated for free in Xilinx projects. They are extensively documented and tested. Their interfaces look nasty to me, but they can be wrapped into the present Oberon firmware interfaces.

5) ISE 14.x Core Generator is providing Floating Point operator v 5.0 for Spartan-3 and upwards. Described in data sheet DS335 March 1, 2011 included in the ISE 14.x Core Generator

Supported operations: 
• multiply
• add/subtract
• divide
• square-root
• comparison
• conversion from floating-point to fixed-point
• conversion from fixed-point to floating-point
• conversion between floating-point types

6) Vivado is providing Floating Point operator v 7.x for Series-7 and upwards, described in Product Guide PG060 (LogiCORE IP Floating-Point Operator v7.0). 

Supported operators:
° Multiply
° Add/subtract
° Accumulator
° Fused multiply-add
° Divide
° Square-root
° Comparison
° Reciprocal
° Reciprocal square root
° Absolute value
° Natural logarithm
° Exponential
° Conversion from floating-point to fixed-point
° Conversion from fixed-point to floating-point
° Conversion between floating-point types

My assessment of Xilinx Floating Point operators

° Interfaces are nasty. They will require unpleasant Verilog or VHDL wrappers.
° Extensively documented and tested. Unlikely to contain major bugs.
° Compatible with IEEE standard. Departures from the standard are documented..
° Not portable to non-Xilinx FPGAs
° Operator 5.0 does not provide transcendental functions
° Operator 7.0 provides more functions, including logarithm and exponential

My assessment of FloPoCo

° Promising, but requires more time to digest the documentation. (The reverse of the present Oberon FP firmware.)


From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Joerg [joerg.straube at iaeth.ch]
Sent: Sunday, October 4, 2020 3:38 AM
To: ETH Oberon and related systems
Subject: Re: [Oberon] [EXT] Re: Wrong output of Texts.WriteReal and     Texts.WriteRealFix      in      PO

> I suspect the floating-point hardware itself isn't fit for IEEE 754

You‘re right; NaN (NaNs and NaNq) is not implemented in RISC5.
Converting correctly strings to/from floating is surprisingly an extremely difficult task.

One quick remark:
It is true that FLOOR cannot handle values >MAX (2^31-1=2147483647) as those values cannot be stored in an RISC-5 INTEGER.
Remember that on RISC-5 i = FLOOR(FLT(i)) is not guaranteed to be true for INTEGERs i > 16777216


More information about the Oberon mailing list