bsg-external / hardfloat Goto Github PK

Hi there!

I created some FuseSoC cores for this project in a new repo. The goal is to improve dependency management (for the moment it relies on git submodules).
Do you want to integrate them into this repo or should we keep them separate?
If you want to integrate them to this repo, for the future it may be favorable to move from Makefiles to FuseSoC for the testing process as well.

Thanks!
Flavien

ZynqParrot was complaining about this with Vivado 2022.1

The divSqrtRecFN_small.v module is the only sequential logic in HardFloat. It uses async reset, which goes against bsg guidelines. It may make sense to convert this to sync to fit guidelines. Otherwise, we'll need to check for implications on our CAD flow.

always @(negedge nReset, posedge clock) begin
        if (!nReset) begin
            cycleNum <= 0;
        end else begin
            if (!idle || inValid) begin
                cycleNum <=
                      (entering && !normalCase_S ? 1 : 0)
                    | (entering_normalCase
                           ? (sqrtOp ? (sExpA_S[0] ? sigWidth : sigWidth + 1)
                                  : sigWidth + 2)
                           : 0)
                    | (!idle && !skipCycle2 ? cycleNum - 1 : 0)
                    | (!idle &&  skipCycle2 ? 1            : 0);
            end
        end

PR #9 replaced the hardfloat module countLeadingZeros with bsg_counting_leading_zeros but the behaviour of these two modules different when the input to the module is 0. For countLeadingZeros, an input of 0 outputs the total number of zeros (ie. the input width). The bsg_counting_leading_zeros module is using a bsg_priority_encode which is defined to the output 0 when the input data is 0.

Have we double checked the logic around the clz replacements to ensure that this mismatch in behavior is never a problem?

We should add a testfloat harness for a post-synth netlist of Hardfloat. We've run into several post-synth issues in the wild, so this is a valuable endeavour

Useful for recoded implementations which support multiple data sizes.

As seen here:
https://github.com/ucb-bar/berkeley-hardfloat/blob/master/src/main/scala/resizeRawFloat.scala

The sp2dp case is easy -- the dp2sp case is trickier.