Graeme Smecher

@jnk0le - that is an excellent point. A synthetic c.mulh using Zcb instructions would be pretty short, and it looks like Zcb has all the right primitives already. Thank you...

On reflection, @jnk0le, I closed this issue too soon. Your comment is predicated on paired c.mul/c.mulh, which is true for wider multiplies. It's _not_ true for DSP algorithms (FFTs, FIRs,...

Thanks, @tovine: for DSP applications, ARM's CMSIS DSP library [0] seems like a good reference point. CMSIS is Apache licensed and should be directly portable to RISC-V (see e.g. [1])....

Here's an FFT, taken brutally and somewhat arbitrarily from [cmsis-dsp](https://github.com/ARM-software/CMSIS-DSP/blob/main/Source/TransformFunctions/arm_rfft_q31.c#L383). ``` #include typedef int32_t q31_t; typedef int64_t q63_t; #define multAcc_32x32_keep32_R(a, x, y) a = (q31_t) (((((q63_t) a) > 32) #define...

Just to be 100% clear: I think this idea is DOA for non-technical reasons (schedule, scope) and technical reasons outside the scope of all my analysis above (lack of available...

Thanks - this context is helpful, and I understand and agree with what you say. I will keep my eyes open for a justifiable benchmark that supports c.mulh.

Unfortunately (and not unpredictably), it looks like the use of VHDL-2008 specific constructs is a hassle here. GHDL can't "synthesize" (really, translate to Verilog) without modifications.

VHDL-2019 would be a step in the wrong direction - honestly, I think the easiest solution is a hand-translated Verilog implementation. (It's not that much code, after all.)

@mithro, I don't have the cycles right now to meet the upcoming GF180MCU MPW deadline. I am _very_ interested in getting Minimax fab'd when the time is right. I'll leave...

@dumblob - if you (or your colleagues) have spare cycles, I'd love some help with the ASIC flow. I haven't found any pre-built dual-ported RAM primitives. Looks like I can...