Re: Fixed Point (Chapter 13): Clarification Request


perhaps i am not upto date on this topic.   but addresses are fixed point. (integers).   and you need vector support for vector loads using the vector accumulators.(indexs).   the math, other than overflow is essentially the same

i hope this makes sense

On Aug 10, 2020, at 10:52 AM, CDS <cohen.steed@...> wrote:

[Edited Message Follows]

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.

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.

WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.

Join { to automatically receive all group messages.