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

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


February 28, 2022

Finding a hardware bug in silicon has consequences. The severity of these consequences for the end user can depend on the use case. For the product manufacturer, fixing a bug once a design is in mass-production can incur a significant cost. Investing in processor verification is therefore fundamental to ensure quality. This is something we care passionately about at Codasip, here is why you should too.

Luckily for the semiconductor industry, there are statistically more bugs in software than in hardware, and in processors in particular. However, software can easily be upgraded over the air, directly in the end-products used by consumers. With hardware, on the other hand, this is not as straightforward  and a hardware issue can have severe consequences. The quality of our deliverables, which will end up in real silicon, seriously matters.

Processors all have different quality requirements

Processors are ubiquitous. They control the flash memory in your laptop, the braking system of your car or the chip on your credit card. These CPUs have different performance requirements but also different security and safety requirements. In other words, different quality requirements.

Is it a major issue if the Wi-Fi chip in your laptop is missing a few frames? The Wi-Fi protocol retransmits the packet and it goes largely unnoticed. If your laptop’s SSD controller drops a few packets and corrupts the document you have been working on all day It will be a serious disruption to your work, there may be some shouting, but you will recover. It’s a bug that you might be able to accept.

Other hardware failures have much more severe consequences: What if your car’s braking system fails because of a hardware issue? Or the fly-by-wire communication in a plane fails? Or what if a satellite falls to earth because its orbit control fails? Some bugs and hardware failures are simply not acceptable.

Processor quality and therefore its reliability is the main concern of processor verification teams. And processor verification is a subtle art.

The subtle art of processor verification

Processor verification requires strategy, diligence and completeness.

Verifying a processor means taking uncertainty into account. What software will run on the end product? What will be the use cases? What asynchronous events could occur? These unknowns mean significantly opening the verification scope. However, it is impossible to cover the entire processor state space, and it is not something to aim for.

Processor quality must be ensured while making the best use of time and resources. At the end of the day, the ROI must be positive. Nobody wants to find costly bugs after the product release, and nobody wants to delay a project because of an inefficient verification strategy. Doing smart processor verification means finding relevant bugs efficiently and as early as possible in the product development.

In other words, processor verification must:

  • Be done during processor development, in collaboration with design teams. Verifying a processor design once it is finalized is not enough. Verification must drive the design, to some extent.
  • Be a combination of all industry standard techniques. There are different types of bugs of different levels of complexity that you might find using random testing, code coverage, formal proofs, power-aware simulation, etc. Using multiple techniques allows you to maximize the potential of each of them (what we could also call the Swiss cheese model) and efficiently cover as many corner cases as possible.
  • It is an ongoing science. What works is a combination of techniques that evolve as processors become more complex. We develop different approaches as we learn from previous bugs and designs to refine our verification methodology and offer best-in-class quality IP.

Processor quality is fundamental. The art of verifying a processor is a subtle one that is evolving as the industry is changing and new requirements arise. At Codasip, we put in place verification methodologies that allow us to deliver high-quality RISC-V customizable processors. With Codasip Studio and associated tools, we provide our customers with the best technology that helps them follow up and verify their specific processor customization.

Philippe Luc

Philippe Luc

Related Posts

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

Building a Swiss cheese model approach for processor verification

April 29, 2022
By Philippe Luc

Measuring the complexity of processor bugs to improve testbench quality

April 4, 2022
By Philippe Luc

Improve Your Verification Methodology: Hunt Bugs Flying in Squadrons

March 14, 2022
By Philippe Luc

Why and How to Customize a Processor


October 1, 2021

Processor customization is one approach to optimizing a processor IP core to handle a specific workload. The idea is to take an existing core that could partially meet your requirements and use it as a starting point for your optimized processor. Now, why and how to customize a processor?

Why you should consider creating a custom core?

