In the README.md, CPKAB and CPKCD operation is introduced, but I cannot get the meaning of these operations, or is there some difference between CPKAB and CPKCD? or op_mod is 0 or 1?

I read the rtl code(fpnew_opgroup_multifmt_slice.sv and fpnew_cast_multi.sv), and I tried to run some simulations to help understand,
however, when

1. src_fmt is fp64, dst_fmt is fp16, op=fpnew_pkg::CPKAB, op=0
2. src_fmt is fp64, dst_fmt is fp16, op=fpnew_pkg::CPKAB, op=1
3. src_fmt is fp64, dst_fmt is fp16, op=fpnew_pkg::CPKCD, op=0
4. src_fmt is fp64, dst_fmt is fp16, op=fpnew_pkg::CPKCD, op=1
   I got the same result.

So is there some detail description for CPKAB and CPKCD operation?
thanks.

The tags referenced in the files mentioned in the title are not consistent with the git subrepos in src. This will probably cause an inconsistent state with bender and surely with ipapprox.

Hi Team,
Is there any data about latency of operation for FDIV and FSQRT? Does the latency depends on the data width?

-Pranay

Hi,

I am running floating point example in below directory

Path : /home/pbhatt82/core-v-verif/core-v-cores/cv32e40p/example_tb/core
Command : make calculator-fp-vsim-run-gui

I am multiplying two numbers: rs1 = 0x00000000 and rs2 = 0x3a2b48ef.
I am getting the wrong result, the sign bit is high.

I am suspecting the error comes from this statement.
https://github.com/pulp-platform/fpnew/blob/0bfbeede0e01b2e44e41bb14c70a80efeffa1bbd/src/fpnew_rounding.sv#L68

@stmach @lucabertaccini

To whom it may concern,

We are from Microelectronics Research Lab (MERL), based in Pakistan working on developing RISC-V based ASICs and SoCs.

Currently we were working on developing an Indigenously design RISC-V based Floating Point Unit (AI-FPU). Initially we were using PULP FPU as a benchmark for the verification of our designed AI-FPU.

However, during the verification process we encountered few cases where the PULP FPU was not 100% compatible with Whisper ISS. A glimpse of those errors is shown in the figure attach.

Thank you,

Regards:
Engr Hamza Shabbir
Research Associate
MERL

Can this code be synthesized as it is in Synopsys DC.If not does it needs to be changed to synthesizable constructs? Thanks in advance.

When I tried to synthesis FPnew using Design Compiler (the top module is fpnew_top or fpnew_opgroup_block), the following error will always appear: "The tool has just encountered a fatal error", "Fatal: Internal system error, cannot recover".

I looked for some corresponding solutions, but they didn't help. (like: https://www.edaboard.com/threads/fatal-internal-system-error-cannot-recover.203320/)

Does anyone know the reason? For example, is the DC version I am using too low?

Hi All,

I downloaded this repository today. Can someone guide how to run the simulation?

Also, do I need a Pulp gnu toolchain to run this, or Risc-V gnu toolchain will work?

if it is useful, I am using cv32 core

Hello
@lucabertaccini @MikeOpenHWGroup @pascalgouedo @JeanRochCoulon @jquevremont

We are from Microelectronics Research Lab (MERL-DSU). MERL is an non-profitable organization with an ambitious plan to lead Microelectronics Research & Development in Pakistan. MERL is working with a Vision to enable Pakistan to become a recognized global player in the microelectronics industry. MERL's Mission is to train Undergraduate Students of Pakistan in the field of ASIC designing.

Our RTL Team has design a Simple as Possible Floating Point Unit (SAP-FPU) based on IEEE-754 format. This is the initial version which contain 22 RISC-V F-Extension Instructions. The design files are available on our github repository.

https://github.com/merldsu/SAP_FPU.git

Regards:
MERL-DSU

If a number is infinity in FP64, after converting it into FP32, will it be infinity or of max magnitude? According to spike, it is infinity but according to RTL implementation, it is of max magnitude.Actually, overflow and infinity are handled together i.e saturating it or making it max magnitude. I think it is fine to handle overflow like this, but for infinity, there should be another case i.e infinity should remain infinity.

Bug Description
Hi,

When executing the fsqrt.d instruction on a double-precision floating-point value representing positive infinity (0x7ff0000000000000), the Overflow (OF) flag in the fflags register is erroneously set. According to the IEEE 754 standard and the RISC-V specification, the fsqrt.d operation should not lead to an overflow situation when the input is infinity. This also results in inconsistency with Spike's output

