Jamil Khatib

OpenHWproject template

Contents

1  List of authors and changes

Name	Changes	Date	Contact address
Jamil Khatib	Initial release	17-7-2000	khatib@opencores.org

2  Project Definition

2.1  Introduction

2.2  Objectives

3  Specifications

3.1  System Specification

• The core should be compliant with the IEEE-754 standard.
• The core is going to have several phases one phase for each precision.
• The speed performance gets the highest priority in the first phases.
• Software support should be provided to handle the compiler, assembler, traps, higher precisions and extra calculations.
• Supported instructions TBD. web site has some suggestions.

3.2  External Interfaces

• The core should be as an execution unit of the OpenRisc1000 cpu.

• In next steps the core should be able to interface to any CPU core.

• The core should give interrupts to the CPU upon exceptions.

• operand A (32 bits for single precision FPU)
• operand B (32 bits for single precision FPU)
• type of operation performed (? bits)
• Mask exception flags interface

Outputs from the FPU:

• result (32 bits for single precision FPU)
• status flag outputs (overflow, NAN, INF ... )
• Interrupt signal

OR1K issue and completion units will know what gets in the FPU and when result should come out. If you the calculation times can be variable for the SAME type of operation then we need extra outputs.OR1K core will decide whether can issue FP instructions or not (detect hazards etc.).

3.3  Hardware specification

• In the first core (that is an execution unit to OR1K) the CPU should be responsible for instruction decoding, data path control ...

• All calculations should be done on the minimum supported extended precision.

3.4  Software specification

3.5  Interface between SW and HW

4  Internal Blocks

The hardware can be divided into the following main blocks:

• Execution Units
  • All blocks should take the operands in decoded format

  • So they should have the ability to take non-normalized inputs.

  • They can generate non-normalized results

  • They should have the ability to take and generate the special values.

  • Each block should generate all 5 exceptions that are connected to the flag status block.

  • Execution units are composed of Add/Subtract, Multiply, Divide, Compare and some transidantal units (TBD)

• Status/Mask flags block
  • This block is connected to all execution units.
  • The user should have the ability to read and mask the flags.
  • The flags should remain set as long as the software do not unset them.
  • The CPU should be interrupted upon any generation of unmasked exception.
  • The software should handle the flags to prevent frequent generation of interrupts and it also trap and handle all exceptions and modify the results upon the source of exception.

• Decode unit that decodes numbers into the the extended format with the hidden bit.

• Encode/Round result that rounds the extended results into the specified precision.

5  Design description

5.1  Decode Unit

5.1.1  Design notes

• It decodes numbers into the the extended format with the hidden bit.
• It is needed to enable all calculation be made on extended precision.
• The conversion is made as shown in the flow chart.
• The core uses single level of registers.

5.1.2  Timing and flow charts

5.2  Adder/Subtracter Unit

5.2.1  Design notes

• Invert the sign of the second operator in case of subtraction.
• Check if the one of the operands is a special number (NaN or Infinity)
• If NaN is one of the operands the result is NaN
• If ¥ check if the operation is ¥-¥ then NaN and Invalid exception is generated
• The operands can be non-normalized and also the results
• check if the result over or under flows regarding the used precision.
• The unit needs two cycles to get the result.

5.2.2  Timing and flow charts

5.3  Compare Unit

5.3.1  Design notes

• Check if one of the operands is NaN so the result is False
• Check the sign of the operands
• Equalize the two exponents and then check the fractions
• There is no need to have a special case for Infiity
• This unit does not generate exceptions
• It needs two cycles to get the result

5.3.2  Timing and flow charts

5.4  Scripts, files and any other information

5.5  Design conventions and coding styles

5.6  Design Modeling

6  Testing and verifications

6.1  Simulation and Test benches

Test benches should be made for each execution block at least to verify their operations with any interference from other blocks.

Specifications of test benches TBD.

6.2  verification techniques and algorithms

The functional verifications will be made in two steps

1. Through SW verification by set of test vectors and checking versus IEEE-754 compliant software.

2. Through prototyping on FPGA and testing it on real operations and calculations.

6.2.1  Verification Software

• The software should generate test vectors for the test benches (at least for the main test bench).

• It should generate numbers and operations randomly for the test bench.

• It should to read mathematical formulae and generate sequence of numbers and operations to the test bench.

• There should be a method to compare the results from the real calculations done on the CPU and from the fpu core.

• All results from test bench and software should be in readable format with the ability to show all bit representations.

• The software should have the ability to generate operations that give special numbers (infinity, zeros and NaN) and all kind of exceptions.

• The software should know when the special numbers are going to be generated and not to calculate them using the normal software flow, else it will fail because the results will be handled by host traps.

6.3  Test plans

Testing should take care of complex operations and well known bugs cased by sequence of operations.

Test plans, equations and operations are TBD

7  Implementations

8  Reviews and comments

9  References