Support for floating point types

[vloncar]

Description

Current hls4ml supports only arbitrary precision integer and fixed-point types. This PR adds support for floating point types. Floating point types are defined in ap_float.h and ac_float.h of the respective libraries and cover two distinct cases: IEEE floating-point standard (basically C/C++ types) and general floating-point implementation (any combination of mantissa and exponent). AC types library is more broad and offers more flexibility than AP types one. The PR covers both by introducing FloatPrecisionType for the general case (covered by the ac_float) and StandardFloatPrecisionType (for ap_float<W,E> and ac_std_float<W,E>). In principle one could cram everything in a single type but that makes it complicated to track what is the actual intended use, especially because of the 1-bit difference between AC and AP types.

To use, user can specify float, double, half and bfloat16 as type and this will result in StandardFloatTypePrecision objects to be used and those C++ types used in the generated code. Note that half and bfloat16 aren't supported out of the box and require the user to tweak the code to make it compile, as it is dependent on the compiler how these are exposed. If the user specifies std_float<W,E> the ap_float<W,E> and ac_std_float<W,E> will be generated using the same object. Finally, for full control of AC type, user can use ac_float<W,I,E,Q> which will use the FloatPrecisionType class and emit the corresponding type in code.

The PR is somewhat incomplete as there are numerous nuances of full support of the general case and the half/bfloat16 but is a good starting point and is self-contained. The problem remains with AP types that don't have a public version of ap_float.h (we'll ask AMD about open-sourcing it), so if user uses a general floating-point type the local compilation with compile() won't work. In the future we can tackle the include issue (also for half and bfloat16 on host compilers), as well as look into optimizations of algorithms (for example, using the accumulator type for the CMVM). The intention right now is not to make this a first-class supported feature, rather an exotic option for users who know what they want and are aware of the caveats and rough edges, but more crucially it allows us to avoid silly test failures due to bitwidth issues. This could be advertised as an experimental feature, but I see we're completely lacking any documentation on type setting, so that may come as a separate PR.

Type of change

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

Tests

Tests for parsing the new types has been added to test_types.h.

Checklist

Yeah, yeah, I did all the things in the checklist.