Expected Behavior:
The OF flag in the fflags register should remain clear (i.e., not set) after performing a square root operation on an infinite value, as the result is well-defined and should be positive infinity.

Actual Behavior:
The OF flag is set in the fflags register, indicating an overflow, which contradicts the expected behavior defined by the IEEE 754 standard and RISC-V floating-point operation guidelines.

Steps to Reproduce:

Load a double-precision floating-point register with the value 0x7ff0000000000000 (positive infinity).
Execute the fsqrt.d instruction on this register.
Check the fflags register; observe that the OF flag is incorrectly set.

Found a bug in a floating point unit. fsgnjx.s instruction is misbehaving.

Ideally fsgnjx.s copy a signed value from one register to another register, while modifying the sign bit based on the sign from another value.

Examples:

FSGNJ.S  f2,f5,f6 	        # f2 =  sign(f6)  * |f5|
FSGNJN.S f2,f5,f6		# f2 = -sign(f6)  * |f5|
FSGNJX.S f2,f5,f6		# f2 =   sign(f6) *  f5

In case, the f6(rs2) register is infinity and the f5(rs1) register is any number, the result from spike(ISS) is the XOR of a sign of f6 (i.e. positive) with the sign bit of f5(rs1) register for FSGNJX.S instruction but the result from FPU is a NaN which is incorrect.

References

Screenshots of logs from the spike and FPU design are attached below for a reference

Hello,

I established a testbench that instanciates the fpnew_top, and I'm trying to understand how I can control the interface to feed the input operands and get the result back.

I use the following instructions inside an initial block. With MULADD operations I get the correct results, but when I change fpu_op to fpnew_pkg::SQRT or fpnew_pkg::DIV I get all zeroes at the output.

I use the same Implementation and Feature parameters used inside the EX stage of RI5CY. Simulation is performed using ModelSim 10.2c. Do you have any idea why i don't get the results for Div and Sqrt? What of ModelSim does work with your SystemVerilog testbenches?

        // The input operands
        apu_operands_i[0] = 32'b00111111100000000000000000000000; // 1.0
        apu_operands_i[1] = 32'b01000000001000000000000000000000; // 2.5
        apu_operands_i[2] = 32'b00111111100000000000000000000000; // 1.0

        // Operation to be executed
        fpu_op        = fpnew_pkg::ADD;
        fpu_vec_op    = 1'b0;
        fpu_op_mod    = 1'b0; // fpu_op = ADD && fpu_op_mod = 0 ==> ADDITION 
                                           // fpu_op = ADD && fpu_op_mod = 1 ==> SUBTRACTION 

        // Input/Output formats
        fpu_int_fmt   = fpnew_pkg::INT32;
        fpu_src_fmt   = fpnew_pkg::FP32;
        fpu_dst_fmt   = fpnew_pkg::FP32; // By default, dest types = src type. fpnew_pkg::FP32;
        fp_rnd_mode   = fpnew_pkg::RNE;

        // Ready/Valid Interface
        in_valid_i = '1;

I have also got several warnings, that I just suppressed, could these affect the results of the simulation?

vlog-2583: [SVCHK] - Some checking for conflicts with always_comb and always_latch variables not yet supported. Run vopt to provide additional design-level checks.

Thank you very much in advance.
Best regards,

I am running the CLASSIFY operation on the following configuration:

FEATURES = '{
Width: 64,
EnableVectors: 1'b1,
EnableNanBox: 1'b1,
FpFmtMask: 5'b11111,
IntFmtMask: 4'b1111};

IMPLEMENTATION = '{
PipeRegs: '{default: 0},
UnitTypes: '{'{default: fpnew_pkg::MERGED},
'{default: fpnew_pkg::MERGED},
'{default: fpnew_pkg::PARALLEL},
'{default: fpnew_pkg::MERGED}},
PipeConfig: fpnew_pkg::BEFORE};

I am providing inputs in a two FP32 element format and according to the RISC-V spec a classify instruction is supposed to give a 10-bit mask output therefore in this case I was expecting two 10-bit masks one for each of the input elements however I am getting a strange result value as seen in the image attached.

The inputs I have provided are positive normal numbers therefore I would expect two identical masks with hex values "0x0000004000000040" but the output is "0x0000000000004242".

