Automatic type inference for param_t in Parametrised Activations

[nghielme]

This small PR implement the inference of W and I parameter for a given floating point constant. It is exploited in parametrised activations

Type of change

• New feature (non-breaking change which adds functionality)

Tests

I run some tests related to Parametrised Activations, already present in the pytests of hls4ml.

Checklist

• I have read the guidelines for contributing.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have installed and run pre-commit on the files I edited or added.
• I have added tests that prove my fix is effective or that my feature works.

[nghielme]

I see some tests related to oneAPI fails; it's hard to me to understand why they fail, how should I proceed?

[jmitrevs]

If you have a linux setup it should be pretty straightforward to install oneAPI, and then you can run the pytest. But we can wait to look at the other issues first. Maybe it will clear itself.

[jmitrevs]

Struct is much too low level for what we are doing here. We have a python float. We should use it, not look at the bits.

[jmitrevs]

Use calculations: based on the value, you can easily determine how many bits you need. Going to structs is hard to follow.

[jmitrevs]

Note the utility we have in hls4ml already:
https://github.com/fastmachinelearning/hls4ml/blob/main/hls4ml/utils/fixed_point_utils.py#L139-L141

[JanFSchulte]

I wanted to try to install oneAPI myself, so I played with this PR a bit. The issue seems to be that the precision for the parameter of the leaky ReLU is reduced significantly, from typedef ac_fixed<16,6,true> quantizer_param_t; to a one-bit typedef ac_fixed<1,0,false> quantizer_param_t;. Vivado and the other backends seem to be able to handle it, but I'm not sure it makes sense in this case because we have negative slopes here and need it to be signed. The other backends seem to be able to deal with it. But for oneAPI, a signed variable is enforced to have at least two bits:

signed _BitInt must have a bit size of at least 2

So we need to make sure to take this into account when inferring the precision for the parameters.