In absolute terms, ASIPs are not that different from hardware accelerators. They both are dedicated, purpose made architectures with the same performance Vs area performance goal. The main difference could be that accelerators are typically not programmable at all but rather “parameterizable” usually through a number of registers. For instance, a speech recognition accelerator could be set to accept various speech coding binary rates. A video decoder could be parameterized to output various frame rates. This accounts more for flexibility, rather than programmability. In other words, accelerators are fixed function.
On the other hand, ASIPs are programmable. They have an instruction set and a program memory, so one can change their instruction stream to carry out different tasks – provided the ASIP architecture is suited enough for them. A video decoder ASIP can therefore be programmed to support H264 standard, or VC1 standard. They both are close in terms of behavior, so the ASIP can support them both, but it is different enough that tuning some parameters would not be sufficient.
At this point, it is important to distinct two types of ASIP. The first ASIP type has an instruction set which is semantically relatively close to the tasks it performs. In this category, instructions are few, and rather high level. For instance, a network packet inspection ASIP instruction could be “Get Packet”, “Extract header”, “Replace header”. Of course, though programmable, their flexibility is still somewhat limited and they cannot be reprogrammed for too different applications.
The second type, which will be our focus from now, are a lot more programmable. In fact, they are C programmable ASIPs. This means that a C compiler and a simulator exist to re-program them. Before we look closer at what design issues this leads to, let us highlight the advantages of such ASIPs:
- First, they are still ASIPs, which means they have a good area/ power / performance ratio
- They can be programmed in C so it is a lot easier to have algorithm people program them, and this task is not longer only within reach of the ASIP architect or designers
- From a system perspective, a C programmable ASIP is more independent from a host or another control processor. Between consecutive compute-intensive tasks, digital processing algorithms often run some control code (if-the-else statements, bit reading/writing, etc…). C programmable ASIPs can perform simple control code (those algorithms decisions that need to be made but do not involve massive processing)
- Minor design or silicon bugs can be more easily hidden or worked around. Indeed, it is usually enough to program a slightly different instruction sequence to work around minor behavioral bugs. This would certainly not feasible with a fixed-function or high-level instruction set ASIP
- Firmware may be deployed later to support new functions, or fix software bugs, even once deployed in the field
The table below summarizes similarities and differences between traditional accelerators, high-level instruction set ASIPs, and C programmable ASIPs.