8-bit ECUs for FIR filters

Post Reply
User avatar
tutatis7
Posts: 10
Joined: Mon May 18, 2020 1:20 am

Is it possible to use 8-bit ECUs modules for multiply-accumulate with 32-bit input data (for 2-channel audio FIR filter - oversampling)?
Robert
Posts: 29
Joined: Fri May 15, 2020 8:27 am

QuickLogic was the first FPGA company to add DSP into the FPGA with the EclipsePlus family. Unfortunately, these DSP’s are only 8-bits and they need to use FPGA routing to cascade together. I don’t believe that it would be very efficient to implement 32x32.

Another alternative is the EOS S3, which has ~900 Logic elements and two dedicated 32x32 Multipliers connected to the FPGA.
Page 62 and 63 of the datasheet at https://www.quicklogic.com/wp-content/u ... t-2020.pdf

Multiplier selection
Built-in signed multipliers are also available in the on-chip programmable logic. The multiplier relieves the use of logic to implement such functions. There are two instances embedded in the on-chip programmable logic. The multiplier can be configured as one 32x32 bit multiplier or two 16x16 bit multipliers. A block diagram of the multiplier is shown on page 63.

As this device also has Cortex M4-F and dual PDM or I2S MIC interface it might be a better choice.
The PDM / I2S is ideally suited for low power voice applications.
Is there a reason for looking at PolarPro or EclipsePlus?
bekeanloinse
Posts: 2
Joined: Mon Apr 08, 2024 4:34 am

The EOS S3 family, with its Cortex M4-F, dual PDM or I2S MIC interface, and dedicated multipliers, seems to offer advantages such as improved efficiency and suitability for low-power voice applications. The ability to configure the multipliers as one 32x32 bit multiplier or two 16x16 bit multipliers provides flexibility in design.
heardle
smithcohn12
Posts: 1
Joined: Fri Nov 21, 2025 9:35 am

Technically yes: you can split each 32 bit sample into four 8 bit limbs and perform multi precision multiply accumulate with wider accumulators and explicit carry and scaling, but it is complex, cycle heavy and riskier for overflow and precision so using native 32 bit DSP blocks or wider datapath (or parallelizing across multiple 8 bit engines) is usually the far cleaner and higher performance choice.
Post Reply