Hi, I'm trying to push the frequency a bit higher and find that timing doesn't improve beyond a point no matter how many input/output registers I add to the divsqrt unit. There seems to be some sequential loops inside the following module.

i_fpnew_divsqrt_multi/i_divsqrt_lei/nrbd_nrsc_U0/control_U0/

Is this a known issue and is there a way around it?

Thanks,
PaulK

Hi pulp-team,
I executed the berkeley testfloat-3e in the verilator model of ri5cy core with FPU+DIV_SQRT and here are the logs of all tests of unary and binary functions. I know that it's quite common to find errors through this set of tests on any CPU but it might be helpful to check IEEE 754 compliance and what you want/or not to be compliant. Logs attached =)

Ps.: it was used the latest master branches on fpnew/riscv core (...e1910/...813a7)
Ps2.: testfloat/softfloat were compile with march:rv32imafc / mabi:ilp32f / O2

log_testfloat_3e_unary_riscv_none_embedded_ri5cy_verilator_model.txt
log_testfloat_3e_binary_riscv_none_embedded_ri5cy_verilator_model.txt

I have been using the Imperas RISV Tests included with riscvOVPsim for compliance testing and having some queries on the F ISA extension tests.

OVPSim : https://github.com/riscv-ovpsim/imperas-riscv-tests
F ISA test download page: https://www.ovpworld.org/library/wikka.php?wakka=riscvOVPsimPlus

These tests from Imperas are the updated RISCV Compliance tests and the fpnew is have some mismatches on the FDIV, FMUL and FSQRT tests.

Here are the mismatching calculations:
FPNEW_MISMATCH_COMPLIANCE_V2.xlsx

I have only seen F ISA extension tests pass with the models (e.g. C/BFM), so this suggests there is a mismatch between the RTL and models.

Can you comment on my findings?

Bug Description

When performing floating-point division using the fdiv.d instruction in CVA6, under specific conditions where the expected result is the smallest representable negative double-precision floating-point number (0xffefffffffffffff), CVA6 incorrectly returns negative infinity (0xfff0000000000000).

Steps to Reproduce:

1. Load fa7 with 0xc024000000000000.
2. Load fs3 with 0x00000000000002cc.
3. Execute the instruction: fdiv.d ft6, fa7, fs3.
4. Observe the resulting value in ft6.

The log is as follows::

core   0: 0x00000000800052b2 (0x233987d3) fsgnj.d fa5, fs3, fs3
1 0x00000000800052b2 (0x233987d3) f15 0x00000000000002cc
core   0: 0x00000000800052b6 (0x23188853) fsgnj.d fa6, fa7, fa7
1 0x00000000800052b6 (0x23188853) f16 0xc024000000000000
core   0: 0x00000000800052ba (0x1b38f353) fdiv.d  ft6, fa7, fs3
1 0x00000000800052ba (0x1b38f353) f 6 0xfff0000000000000

See: openhwgroup/cva6#2060

Hi all,
I need an FMA block that can do BF16*int8+int8. Is there a way to configure this option in the IP? If not, what are the minimum conversions I can do from int8 (actually int9) to get the FMA to work in this IP?
Any suggestions, or guidance would be appreciated.

-K

In the case where some lanes experience faster or slower execution than lane 0, the pipeline can become unsynchronized.

This can currently only happen if some lanes in the vectorial DIVSQRT unit handle special cases while others don't, but could in theory happen with any variable-latency unit (which we currently don't have).

Manually transferring this issue from here:

openhwgroup/cva6#577 (comment)

When I am trying to synthesize the design, It gives me an error in this function; any_enabled_multi in fpnew_opgroup_block.sv
Error: ../cva6/src/fpu/src/fpnew_opgroup_block.sv:81: Constant value required. (ELAB-922)

Here is the original function in fpnew_pkg.sv:

As per IEEE754-2008, Section 7.5, Exact subnormal results should not raise the underflow exception flag.

Basically all operations that can signal UF are affected.

Prefix the includes such as the following…
https://github.com/pulp-platform/fpnew/blob/b34d5f6069bf35abeb8a9b155d4f80d80dcde250/src/fpnew_divsqrt_multi.sv#L14
…with the "common_cells" directory, e.g.

