DSP to ASIC conversion refers to the process of moving from a software based design utilizing a DSP processor to a dedicated ASIC which increases performance by several orders of magnitude.

Comparison of ASIC DSP versus SW DSP:

Pros:

1)    Reach performance that is either impossible with a DSP processor or that would require an array of DSP processors with a single efficient chip.

• Performance improvement over a DSP processor is typically between "x3" to "x100" depending on the specific application.

• Performance is gained by paralleling the algorithm (e.g. loop unrolling) thus increasing the number of MAC operations per cycle

2)    Reduce system power consumption.

• Less activity on external IO's since no program memory is needed.

• The dedicated ASIC can run at 10%-50% the DSP processor clock rate (and still be a lot faster.)

3)    Performance is typically scalable.

• Replicating the algorithm to handle n data streams instead of adding extra processors, and more memory in the typical.

4)    IP security is inherent.

• There is no external program memory which can be copied or buses that can be monitored using a logic analyzer. Copying an ASIC is practically impossible.

5)    Combine the DSP algorithm with all the external logic that typically requires extra chips (e.g. FPGA).

• This is almost a trivial part for the DSP ASIC. In contrast, using a DSP processor may require implementing external glue logic.

• Complex IP's can be used in the DSP ASIC, such as Ethernet MAC, high speed USB, PCIe etc.

Cons:

1)    For next generation products relying on legacy technology, the move requires some engineering effort in order to "port" the legacy design.

• In contrast to the FPGA conversion flow, here the algorithm needs to be paralleled for the performance improvement to take place.

• Development cycle involves FGPA synthesis (for prototyping) which is typically longer than compiling & flashing a DSP processor.

2)    Final product is less flexible.

• An ASIC only has the amount of flexibility that was introduced during its architectural design. A SW DSP may be changed by updating the flash contents.

Comparison of ASIC DSP conversion versus traditional hand coded ASIC:

Pros:

1)    Rapid Prototyping. Faster by a factor of 3 at least.

• Algorithm RTL (in Verilog or VHDL) is automatically generated from ANSI C compliant code using Impulse CoDeveloper tool chain.

• Wrappers for connecting algorithm with common interfaces are provided.

• Custom wrappers & interfaces may be provided also.

2)    Risk is considerably reduced.

• Algorithm is verified in both a SW test bench and on an FPGA prototype.

• After the product is finalized, the KaiSemi FPGA to ASIC flow is utilized and a drop-in replacement ASIC chip is available shortly. In contrast, a typical RTL ASIC flow is very complicated and hazard prone.

3)    Ability to test various algorithms before committing is much simpler.

• Since the algorithm is written in ANSI C complaint code, it is fairly easy to change and retest. Efficient hand coding is usually not very  tolerant to changes, and every small change might require a re-design.

4)    Time from prototype to chip in hand is reduced significantly using the streamlined KaiSemi proprietary FPGA to ASIC conversion flow.

• KaiSemi leverages its unique capability to quickly provide an ASIC, which is functionally equivalent to an FGPA. For more details on this, see FGPA to ASIC conversion.

Cons:

1)    Hand coded ASIC might be slightly more efficient. Typically by 5%-20%.

DSP to ASIC conversion flow:

The conversion flow consists of an FPGA prototype, which implements the algorithm required on a development board, and then converting it to an ASIC.

The process of getting to an FPGA prototype is typically comprised of:

•    Analyzing the algorithm and finding which points could benefit most from parallelization.

•    Writing the algorithm in ANSI C, using Impulse CoDesigner tool libraries.

•    Testing the algorithm correctness in SW.

•    Compiling the algorithm to HW RTL.

•    Optionally, compiling the SW test bench to HW RTL and run it through an RTL simulator.

•    Using selected wrappers to connect physical interfaces to HW algorithm.

•    Synthesizing and testing the algorithm in FPGA.