Meet us at the RISC-V Summit in San Jose, CA, on December 13-14, 2022! 

What is an ASIP?

April 16, 2021

ASIP stands for “application-specific instruction-set processor” and simply means a processor which has been designed to be optimal for a particular application or domain.

General-purpose vs. domain-specific or application-specific processors

Most processor cores to date have been general-purpose, which means that they have been designed to handle a wide range of applications with good average performance. This may mean that if you have some special computationally intensive algorithm, such as audio processing, you may need a high-performance core (for example with a SIMD unit, or zero overhead loops) or a high clock frequency to achieve your needs. This may result in exceeding your silicon or power budget.

An alternative is to create an ASIP which has a specialized architecture, optimized to efficiently achieve the required performance for the audio processing. The ASIP would not usually be designed to optimally handle more generic operations such as those needed for an operating system. Instead, if an OS is needed, you would probably run it on a separate general-purpose core which would not be constrained by the need to run audio processing algorithms. Thus, the ASIP design is optimized for performance with just enough flexibility to meet its use case.

ASIPs have been the subject of research in universities around the world and have been applied to a number of domains such as audio signal processing, image sensors, and baseband signal processing. Codasip founder and President Karel Masařík with CTO Zdeněk Přikryl researched design automation for ASIPs at the TU Brno. To read more on their research, check the papers listed at the end of this article.

ASIPs to address semiconductor scaling issues

ASIPs or domain-specific processors are likely to be used more widely in the future due to semiconductor scaling issues. For decades, developers of SoCs have relied on Moore’s law and Dennard Scaling to get more and more performance and circuit density through successively finer silicon geometries.

While this scaling applied, it was generally reasonable to use general-purpose processor cores and to rely on new generations of silicon technology to deliver the performance required with an acceptable power consumption. However, this scaling has been known to have broken down, with smaller increments in performance improvement and leakage current worsening power consumption. Because of this, the semiconductor industry must change, and a new approach to processing is needed.

To date, this industry challenge has been tackled by incorporating different types of general-purpose cores on a single SoC. For example, mobile phone SoCs have combined application processors, GPUs, DSPs, and MCUs, but none of these classes of processor have application-specific instruction sets.

With new products demanding new algorithms for artificial intelligence, advanced graphics and advanced security, more specialized hardware accelerators are needed and are being developed. Such accelerators are designed to handle computationally demanding algorithms efficiently. Each accelerator will need an optimized instruction set and microarchitecture – in other words, an ASIP.

Domain-specific accelerators. Source Codasip.

ASIP and software development

Domain-specific processors (Application-specific processors, ASIP… you will notice we use these terms interchangeably) combine hardware specialization with flexibility through software programmability.

One challenge of creating custom hardware is ensuring the needs of software developers are met too. Techniques such as intrinsic instructions allow direct access to the instruction set from C, but reduce the flexibility of the code. They may still be a viable answer when complex functions are encapsulated in a single instruction.

But better still would be a top-down approach. Instead, a compiler created for your domain-specific accelerator, automatically targets the custom instructions you create. This, along with an instruction set simulator and profiler, accelerates the rate at which you can try different design iterations to converge on an optimal solution.

Codasip Studio provides a complete solution for this process with the ability to generate ISA and compiler from a simple instruction level model.

Design automation and verification of application-specific processors

With the need to develop many and varied accelerators, it is not efficient to develop the instruction sets and microarchitecture manually. Application software can be analyzed by profiling and the instruction set tuned to those needs. A processor design automation toolset like Codasip Studio can be then used to generate a software toolchain and an instruction set simulator.

Specifically, Codasip Studio automates the generation of a C/C++ compiler that is fully aware of the instruction set and can infer specific instructions automatically. It is important to have the C/C++ compiler in the loop, to see the impact of the application-specific instructions. The same applies for instruction set simulators, debuggers, profilers, and other tools in SDK that are automatically generated. Codasip Studio can be also used to generate hardware design including RTL, testbenches, and a UVM environment.

Did you know?

Codasip was originally founded to create co-design tools for ASIPs, hence the name “Co-dASIP”. Codasip Studio has subsequently been used for creating more general-purpose cores such as RISC-V embedded and application cores too.

Processor design does not end with generating the RTL code – the dominant part of the design cycle is verification and it needs to be rigorous. As Philippe Luc explained to Semiconductor Engineering, RTL verification is multi-layered and complex.