`include "common_cells/registers.svh"

I think that was the intention behind creating a common_cells subdirectory in include.

FPU Configuration Discussion

There are plenty of configuration options for the FPU, almost all of which currently are passed to the top level module as parameters.
This leads to a cumbersome layout and amount of parameters, since there are options for every operation and format (the number of which can be redefined in the package).

This issue aims at finding a satisfactory solution for configuring the design. Initial considerations are:

Everything through parameters (current state)

Currently, (almost) all configuration is done through parameters. The set of available FP and int formats are set up in the package and can then be enabled/disabled via parameters.

Pros

• Full control of design-space without changing RTL for different implementation options (like varying number of pipeline stages, enabling/disabling formats or operations etc.)
• Multiple versions of the FPU within one design / project easily possible - differentiated through parameter list.

Cons

• Many parameters:
  • either a bulky array-of-arrays style parametrization (current, module interface independent of number of formats supported)
  • or a huge list of options (module interface dependent on the number of formats defined in the pkg)
• Large amount of parameters are unrolled into long and difficult to manage module names in synthesis
• Most of these parameters are not modified anymore after an initial exploration

Everything from the package

Alternatively, all configuration could be done through parameters in the package

Pros

• No parameters cluttering up the modules

Cons

• Each configuration change requires modifying the RTL
• Only one version of the package (= FPU configuration) possible in the design
• Different configurations of FPU are not discernible through module name - alignment issues more easily possible if outdated pre-compiled design and changed RTL (in case of parameter change) are combined

A mix of the two

It might make sense to reduce the number of parameters to just the most frequently modified ones. However identifying these is difficult and cons from both options might need to be dealt with..

Hi there!

Overview

While this issue showed that fdiv can return a result off by one and therefore return NaN instead of infinity,

I found that fdiv.s may return wrong results for NaN inputs, where the output is not just off by one.
Hence, this is another bug than the reported off-by-one. I do not know at the moment whether the root cause is shared.

Snippet

  .section ".text.init","ax",@progbits
  .globl _start
  .align 2
_start:

  # Enable the FPU
  li t0, 0x2000
  csrs mstatus, t0
  csrw	fcsr,x0

  la t0, .fdata0
  la t1, .fdata1
  fld ft0, (t0)
  fld ft1, (t1)

  fdiv.s ft2, ft0, ft1, rup

infinite_loop:
  j infinite_loop

.section ".fdata0","ax",@progbits
  .8byte 0xeed295ee2a0a6df4 # nan
.section ".fdata1","ax",@progbits
  .8byte 0x0707b7830687b703 # nan

We get ft2=0xffffffff63028f6f = 2.40841e+21, while the expected result is 0xffffffff7fc00000=nan, validated with spike.

Note

Interestingly, the result is also wrong with cva6 version 17743bc7120f1eb24974e5d7eb7f519ef53c4bdc, but with a different value: 0x83028f70 = -3.83682e-37.

Thanks!
Flavien

FDIV and FSQRT rounding mode calculation mismatches found when comparing the results from FPnew to a RocketChip RISCV IMAF processor.

I have attached a few examples of calculation mismatches found:
FDIV FSQRT Rounding Mode Calculation Mismatches .xlsx

Note: I have added the solution from issue #47 since it fixed rounding mode issues found when testing against the RISCV Compliance tests, and I have found there are less rounding mode issues detected with it included.

Can you comment on my findings?

Bug Description

In some rounding mode, precision errors occur when calculating fsqrt.d. And the results differ from those of Spike.
Testing has shown that RDN, RUP, RMM and DYN all experience rounding errors.

How to reproduce and the logs are as follows:
Example:
Initialize fa7 with 0x402e000000000000 and execute fsqrt.d ft10, fa7.
Under RDN, DYN Mode:

Spike results are: ft10 = 0x400efbdeb14f4eda
CVA6 results are: ft10 = 0x400efbdeb14f4ed9

Under RUP , RMM Mode:
Spike results are: ft10 = 0x400efbdeb14f4ed9
CVA6 results are: ft10 = 0x400efbdeb14f4eda

Moreover:

The vulnerability of the rounding mode mentioned above also occurs in the fdiv instruction.

Example:
When executing the instruction fdiv.d fs9, fs10, fa4 with the following register values:

fs10 = 0x41ddc16575c00000
fa4  = 0x41e0000c09000000

The results differ between CVA6 and Spike simulator as follows:
Round Toward Zero (RTZ) Mode:
CVA6 Result: 0x3fedc14f1407f47f
Spike Result: 0x3fedc14f1407f47e (correct value as verified)
Round Up (RUP), Round to Nearest, Tie to Max Magnitude (RMM), and Dynamic (DYN) Rounding Modes:
CVA6 Result: 0x3fedc14f1407f47e
Spike Result: 0x3fedc14f1407f47f

See: openhwgroup/cva6#2057

Background

I've been running functional tests/validation on this fpu, by running test vectors generated by testfloat. http://www.jhauser.us/arithmetic/TestFloat.html

I've noticed a class of bugs around the underflow flag. Here are some errors produced by testfloat:

Errors found in f32_mul, rounding near_even:
+01.000000  +7E.7FFFFF  => +01.000000 ....x  expected +01.000000 ...ux
+01.000000  -7E.7FFFFF  => -01.000000 ....x  expected -01.000000 ...ux
+01.7FFFFF  +7E.000000  => +01.000000 ....x  expected +01.000000 ...ux
 
Errors found in f32_mulAdd, rounding min:
+54.61FFFE  -02.70001F  -00.7FFFFF
=> -01.000000 ....x  expected -01.000000 ...ux
+00.000001  -7D.7FBFFF  -00.7FFFFF
=> -01.000000 ....x  expected -01.000000 ...ux

This effects the FMA operations using the Multiply operation, (MUL, F[N]MADD, F[N]MSUB). And the DIV operation (Using t-head div/sqrt)
This bug shows up for all rounding modes except RTZ.

Issue

The fact that this does not effect the RTZ rounding mode led me to this statement in the spec:

This bug is the corner case, where the final result is +/-b^emin, but the unbounded exponent range lies strictly between +/-b^emin. In this case it appears that the underflow flag should be set, which is what happens in softfloat, but not happening in the FMA or t-head DIV unit.

In RTZ mode you can never hit the case where you round from a subnormal result into a normal result.

Bug Description

When executing the fsqrt.d instruction on a double-precision floating-point value representing positive infinity (0x7ff0000000000000), the Overflow (OF) flag in the fflags register is erroneously set. According to the IEEE 754 standard and the RISC-V specification, the fsqrt.d operation should not lead to an overflow situation when the input is infinity. This also results in inconsistency with Spike's output

Expected Behavior:
The OF flag in the fflags register should remain clear (i.e., not set) after performing a square root operation on an infinite value, as the result is well-defined and should be positive infinity.

Actual Behavior:
The OF flag is set in the fflags register, indicating an overflow, which contradicts the expected behavior defined by the IEEE 754 standard and RISC-V floating-point operation guidelines.

Steps to Reproduce:

1. Load a double-precision floating-point register with the value 0x7ff0000000000000 (positive infinity).
2. Execute the fsqrt.d instruction on this register.
3. Check the fflags register; observe that the OF flag is incorrectly set.

EDIT: A PR has been submitted pulp-platform/fpu_div_sqrt_mvp#25

EDIT: And See: openhwgroup/cva6#2058

Hi there!

I found a bug in FPnew (bug found through Ariane).

Bug

The operand_c should not be signed for floating multiplications using RDN.

Observable consequences

The floating multiplication gives wrong results for some inputs with the RDN rounding mode.

For example, the pseudo assembly code below executes incorrectly:

ft0 = 0x0 # corresponds to value +0.0
ft1 = 0x00000000dc98da8a # corresponds to value +1.82854e-314

fmul.d ft2, ft1, ft0

In the end of the snippet:

• We expect the result to be 0x0, i.e., +0.0
• We get the result 0x8000000000000000, i.e., -0.0

Related issues

This seems to be the underlying cause of the observations made in openhwgroup/core-v-verif#54, openhwgroup/core-v-verif#63, part of openhwgroup/core-v-verif#68, this external issue in core-v-verif and this external issue in cv32e40p.

Hi,
I need an FMA block which can do BF16*int8+int8. Is there a way to configure this option in the IP? If not, what are the minimum conversions I can do from int8 (actually int9) to get the FMA to work in this IP?
Any suggestions, guidance would be appreciated.

I tried to run fcvt.s.d to convert a small double (2.386004908190509275e-40 which is 0x37b4c8f800000000) into single, but it gives inf (0x7f800000) instead of 2.38600491e-40 (0x0002991f).

Hi there!

fsqrt was known to produce some off-by-one errors, and may return 1 on canonical NaN.

This snippet shows that additionally to these known problems, fsqrt.s can return large valid floating-point numbers instead of NaNs, when the input is a non-canonical NaN.
Hence, this is another bug than the reported off-by-one. I do not know at the moment whether the root cause is shared.

  .section ".text.init","ax",@progbits
  .globl _start
  .align 2
_start:

  # Enable the FPU
  li t0, 0x2000
  csrs mstatus, t0
  csrw	fcsr,x0

  la t0, .fdata0
  fld ft0, (t0)

  fsqrt.s ft2, ft0

infinite_loop:
  j infinite_loop

.section ".fdata0","ax",@progbits
  .8byte 0xc5d584907716dd07

Got ft2=0x5b7c271f which corresponds to 7.09747e+16, instead of ft2=0x7fc00000=nan.
Tested with Ariane with cvfpu 0.7.0 (109f9e9ed3adff25464db3aa021cb88119b7bf53).

Thanks!
Flavien

Hi there!

I've detected a bug in CVFPU.

Brief bug description

A conversion from double to unsigned int fcvt.wu.d provides wrong results in some cases.
I discovered the bug through cva6.

Example instance 1

Here is an example RISC-V (rv64imfd) snippet:

  .section ".text.init","ax",@progbits
  .globl _start
  .align 2
_start:

  # Enable the FPU
  li t0, 0x2000
  csrs mstatus, t0
  csrw	fcsr,x0

  la t0, .fdata0
  fld ft0, (t0)

  fcvt.wu.d a0, ft0, rup

  li t0, 0x10
  sd a0, (t0)

  sw x0, 0(x0)

infinite_loop:
  j infinite_loop

.section ".fdata0","ax",@progbits
  .8byte 0x41dfffffffc00001 # 2.14748e+09

Expected and actual results

We expect a0=0xffffffff80000000. I verified this with Spike.
However, CVA6 gives a0=0x80000000.

Example instance 2

Here is an example RISC-V (rv64imfd) snippet:

  .section ".text.init","ax",@progbits
  .globl _start
  .align 2
_start:

  # Enable the FPU
  li t0, 0x2000
  csrs mstatus, t0
  csrw	fcsr,x0

  la t0, .fdata0
  fld ft0, (t0)

  fcvt.wu.d a0, ft0, rmm

  li t0, 0x10
  sd a0, (t0)

  sw x0, 0(x0)

infinite_loop:
  j infinite_loop

.section ".fdata0","ax",@progbits
  .8byte 0x41efffffffffffff # 4.29497e+09

Expected and actual results

We expect a0=0xffffffffffffffff. I verified this with Spike.
However, CVA6 gives a0=0.

Thanks!
Flavien

Hi,

the fpnew_opgroup_multifmt_slice uses the wrong FP width for the third operand.

AFAIK the third operand is only used by the ADDMUL opgroup, which expects that operands_i[0] and operands_i[1] have the FP format specified by src_fmt_i and operands_i[2] and the result have the FP format dst_fmt_i:

Accordingly, the fpnew_opgroup_multifmt_slice should use the width of FP format dst_fmt_i when assigning the individual elements of operands_i[2] to the lane instances. However, the width of src_fmt_i is used for all operands:

As a result, the third operand is incorrect for all lanes (except for the first lane), as shown in the following waveform. The first group of signals shows the src_fmt_i (which is FP16) and dst_fmt_i (which is FP32), as well as operands_i[0] (for reference) and operands_i[2] of the fpnew_opgroup_multifmt_slice. The elements of operands_i[0] which are 16 bits wide are correctly assigned to the individual fpnew_fma_multi instances (as seen in the signal groups below, which show the input operands of the first three instances). However, the elements of operands_i[2] which are 32 bits wide are not correctly assigned. The individual elements of these operands are surrounded by rectangles of different colors.

Looks like these new signals don't have a driver for all lane=0..3.

https://github.com/pulp-platform/fpnew/blob/827d1b4ec7f2ba40592c8c6502936860e58a27ca/src/fpnew_opgroup_multifmt_slice.sv#L71

Hi there!

I've detected a bug in CVA6, probably in CVFPU but I'm not certain. I initially posted the issue in the CVA6 repo before moving it here. I used the commit 17743bc7120f1eb24974e5d7eb7f519ef53c4bdc of CVA6.

Brief bug description

A conversion of nan from simple to double may set a lot of bits in the mantissa, unexpectedly, under specific microarchitectural conditions.

Example instance 1

In this instance, we convert the single-precision 0xffffffffff800000 using fcvt.d.s.
We expect to get 0xfff0000000000000 as a result, but under the circumstances induced in the very simple ELF, we get 0xffefffffffffffff. I confirmed the expected result with spike, and in the snippet further below in CVA6.

Here is the ELF and waveforms of the bug.
A symptom of the bug is the first write to address 0x18, which essentially writes the result of the conversion.

Here you can observe that the value dumped is erroneous.

Example instance 2

In this instance, we convert the single-precision 0xffffffff7f800000 using fcvt.d.s.
We expect to get 0x7ff0000000000000 as a result, but under the circumstances induced in the very simple ELF, we get 0x7fefffffffffffff. I confirmed the expected result with spike, and in the snippet further below in CVA6.

Here is the ELF and waveforms of the bug.
A symptom of the bug is the sixth write to address 0x18, which essentially writes the result of the conversion.

Example instance that runs correctly

Interestingly, performing the conversion out of context works, for example this snippet executes apparently correctly. It is similar if we replace the values with the values of the second instance.

  .section ".text.init","ax",@progbits
  .globl _start
  .align 2
_start:

  # Enable the FPU
  li t0, 0x2000
  csrs mstatus, t0
  csrw	fcsr,x0

  la t0, .fdata0
  fld fa5, (t0)

  fcvt.d.s ft0, fa5

  li t0, 0x18
  fsd ft0, (t0)

  sw x0, 0(x0)

infinite_loop:
  j infinite_loop

.section ".fdata0","ax",@progbits
  .8byte 0xffffffffff800000

Therefore I deduce that this is conditioned by some microarchitectural effects (maybe branch prediction but I am not certain).

Thanks!
Flavien

Hi everyone,

is there any C/C++ exmple available for float16alt (bfloat16) with compiler flag?

Thank you

In v0.7.0, converting the FP32 value -2147483648.0 to INT32 produces the result 0x80000000 and sets the NV status flag. However, the input value can be exactly represented as an INT32.

Test case:

  operands_i = '{0: 32'hcf000000, 1: 32'h00000000, 2: 32'h00000000};
  rnd_mode_i = RNE;
  op_i = F2I;
  op_mod_i = 1'b0;
  src_fmt_i = FP32;
  int_fmt_i = INT32;

Root cause:
These lines do not take account of the fact that for the valid input value, the exponent is exactly 31. If the sign is negative and the mantissa is 0x80000000 in this case, there should not be overflow.

I had run 4 instructions and all of them are from different operation blocks (ADDMUL, DIVSQRT, NONCOMP, and CONV). I know that the ADDMUL block uses three operands as input operands_i[2:0][31:0] and this input is set in little-endian format.
The problem I am getting is with simple FADD.S instruction, it should add operand_i[1][31:0] and operand_i[0][31:0] but it is adding operand_i[2][31:0] with operand_i[1][31:0].
Can someone elaborate this please, do I have to give rs1 and rs2 at locations [2] and [1], or is there any other way?

Hi,
Currently the only FP8 support is E5M2. How complicated would it be to add E3M4 and E2M5 support? Can I make a contribution to some organization to get these added? What would it take :-) ?

I'm simulating the FPU inside Vivado 2020.1. The testbench is this:

module tb_top;
  localparam fpnew_pkg::fpu_features_t Features = fpnew_pkg::RV32F;
  localparam fpnew_pkg::fpu_implementation_t Implementation = fpnew_pkg::DEFAULT_NOREGS;
  localparam int unsigned WIDTH = Features.Width;
  localparam int unsigned NUM_OPERANDS = 3;
  localparam type TagType = logic;

  /* input */logic                                                  clk_i = 0;
  /* input */logic                                                  rst_ni = 0;

  /* input */logic                    [NUM_OPERANDS-1:0][WIDTH-1:0] operands_i = 0;
  /* input */fpnew_pkg::roundmode_e                                rnd_mode_i;
  /* input */fpnew_pkg::operation_e                                op_i;
  /* input */logic                                                  op_mod_i;
  /* input */fpnew_pkg::fp_format_e                                src_fmt_i;
  /* input */fpnew_pkg::fp_format_e                                dst_fmt_i;
  /* input */fpnew_pkg::int_format_e                               int_fmt_i;
  /* input */logic                                                  vectorial_op_i = 0;
  /* input */TagType                                                tag_i;

  /* input */logic                                                  in_valid_i = 0;
  /* output */logic                                                  in_ready_o;
  /* input  */logic                                                  flush_i = 0;
  /* output */logic                    [       WIDTH-1:0]            result_o;

  /* output */fpnew_pkg::status_t                                   status_o;
  /* output */TagType                                    tag_o;
  /* output */logic                                                  out_valid_o;

  /* input */logic                                                  out_ready_i = 1;

  /* output */logic                                                  busy_o;


  fpnew_top DUT_i (.*);

  /* Clock Generation */
  always #5 clk_i = ~clk_i;

  initial begin
    rnd_mode_i = fpnew_pkg::RNE;
    op_mod_i = 0;
    op_i = fpnew_pkg::ADD;
    src_fmt_i = fpnew_pkg::FP32;
    dst_fmt_i = fpnew_pkg::FP32;
    int_fmt_i = fpnew_pkg::INT32;
    tag_i = 0;

    operands_i[0] = 'h3f800000;
    operands_i[1] = 'h3f800000;
    operands_i[2] = 'h3f800000;
    flush_i = 1;

    for (integer i = 0; i < 10; i++) begin
      @(posedge clk_i);
    end

    /* Deassert reset */
    rst_ni  = 1;
    flush_i = 0;
    @(posedge clk_i);
    @(posedge clk_i);
    @(posedge clk_i);
    @(posedge clk_i);
    in_valid_i = 1;
    @(posedge clk_i);
    @(posedge clk_i);
    in_valid_i = 0;
    for (integer i = 0; i < 10; i++) begin
      @(posedge clk_i);
    end
    $finish;
  end

endmodule

The result of the module is this one:

Which is a NaN. Can someone please walk me through the issue? Is this a Vivado thing?

@spidugu444 reported core-v-verif issue openhwgroup/cva6#1416

hello,
We were testing Floating point unit and we encounter one issue that during the operation of fadd and fsub instruction the underflow flag does not get high whereas in fmul,fmadd,fmsub,fnmadd and fnmsub the underflow flag gets high whenever the result is subnormal.

Can you explain what is the logic behind it.

Regards:
Hamza Shabbir

Hi,

I am running floating point example in /home/pbhatt82/core-v-verif/core-v-cores/cv32e40p/example_tb/core this directory, I am getting below error.

Path : /home/pbhatt82/core-v-verif/core-v-cores/cv32e40p/example_tb/core
Command : make calculator-fp-vsim-run-gui

Hi,

Is there any multi-cycle path in the design? Critical paths for some instructions are very long.

Thanks.

Hi there!

I've detected a bug in CVFPU.

Brief bug description

A conversion of +inf from double to simple sets a lot of bits in the mantissa, unexpectedly.
I have found it through cva6.

Example instance

Here is an example RISC-V (rv64imfd) snippet:

  .section ".text.init","ax",@progbits
  .globl _start
  .align 2
_start:

  # Enable the FPU
  li t0, 0x2000
  csrs mstatus, t0
  csrw	fcsr,x0

  la t0, .fdata0
  fld ft0, (t0)

  fcvt.s.d ft1, ft0, rdn

  li t0, 0x18
  fsd ft1, (t0)

  sw x0, 0(x0)

infinite_loop:
  j infinite_loop

.section ".fdata0","ax",@progbits
  .8byte 0x7ff0000000000000

Expected and actual results

We expect ft1= 0xffffffff7f800000.. I verified this with Spike.
However, CVA6 gives ft1= 0xffffffff7f7fffff..

Thanks!
Flavien

I am using this fpnew with these parameter, other parameters are default.

      .Features       ( fpnew_pkg::RV32F          ),
      .Implementation ( fpnew_pkg::DEFAULT_NOREGS )

I am facing a problem while handling out_valid_o and busy_o signals. I am making this combination assign fpu_busy_idu = fp_busy & (~out_valid_fpu2c); to stall the processor while the fpu is in working mode.

Problem;
When we have the FSQRT.S or FDIV.S instruction, the fpnew remain it busy busy signal high for more cycles although we get the correct result on first valid signal.

busy_o is fp_busy and out_valid_o is out_valid_fpu2c.

Hi pulp-team,
I am experiencing segmentation faults while using your fpu in Xilinx Vivado.
I created a very simple testbench, which drives the fpu input signals, under Vivado 2018.2 and instantiated the top module 'fpnew_top' in it.
After that, I properly configured the module in order to implement 32-bit fp operations.
The compilation hangs during the elaboration phase.
I attach my elaborate.log for your convenience.
elaborate.log

Kind regards,
Giovanni