Floating Point Unit is instantiated in CORE-V-MCU

[MikeOpenHWGroup]

The CORE-V-MCU instantiates the "fpnew" floating point IP from the pulp-platform team. As discussed in #189, the CV32E40P does not make use of this floating point unit, so it really should not be there.

Note: I have labelled this as a bug for two reasons:

1. Instantiating fpnew and connecting it to the core via the APU bus may cause unintended behaviour. This has not been tested for.
2. Physical Implementation: even if the instantiating and connecting fpnew does not cause a functional bug, it is not good practise to include a lot of unused logic.

[MikeOpenHWGroup]

Fixed in #191

[gmartin102]

closed -- FPU is removed from cv32e40p instantiation

[MikeOpenHWGroup]

FPU is removed from cv32e40p instantiation

As of 53a5d08, the FPU is still there.

The parameter is not set to 0, so the CV32E40P will no longer decode F or D instructions to be forwarded to the APU. This is good. However the floating point IP is still instantiated in the MCU and is still connected to the CV32E40P core via the APU interface.

Is that what we want?

[gmartin102]

instatiation of cv32e40 indicates USE_FPU=0 cv32e40p_core #( .FPU(0), .NUM_MHPMCOUNTERS(1), .PULP_CLUSTER(0), .PULP_XPULP(0), .PULP_ZFINX(0) ) lFC_CORE ( I don't understand your comment

[MikeOpenHWGroup]

Yes, you are right that the instantiation of cv32e40 indicates USE_FPU=0. This means that the core will now flag floating point instructions as illegal instructions.

However, the FPU IP is still instantiated and connected to the core in the fc_subsystem. The core can no longer use it, but the floating point unit instance still exists in the RTL model and will still be synthesized into gates.