17³Ô¹Ï

ASIP Designer W-2024.12 includes a new example processor model which demonstrates that fixed-function hardware efficiency and software programmability are not contradicting goals. The example implements a programmable accelerator for low-density parity check (LDPC) decoding in wireless communications, an application with daunting computational requirements.

Fixed-function RTL versus High-Level Synthesis versus ASIP

For computationally intensive applications with high requirements to throughput, area, and power, and where the flexibility of a software programmable solution is not necessarily required, design teams traditionally chose to implement a fixed-function RTL solution to avoid the suspected overhead of a programmable architecture in terms of its program memory, the instruction fetching and decoder logic, but also due to the effort to design the required software tools such as a compiler.

However, a pure fixed-function approach with RTL design entry has the disadvantage that changes to the specification or requirements, or just multiple design iterations to explore different architectural options, can be implemented only with significant design effort. As a result, design changes, particularly late changes, are expensive, as they require time and RTL design expertise. After tape-out, changes or bug fixes require a complete re-spin of the chip manufacturing process.

High-Level Synthesis (HLS) provides some remedy to this problem. The design entry is typically algorithm code written in C++, and along with user-specified constraints to timing and/or power, an HLS tool automatically generates an RTL implementation. The quality of results in terms of power, performance and area, particularly the efficiency of resource sharing, depends on the tool. The user has some control by adapting the C++ algorithm code and the constraints for a new iteration.

This approach allows some flexibility at design time, as the input C++ code can be modified and the design flow can be iterated multiple times, before the chip gets taped out. But in the same way as an RTL-entry approach, changes and fixes after tape-out imply the large costs associated with a silicon redesign.

An ASIP (Application-Specific Instruction-Set Processor) is a programmable architecture that is optimized for a particular application or class of applications. The hardware is tailored to achieve a certain throughput and/or power consumption as required by the applications. The architecture is programmable, that is, the application is written in a high-level programming language such as C or C++. Changes to the specification or bug fixes, no matter how late and even post-production, can be applied in the software and do not need to result in a redesign of the chip. In the worst case, a big change to the application code may result in a non-optimal cycle count on current ASIP architecture, but it will still run correctly.

The challenges typically associated with designing an ASIP are the fear of hardware overhead that is inferred to make the architecture programmable, and the expertise required to design software tools for the architecture, such as an optimizing compiler.

ASIP Designer addresses these challenges. While production-quality RTL code and software tools, including an optimizing compiler, are automatically generated from the tool, the designer has full control of the PPA quality of results through the modeling of the processor architecture. All hardware resources are explicitly defined in the processor model, and ASIP Designer¡¯s optimizing compiler takes care that they are used in the most efficient way.

The following LDPC case study demonstrates that a programmable architecture designed with ASIP Designer can indeed meet daunting throughput requirements with very little area penalty incurred from adding programmability.