Perhaps, it is important to understand the history of why fixed point is utilized. Historically, fixed point was the alternative for expensive floating point implementations/operations, or was the easy option on top of an integer-only MCU. In today's chips, however,  if floating point is available in a processing system, then floating point will be used over fixed point - sometimes because fixed point introduces a lot of signal processing challenges that are not present in floating point; perhaps because most, if not all, signal processing math is designed in, and for, floating point. Conversion to fixed point happens if no other choice is available or to support legacy code bases.

Consider:
1. For the vector extension, floating point is mandatory. This could lead to the utilization of fixed point math being low. In this case, it will likely involve conversion in and out of floating point before doing the actual math.

2. Fixed point may be used more frequently if there is a significant benefit over floating point:
- legacy code is less of an issue on our architecture because it's new;
- power/performance - but we're already paying the price for area with floating point!

For the current vector extension definition that would, maybe, be for the 1.7 FP or 8-bit fixed point, where there could be a performance benefit depending on the factual implementation of the vector engine for a given RISCV core.

With that said, we are not opposed to supporting fixed point. We are questioning having fixed point being mandatory. Fixed point support has a significant impact on compilers and tools (no native data type + no clear definition) and a significant impact on the usage/support model (fixed point ISA section is missing expected fixed point options).

Hence the suggestion for making it optional, and working through some of the use-cases for fixed point to ensure that the fixed point ISA definition is "usable" by the intended target audience/users.

Internally we've worked through a few simple examples, like IIR and FIR filters, and it quickly becomes apparent that when using 1.(SEW-1) [industry standard definition] as a fixed point definition it quickly because "unmanageable" in terms of managing decimal points, overflows and mixed precision. "Unmanageable" here should be read as: requires a lot of additional checks around all math operations to ensure we don’t overflow or mix decimal points.