Codasip Studio can automate key parts of the verification process in order to help the full flow of ASIP design being quicker. Among other things, Codasip Studio provides automated coverage points for the optimised instructions. The provided UVM environment makes it easy to run programs (including the new instructions) on both model and RTL with result comparison. A constrained random program generator is provided to help closing coverage and ensure quicker verification for our customers.

To learn more about the power of Codasip Studio combined with RISC-V, read our white paper on “Creating Domain-Specific Processors with custom RISC-V ISA instructions”.

Codasip research papers on design automation for ASIP

  • MASAŘÍK Karel, UML in design of ASIP, IFAC Proceedings Volumes 39(17):209-214, September 2006.
  • ZACHARIÁŠOVÁ Marcela, PŘIKRYL Zdeněk, HRUŠKA Tomáš and KOTÁSEK Zdeněk. Automated Functional Verification of Application Specific Instruction-set Processors. IFIP Advances in Information and Communication Technology, vol. 4, no. 403, pp. 128-138. ISSN 1868-4238.
  • PŘIKRYL Zdeněk. Fast Simulation of Pipeline in ASIP simulators. In: 15th International Workshop on Microprocessor Test and Verification. Austin: IEEE Computer Society, 2014, pp. 1-6. ISBN 978-0-7695-4000-9.
  • HUSÁR Adam, PŘIKRYL Zdeněk, DOLÍHAL Luděk, MASAŘÍK Karel and HRUŠKA Tomáš. ASIP Design with Automatic C/C++ Compiler Generation. Haifa, 2013.
Roddy Urquhart

Roddy Urquhart

Related Posts

Check out the latest news, posts, papers, videos, and more!

Why Codasip Cares About Processor Verification – and Why you Should too

February 28, 2022
By Philippe Luc

Why and How to Customize a Processor

October 1, 2021
By Roddy Urquhart

What does RISC-V stand for?

March 17, 2021
By Roddy Urquhart

What is CodAL?

February 26, 2021

CodAL, standing for Codasip Architectural Language, is central to developing a processor core using Codasip Studio. The language has a C-like syntax and it merges good practices and code constructs from conventional programming languages and hardware description languages. It has been developed from the outset to describe all aspects of a processor including both the instruction set architecture (ISA) and microarchitecture.

Each processor description includes four elements in its description:

  1. Architectural resources, for example, registers and a program counter.
  2. Instruction set, that is, names of instructions, their operands and their binary form (opcodes).
  3. Semantics, or a description of the behaviour of each instruction and exception – how they affect the architectural resources.
  4. Implementation, which includes those resources and behaviour (especially timing) that are not visible in the architectural model but which define a particular micro-architectural implementation. Note that more than one micro-architectural implementation can be in a single CodAL description.

The architectural or instruction accurate (IA) model contains the instruction set, architectural resources, and the semantics. The micro-architectural or cycle accurate (CA) model contains the instruction set, architectural resources and the micro-architectural implementation.

CodAL description. Source Codasip.

CodAL description is object-oriented, meaning that an object can be instantiated into a more complex object, the complex object into an even more complex one, etc. CodAL allows information to be passed through the object hierarchy without having to use complex function calls.

The CodAL element is a common example of an object, and in the following example we show an element describing a multiply-accumulate instruction.

CodAL example. Source Codasip.

The use statement describes the resources that are used by the instruction – a destination register (dst) and two source registers (src1, src2). Next, the assembly statement describes the assembler mnemonic (mac) and its arguments. The binary statement describes the binary representation of the instruction and arguments. Finally, the semantics statement describes the multiply-accumulate operation.

The CodAL description is used by the Codasip Studio toolset to generate an SDK and an HDK. For example, the element description would be used when generating the instruction set simulator (ISS), assembler, disassembler, C/C++ compiler, and debugger for the processor core.

CodAL schema. Source Codasip.

The CA description would take advantage of the instruction set and resources descriptions used for the IA models. In addition, the CA description would specify microarchitectural features such as the pipeline length.

The cycle-accurate parts of the CodAL description would be used for generating the cycle-accurate simulator, RTL, testbench, and UVM environment. In this way CodAL is the single source for all aspects of the processor hardware and software. In contrast, some other processor development tools require two languages to describe the processor core. The methodology also enables powerful verification of generated RTL against a golden reference model in generated UVM environment.

Roddy Urquhart

Roddy Urquhart

Related Posts

Check out the latest news, posts, papers, videos, and more!

Processor design automation to drive innovation and foster differentiation

July 7, 2022
By Lauranne Choquin

Single unified toolchain empowering processor research

May 23, 2022
By Keith Graham

Design for differentiation: architecture licenses in RISC‑V

May 16, 2022
By Rupert Baines