Before we start, let’s make sure we are all on the same page. Processor configuration and processor customization are two different things. Configuring a processor means setting the options made available by your IP vendor (cache size, MMU support, etc.). Customizing a processor means adding or changing something that requires more invasive changes such as changing the ISA, writing new instructions. In this blog post we focus on processor customization.

Customizing an existing processor is particularly relevant when you create a product that must be performant, area efficient, and energy efficient at the same time. Whether you are designing a processor for an autonomous vehicle that requires both vector instructions and low-power features, or a processor for computational storage with real-time requirements and power and area constraints, you need an optimized and specialized core.

Processor customization allows you to bring in a single processor IP all the architecture extensions you need, standard or custom, that would have been available in either multiple IPs on the SoC or in one big, energy intensive IP. Optimizing an existing processor for your unique needs has significant advantages:

  • It allows you to save area and optimize power and performance as it targets exactly what you need.
  • It is ready to use. The processor design has already been verified – you only have to verify your custom extensions.
  • You design for differentiation. Owning the changes, you create a unique product.

Now, one may think that this is not so easy. How reliable is the verification of a custom processor? Differentiation is becoming more difficult, time consuming, and sometimes more expensive. The success of processor customization relies on two things:

  • An open-source ISA such as RISC-V.
  • Design and verification automation.

Custom processor, ASIP, Domain-Specific Accelerator, Hardware Accelerator, Application-Specific processor… are all terms related to processor customization.

Customizing a RISC-V processor

Remember: the RISC-V Instruction Set Architecture (ISA) was created with customization in mind. If you want to create a custom processor, starting from an existing RISC-V processor is ideal.

You can add optional standard extensions and non-standard custom extensions on top of the base instruction set to tailor your processor for a given application.

RISC-V Modular Instruction Set. Source: Codasip.

For a robust customization process that ensures quality in the design and confidence in the verification, automation is key.
With Codasip you can license RISC-V processors:

  • In the usual way (RTL, testbench, SDK).
  • In the CodAL source code.

CodAL is used to design Codasip RISC-V processors and generate the SDK and HDK. You can then edit the CodAL source code to create your own custom extensions and modify other architectural features as needed.

Microsemi opted for this approach as they wanted to replace a proprietary embedded core with a RISC-V one. Check this great processor customization use case with Codasip IP and technology!

Processor design automation with Codasip Studio

The legacy approach to adding new instructions to a core is based on manual editing. Adding custom instructions must be reflected in the following areas:

  • Software toolchain.
  • Instruction set simulator.
  • Verification environment.
  • RTL.
Design Automation without Codasip Studio. Source: Codasip.

With the software toolchain, intrinsics can be created so that the new instructions are used by the compiler, but this also means that the application code needs updating. However, modifying the existing ISS and RTL are both potential sources of errors. Lastly, if the verification environment needs changing, this is a further area for problems. Verifying these manual changes is a big challenge and adds risk to the design project.

Some vendors offer partially automated solutions, but by not covering all aspects of processor customization they still leave room for error due to the manual changes.

Design Automation with Codasip Studio. Source: Codasip.

In contrast, with Codasip the changes are only made to the CodAL source code. The LLVM toolchain is automatically generated with support for the new instructions. Similarly, the ISS and RTL are generated to include the custom instructions and can be checked using the updated UVM environment. This approach not only saves time, but is a more robust customization process.

Create an application-specific processor with RISC-V and Codasip

As differentiation is becoming more difficult, time consuming and sometimes more expensive with traditional processor design, customizing a processor so that it will meet your unique requirements is the key. Creating an application-specific processor efficiently, without compromising PPA, requires an open-source architecture and tools to automate the design and verification process. Find out more in our white paper on “Creating Domain-Specific Processors using custom RISC-V ISA instructions”.

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

Design for differentiation: architecture licenses in RISC‑V

May 16, 2022
By Rupert Baines

Building the highway to automotive innovation

May 5, 2022
By Jamie Broome

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