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

Design for differentiation: architecture licenses in RISC‑V


May 16, 2022

I was discussing with a colleague about the concept of architecture license in RISC-V. I realized that, in the open-source world, it can be a little tricky to grasp.

In a traditional processor IP model, there is a clear distinction between an off-the-shelf IP license that gives some level of configuration but no customization, and a fairly expensive architecture license enabling a licensee to use the instruction set with their own custom microarchitecture.

With RISC-V, the complication comes from the fact that it is often described as “an open-source architecture”, so people believe that some source code is licensed. But actually that is not the case at all.

Traditional IP and architecture licensing

In a traditional model, things are quite straight forward. A standard license for Arm or MIPS lets the customer use an RTL design but not change it at all (aside from a few configuration options perhaps).

Meanwhile, for customers willing to spend a lot of money, an architecture license gives them the right to modify how a processor executes instructions (the issue width, the cache size, etc.). However, it does not generally give the right to modify the instructions (with some exceptions such as the Cortex-M33 that supports Arm Custom Instructions, allowing the implementation of bespoke data processing operations, or Cadence Tensilica).

RISC-V based IP and architecture licensing

In an open-source model such as RISC-V, things are somewhat different

The RISC-V architecture is usually described as “open-source”, which implies everyone can use it at no cost.

However, a better description of RISC-V is that it is an “open architecture” or “open standard”. In that sense RISC-V is like C, Wi-Fi or LTE with RISC-V International performing the role of (respectively) ANSI, IEEE 802.11 and 3GPP in defining and managing standards that people are free to implement as they choose. But that is a written standard – not an implementation or a microarchitecture.

Just as is the case with those other open standards,  RISC-V licenses can either be open-source or commercial.

You can download open-source designs and have complete freedom to modify them however you wish. Boom, PULP, SweRV and other open-source designs give absolute freedom. But that comes with a cost: they are not supported, the verification is often troublesome, and they may not be of sufficient quality to use in a commercial design. Some companies do use them accepting those compromises; others are understandably wary.

Or you can buy a commercial RISC-V design. There are many companies offering high quality cores delivered as RTL with warranty and full product support. These can be an excellent solution for many customers. Then we are back to something similar to the traditional model: a sort of black box design – although based on an open-standard ISA – in that it cannot be modified or customized to address specific needs. But for many purposes that generic product will be a good fit.

Codasip, as a RISC-V core vendor, does a lot of business on this basis: customers buy a standard RISC-V processor core delivered as RTL and SDK, with high performance, “best-in-class” verification and full support. That is without any architecture license fees, to use it as it is, off the shelf.

ISA customization enables Design for Differentiation

But Codasip offers another option. This is an architecture license – and more – delivered as a source code in the CodAL processor description language.

Many of our customers buy a standard Codasip processor IP product delivered as CodAL source and then use Codasip Studio™  which enables them to modify it freely. We provide the flexibility to modify both the microarchitecture and the ISA, precisely what one needs to Design for Differentiation. Customization at ISA level brings higher performance and optimization. What is more, the power and elegance of the Codasip Studio toolset makes this very easy.

This is different to, for example, an Arm architecture license in three ways:

Freedom

Arm, even with an architecture license, constrains what you are allowed to do. Codasip does not: it is your core and you have control.

Tooling

Arm cores are developed internally, in traditional ways and not designed to be easy to modify. In contrast, all of Codasip’s cores are developed using Studio and are designed expressly to make customization (both ISA and microarchitecture) straightforward and efficient. That includes automatically creating the software toolchain (customized compiler etc) and verification.

Cost

Traditionally the limitation of architecture licenses has been both the cash cost of the license and the engineering resources (cost) required to take advantage of it. Codasip and Studio now make that far easier and hence more affordable with a complete end-to-end architecture customization solution. This dramatically changes the cost equation both of the architecture license fee and the engineering resources required.

RISC-V offers the promise of openness: Codasip and Studio make that promise a reality

Codasip offers the best of both worlds: a portfolio of high-quality standard cores that are a good fit for standard applications, with full verification and support. Or you can upgrade to a cost-effective architecture license, freely customize the core in an easy-to-use environment and have a unique product for your unique needs.

Rupert Baines

Rupert Baines

Related Posts

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

How to reduce the risk when making the shift to RISC-V

November 17, 2022
By Lauranne Choquin

DAC 2022 – Is it too risky not to adopt RISC-V?

July 18, 2022
By Brett Cline

Processor design automation to drive innovation and foster differentiation

July 7, 2022
By Lauranne Choquin

Closing the Gap in SoC Open Standards with RISC-V


March 24, 2022

The semiconductor industry has changed hugely in the last 3 or 4 decades. Around 1980 some larger semiconductor companies were strongly vertically integrated, not only designed and manufactured their products, but even made their own processing equipment and in-house EDA tools. Today almost every semiconductor company uses 3rd party equipment for IC manufacturing and designs using 3rd party EDA tools and 3rd party IP. A key reason why the disaggregation of the semiconductor industry has happened is the use of open standards.

There is no universally agreed definition of an open standard but it is generally agreed that they are available on a reasonable and non-discriminatory basis. In many cases, especially in SoC design, such standards are available on a royalty-free basis. Many open standards are owned by independent bodies such as the IEEE, OSI and IETF (internet engineering task force) rather than by companies. In such cases the further development of the standard is through an open process with widely-based participation.

Open Standards and SoC Design

It is worth looking at open standards for SoCs from both hardware and software angles. For embedded software, C and C++ have been well-established as open standards. Middleware and real-time operating systems (RTOS) have therefore frequently been supplied as source code using one of these languages. Some porting may be necessary where there are processor- or peripheral-dependencies but generally design teams can tackle this.

In many current devices, especially in IoT, an SoC has either wired or wireless communications. Such links require communication protocols based on open standards such as Ethernet or Bluetooth LE. Such networked devices are also likely to require some sort of security and again open standards enable secure communications.

In digital hardware design, the microarchitecture is described in a hardware description language. Both Verilog and VHDL are IEEE open standards and the RTL description will be synthesized to the gate level. Processors and peripherals are frequently connected by AMBA buses which are a set of standards owned by Arm but available royalty free.

Verification will frequently be done using UVM (Universal Verification Methodology) which again is an open standard managed by the Accellera industry organisation. Power intent can be expressed in UPF (Unified Power Format) – another Accellera standard.

Finally, at the physical design level layout is required for silicon manufacturing. For decades GDSII, originally developed at Calma, has been used as the main interchange format. More recently, OASIS (Open Artwork System Interchange Standard) has been used as an open standard for layout.

The benefits of open standards

Open standards have provided many benefits to industry. Firstly, they have provided interoperability between chips, between software packages and between design tools. This has enabled disaggregation.

Secondly, if there are open standards there is an opportunity for an ecosystem of products and vendors to develop. For example, with C there are a host of software development tools available as well as middleware and RTOS products for embedded software reuse. At the hardware level there is a wide range of EDA tools that use open standards such as Verilog, UVM and OASIS. This means that development teams have a wide choice of vendors and do not need to depend on a single vendor.

Thirdly, an open standard means that one level of specification is already accomplished allowing product companies to focus on differentiation through their implementation.

However, the ‘elephant in the room’ is that there has been an obvious gap in the open standards. The ISA represents the all-important interface between hardware and software, but this has historically been almost exclusively the preserve of proprietary ISAs.

Closing the gap in open standards with RISC-V

With RISC-V there is for the first time a truly open standard for an ISA with real industry support. The ISA combines a very lightweight base integer instruction set with the flexibility of standard and custom extensions. The RISC-V ISA does not specify a microarchitecture so, for example, Codasip has developed RISC-V processor cores with three-, five-  and seven-stage pipelines thus allowing designers to match a core to their needs. IP vendors differentiate with microarchitecture.

An immediate benefit for embedded software suppliers and for SoC developers is that it is attractive to offer middleware as binaries (as well as just source code). This alone should help RISC-V adoption to accelerate by simplifying work for embedded software developers.

Using an open ISA is a catalyst for a rapidly expanding ecosystem embracing processor IP vendors, software development tool providers, software companies and semiconductor companies. Just as in networking, token ring proprietary products were squeezed out by the growing ecosystem of Ethernet around 1990, we can expect proprietary ISAs to be squeezed out by RISC-V in the coming decade.

Lastly for companies developing their own processor cores, the base instruction set is available royalty free. The modularity and extendibility of the RISC-V ISA means that basic instructions are already defined, and the developers can focus on the specific value add of their core or accelerator.

Adopting RISC-V is now a low-risk choice for embedded SoC developers. The crucial gap in SoC open standards has been closed to the benefit of both hardware and software developers.

Roddy Urquhart

Roddy Urquhart

Related Posts

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

How to reduce the risk when making the shift to RISC-V

November 17, 2022
By Lauranne Choquin

DAC 2022 – Is it too risky not to adopt RISC-V?

July 18, 2022
By Brett Cline

Processor design automation to drive innovation and foster differentiation

July 7, 2022
By Lauranne Choquin

What is the difference between processor configuration and customization?


August 12, 2021

For many years, people have been talking about configuring processor IP cores, but especially with growing interest in the open RISC-V ISA, there is much more talk about customization. So, processor configuration vs. customization: what is the difference?

CPU configuration is like ordering a pizza from the pizzeria

A simple analogy is to think of ordering a pizza. With most pizzerias, you have standard bases and a choice of toppings from a limited list. You can configure the pizza to the sort of taste you would like based on the standard set of options available.

Processor IP vendors have typically offered some standard options to their customers, such as optional caches, tightly coupled memories, and on-chip debug, so that they could combine them and provide the customers with suitable configurations for their needs. While doing so, the core itself remains the same, or has very limited variations. Certainly, the instruction set, register set, and pipeline would remain the same, and only optional blocks such as caches are allowed to vary.

CPU customization is like having a chef making a special pizza for you

Today, many users are demanding greater specialization and variability in their processor cores. This may be to achieve enhanced performance while keeping down silicon area and power consumption. There may be a number of ways in which this can be achieved, for example, by creating custom instructions optimized to the target application, adding extra ports and registers. Such changes fundamentally alter the processor core itself.

Returning to the pizza analogy, customization is like if a private chef has an underlying pizza base recipe but is willing not only to let you provide alternative toppings, but to modify the pizza base, with alternatives to the standard flour, oil, and yeast ingredients used. This is quite a good reason why you would want to customize a processor, isn’t it!

And this is exactly what RISC-V allows you to do. You can customize an existing RISC-V processor to meet your specific requirements by adding optional standard extensions and non-standard custom extensions.

Create a custom core with RISC-V and Codasip

Although some proprietary IP suppliers allow their cores to be extended, the greatest customization opportunity lies with RISC-V. The ISA was conceived from the outset to support custom instructions.Codasip RISC-V processorsCodasip RISC-V Processors were developed using the CodAL architecture description language and are readily customized using Codasip Studio.Codasip StudioFor more information on how custom instructions can be used to create domain-specific processors, download our white paper.

Roddy Urquhart

Roddy Urquhart

Related Posts

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

How to reduce the risk when making the shift to RISC-V

November 17, 2022
By Lauranne Choquin

DAC 2022 – Is it too risky not to adopt RISC-V?

July 18, 2022
By Brett Cline

Processor design automation to drive innovation and foster differentiation

July 7, 2022
By Lauranne Choquin

What does RISC-V stand for?


March 17, 2021

RISC-V stands for ‘reduced instruction set computer (RISC) five’. The number five refers to the number of generations of RISC architecture that were developed at the University of California, Berkeley since 1981. It is pronounced “risk-five” and you might sometimes see it written “RISC five“ or “R5“).

The RISC concept (like the parallel MIPS development in Stanford University) was motivated by the fact that most processor instructions were not used by most computer programs. Thus, unnecessary decoding logic was being used in processor designs, consuming unnecessary power and silicon area. The alternative was to simplify the instruction set and to invest more in register resources.

The RISC I project implemented a mere 31, 32-bit instructions but 78 registers. It introduced the notion of register windowing which was a technique that was later adopted by the SPARC architecture. This was closely followed by the RISC II project which had an even larger register file (138 registers). RISC II also introduced 16-bit instructions which improved code density. The terms RISC III and RISC IV have been used to refer to the SOAR and SPUR projects in 1984 and 1988, respectively.

The RISC-V project was partly motivated by the fact that proprietary, closed ISAs were restricted by patents and license agreements. Krste Asanović of the University of California, Berkeley was convinced that there were great advantages in having a free, open ISA that could be applied to both academic and industrial projects. David Patterson, who had worked on earlier RISC projects, was also involved. In 2010, a 3-month project led to the development of a new instruction set, leading to the publication of the first RISC-V ISA specification in 2011.

In order to manage contributions from other parties, the RISC-V Foundation – now RISC-V International – was formed in 2015 as an open collaborative community, and the original developers of the ISA transferred their rights around RISC-V to this organization. Since then, RISC-V International has managed further development of the RISC-V ISA.

Roddy Urquhart

Roddy Urquhart

Related Posts

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

How to reduce the risk when making the shift to RISC-V

November 17, 2022
By Lauranne Choquin

DAC 2022 – Is it too risky not to adopt RISC-V?

July 18, 2022
By Brett Cline

Processor design automation to drive innovation and foster differentiation

July 7, 2022
By Lauranne Choquin

Customizing an Existing RISC-V Processor


February 11, 2021

Using the open RISC-V ISA is a great starting point for creating a domain-specific processor that combines application-specific capabilities and access to portable software. But how do you create an optimized ISA, profiling software and experimenting with adding/removing instructions, in a smart and easy way? In other words, how do you customize an existing RISC-V processor efficiently?

How to modify the instruction set?

The industry will generally offer you two approaches. Either you do it manually or you automate the process as much as possible.

The manual approach

The old-fashioned way to modify the instruction set would be to:

  1. Modify the instruction set simulator (ISS) to change the ISA.
  2. Update the SDK to reflect the new set of target instructions.

This requires an extensive amount of manual work with associated technical risks. The resulting SDK will almost certainly need to make any custom instructions available as intrinsics or as inline assembler code. The alternative of modifying and verifying the compiler is costly in effort, but the end result is much better for the software developers. Similarly, if a processor is extended, traditionally it would be necessary to modify the microarchitecture by editing the RTL and then verify it against the ISS as the golden reference.

The automated approach

In contrast, describing the ISA in a processor description language like CodAL significantly improves the efficiency of this process using design automation tools. Codasip Studio can automatically generate both the ISS and a new compiler for the modified ISA, making the processor customization process more straightforward. But the CodAL processor description language is not just limited to creating instruction-accurate descriptions – it can also be used to describe microarchitecture (cycle-accurate). The consistency of the two descriptions can be checked within the Studio environment using static analysis.

A far easier approach is to not just to start with the RISC-V ISA, but with a complete RISC-V processor core design described in CodAL.

Automating the customization of a RISC-V CPU with Codasip Studio

Codasip’s RISC-V processors are all designed in Codasip Studio using the CodAL language. The range of cores spans simple 32-bit embedded cores to 64-bit Linux-capable application processors with multi-core capabilities. Thus, you can choose a processor that meets known baseline requirements such as pipeline depth and/or OS support, and then focus on creating custom extensions to improve performance. Starting with an already-proven processor design means that the microarchitecture for any new instructions is incremental, saving time and significantly reducing risk.

Codasip Studio verification flow diagram

Codasip Studio can be used to generate the HDK including the RTL, a testbench, EDA scripts, and a UVM environment. The UVM environment enables the all-important verification of the new processor RTL against its golden ISS reference. The generated UVM environment includes default cover points and assertions for key areas of functionality such as register files, bus protocols, memories, and caches. The third-party RTL simulator can measure the functional and RTL code coverage achieved.

After extending the microarchitecture, Codasip Studio profiler provides coverage analysis tools to assess code coverage of the CodAL, including line, condition, and expression coverage. In order to achieve acceptable code coverage, Codasip Studio provides random assembler generators to exercise the code very thoroughly. In difficult corner cases, it may be necessary to write directed tests.

Diagram that shows the Codasip Studio flow

All-in-all a Codasip RISC-V processor licensed as CodAL source code can be efficiently modified in the Codasip Studio environment and thoroughly verified. This is a cost-effective and super-efficient approach to creating domain-specific processors.

Learn more in our white paper “Creating Domain-Specific Processors with RISC-V custom 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

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

How to Choose an Architecture for a Domain-Specific Processor


January 29, 2021

If you are going to create a domain-specific processor, one of the key activities is to choose an instruction set architecture (ISA) that matches your software needs. So where do you start?

Some companies have created their instruction sets from scratch, but if you have such an ISA, a penalty may be the costs of porting software. Today, the RISC-V open ISA can provide you with an excellent starting point and a software ecosystem. Depending on what you need, there are several obvious starting points. In case of a 32-bit processor, if you start with RISC‑V, the base ISA (RV32I) is just 47 instructions. Using this base set is easier than creating proprietary instructions with similar functionality, as well as meaning that software is already available from the RISC-V ecosystem.

Starting point Number of instructions
RV32I 47
RV32IMC 101
RV32GC 164

Many use cases require multiplication suggesting that [M] extensions would be useful, and it is sensible to take advantage of the 16-bit compressed [C] instructions for code density, so it is commonplace to use the RV32IMC set which amount to 101 instructions. Using RISC-V as a starting point will ensure that it is straightforward to use common software such as an RTOS or protocol stack. If you additionally require floating point computation, then the RV32GC (G=IMAFD) instructions may be appropriate, additionally including atomic [A], single-precision floating point [F], and double-precision floating point [D] extensions. Even RV32GC only has 164 instructions.

The RISC-V ISA is designed in a modular way that allows processor designers to add not only any of the standard extensions, but also to create their own custom instructions while keeping full RISC-V-compliance. The standard extensions are a convenient option thanks to being readily available; however, some may substantially increase the instruction set complexity. For example, the complete set of packed SIMD extensions [P] adds 331 additional instructions. In many cases, sufficient gains for a particular application can be made with custom instructions with potentially a lower overhead in silicon area and power.

Having chosen the starting point for your domain-specific processor, it is then necessary to work out what special instructions are needed to meet your computational requirements. This requires a careful analysis of the software that you need to run on your processor core. A profiling tool allows computational hotspots to be identified. Once such hotspots are known, a designer can create custom instructions to address them. Therefore, a designer can iterate by experimenting with adding or deleting instructions, then profiling the software again and assessing whether the changes have achieved their objectives.

However, while this iterative process is logical, how would you actually do it in practice? You might be able to access an open-source instruction set simulator and toolchains such as GNU or LLVM, but modifying these by hand is something for toolchain specialists and is time-consuming.

The alternative is to describe the instruction set using a processor description language. In Codasip Studio, an instruction accurate (IA) model of a processor can be created using the CodAL processor description language. An SDK including compiler, instruction set simulator (ISS), debugger, and profiler can be automatically generated from the IA description.

By describing the ISA at a high level and automatically generating the SDK, it is possible to rapidly iterate experiments in extending the instruction set. In this way, it is possible to choose a well-optimized ISA for a domain-specific processor, sometimes known as an Application Specific Instruction Processor (ASIP). Generating the SDK automatically is not only faster, but less prone to errors than manual changes, meaning that the design process is cheaper and more predictable, avoiding unnecessary risk and roadmap disruptions.

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

Does ISA ownership matter? A Tale of Three ISAs


December 22, 2020

An instruction set architecture (ISA) is crucial to the development of processors and their software ecosystems. In the last half century, the majority of ISAs have been owned by single companies, whether product companies for their own chips/systems or processor IP companies who licensed their processors to chip developers. Does ISA ownership matter? Let’s consider three proprietary ISAs and their history.

Firstly, the Alpha ISA was developed by Digital Equipment Corporation (DEC) for its workstations and servers and was released in 1992. In the mid-1990s, this was considered a worthy competitor to SPARC and MIPS RISC architectures. However, the ownership of the ISA transferred to Compaq when DEC was acquired in 1998. Compaq in turn sold the rights to the Alpha ISA to Intel in 2001, and in the same year Compaq was acquired by Hewlett Packard. The last Alpha-based products were released in 2004, meaning that the ISA was effectively dead because of a series of acquisitions.

MIPS Technologies was spun out of Silicon Graphics as an independent IP company in 1998. For some years it enjoyed some success, particularly at the higher end of the processor IP market, and was only the second architecture to have Android ported in 2009. However, with a declining share price, MIPS sold 498 patents to AST and agreed to an acquisition by Imagination Technology in 2013. After Canyon Bridge acquired Imagination, MIPS was spun-out again ending up, after a series of transactions, as part of Wave Computing. As an artificial intelligence silicon provider, Wave is a potential competitor to some MIPS licensees.

Wave tried to encourage the adoption of the MIPS ISA in competition to RISC-V through their MIPS Open Initiative in late 2018. However, the licensing terms contained some onerous conditions relating to patents. In late 2019, Wave suddenly shut down the program, giving zero notice. The important lesson is that even if an ISA is open, its future is not secure if it is commercially owned. Seven years of ownership change have seen MIPS’ market share spiral downwards.

The third example is Arm, the biggest processor IP company of them all. Arm has long been seen as not only a big, successful IP company, but one offering “Swiss neutrality” in the semiconductor industry. Arm was quite distinct from both semiconductor companies and EDA companies. As such, it enjoyed a position of trust from its licensees as it did not have a conflict of interest. With its acquisition by SoftBank in 2016, Arm lost control over its destiny, even though SoftBank was not competing with its licensees. With the planned acquisition of Arm by NVIDIA, announced in September 2020, Arm will lose its neutrality completely. As a semiconductor company, there is a conflict of interest between Arm’s owners and its licensees, meaning it can no longer be trusted in the same way.

As can be seen from the ‘Tale of three ISAs’, the ownership of an ISA matters a lot, regardless of whether the ISA is commercially licensed or open. Acquisitions can lead to the disappearance of an ISA through merging of product lines or through making licensing difficult. Another motive for taking over a company can even be to kill off a competing product line, which in the case of an ISA could catastrophically impact licensees.

ISA ownership is one of the key issues that the developers of RISC-V have thought about. By transferring the ownership of the ISA to RISC-V International, the original developers of the ISA have assured its longevity. Longevity is assured both by the independent ownership of the ISA and the fact that licensees have a choice of IP vendors supporting the same open standard. Thirdly, once ratified, the ISA is frozen assuring software developers that their code will be able run on suitable cores indefinitely.

Roddy Urquhart

Roddy Urquhart

Related Posts

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

Design for differentiation: architecture licenses in RISC‑V

May 16, 2022
By Rupert Baines

Closing the Gap in SoC Open Standards with RISC-V

March 24, 2022
By Roddy Urquhart

What is the difference between processor configuration and customization?

August 12, 2021
By Roddy Urquhart

Open Source vs Commercial RISC-V Licensing Models


November 26, 2020

Everybody is familiar with commercial licensing from traditional processor IP vendors such as Arm, Cadence, and Synopsys. But in discussing the RISC-V Open Instruction Set Architecture (ISA), there is widespread confusion of terminology with RISC-V often being described as “open source”. Some have even accused vendors of commercial RISC-V IP such as Codasip or Andes as not being in the spirit of RISC-V. But what is reality? What does the RISC-V licensing model for processor IP look like?

What does open source, open standard and commercial mean?

Let’s look at definitions briefly. An open standard like C, Verilog or HTTP is defined by a document that is maintained by an independent organization. Thus, C is maintained by ISO, Verilog by IEEE, and HTTP by IETF. These organizations maintain the technical standards using a set of impartial rules. Such open standards are generally freely accessible.

With open source, the source code for a software package or the hardware description language source for a hardware block are made available using a license. Open-source licenses vary from restrictive ones, such as copyleft license, to permissive ones, such as Apache. An open-source license defines rights for using, studying, modifying, and distributing the code. A copyleft license will require that any modifications be open-sourced, while a permissive license will not.

RISC-V is an open standard, and the ISA does not define any microarchitecture or business model. Therefore, a RISC-V microarchitecture can be licensed either as a commercial IP license or as an open source one. Nothing is prescribed.

If we think of a classic commercial processor IP license, you are generally paying for:

  •       The right to use the vendor’s ISA
  •       The right to use the vendor’s microarchitecture
  •       A warranty
  •       Vendor commitment to fix errors
  •       Indemnification

In practice, the warranty is usually time-bound, and the indemnification is limited. However, for the licensee, the vendor has some commitments to fix a design if bugs are found, which is valuable particularly on a tight schedule. If a licensee is accused of patent infringement, intellectual property indemnification means that the vendor will either defend the accusation or settle it on behalf of the licensee.

Traditional architecture and IP licensing model vs. RISC-V licensing model

Classic IP vendors have jealously guarded their own ISAs as well as their microarchitectures. A normal license bundles the use of the ISA with the microarchitecture and there are no rights to modify the deliverables. Very rarely such vendors have offered an architectural license which has enabled the licensee to use the ISA with their own microarchitecture, but such licenses have commanded substantial fees. One reason why RISC-V is very disruptive is that with a free and open ISA, one of the most valuable possible deliverables has no license fee.

Is RISC-V free? Open-source and commercial RISC-V based IP cores

Given that RISC-V does not prescribe microarchitecture or how it is licensed, there are both commercially licensed and open-source RISC-V IP cores. With an open-source license, you pay no license fee for the microarchitecture, but you also do not get all the benefits of a commercial license. Generally, deliverables have no warranty and are accepted “as is”. Similarly, there is not the indemnification that exists with a commercial license. If bugs are found, then either the licensee or the open-source community needs to fix them.

With commercially licensed RISC-V cores, the only fees are associated with the microarchitecture as the RISC-V ISA is licensed free of charge. With this license, you get the warranty, indemnification and bug fixing commitments normally associated with a commercial license.

What is the right licensing model for RISC-V?

We often get the question “Is RISC-V really open source?”. RISC-V is an open standard that allows companies to create RISC-V microarchitectures. Companies can then license the IP as either open-source or commercial. Which is the right choice for RISC-V? Both commercial licenses and open source licenses have advantages and disadvantages. You need to weigh up what is best for your design project.

At Codasip, we offer commercial RISC-V IP licenses and Codasip Studio technology that enables our customers to modify both the microarchitecture and the architecture.

In the past, commercial and open source licenses were seen as bitter competitors. However, in the software world, companies such as Microsoft have embraced both models. Microsoft offers commercial licenses, supports open source projects, and has cloud-based business models. Commercial and open-source RISC-V licenses can co-exist and complement each other.

Roddy Urquhart

Roddy Urquhart

Related Posts

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

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

Closing the Gap in SoC Open Standards with RISC-V

March 24, 2022
By Roddy Urquhart

More than Moore with Domain-Specific Processors


May 6, 2020

Last month was the 55th anniversary of Gordon Moore’s famous paper Cramming more components onto integrated circuits. He took a long-term view of the trends in integrated circuits being implemented using successively smaller feature sizes in silicon. Since that paper, integrated circuit developers have been relying on three of his predictions:

  1. The number of transistors per chip increasing exponentially over time.
  2. The clock speed increasing exponentially.
  3. The cost per transistor decreasing exponentially.

These predictions have largely held true for almost half a century, enabling successive generations of processors to achieve higher computational performance through greater processor complexity and higher clock speeds. These improvements were mainly delivered through general-purpose processors implemented in new technology nodes.

From about 2005, the improvements in clock frequency began to level off, leading to a levelling-off of single thread performance. Since then, using multiple cores on a single die has become commonplace, but again these cores were mainly general-purpose ones, whether application processors or MCUs.

If you are designing a chip with some performance challenges, do you simply follow Moore’s law and move into a smaller silicon geometry and use general-purpose processor cores? That could be a costly approach since mask-making costs are higher in small geometries. Also, you may not achieve your performance in the most efficient way.

Many embedded applications involve cryptography, DSP, encoding/decoding or machine learning. Each of these operations typically run inefficiently on a general-purpose core. For example, Galois fields are commonly used in cryptography, but multiplication operations take many clock cycles.

So, what can be done to deal with computational bottlenecks? In extreme cases, like dealing with real time video data, it may make sense to create dedicated computational units to handle a narrow range of computationally intensive operations. However, this may not be the best trade-off.

It will often be desirable to run both computationally intensive operations and other embedded functions on the same processor core.  Ideally, the most silicon-efficient processor implementation will be one that is tuned for your particular application.

This can be achieved by creating a processor core that has custom instructions targeted to address the bottlenecks. Adding custom instructions does not have to be expensive in silicon resources. For example, Microsemi created custom DSP instructions for their RISC-V-based audio processor products: Their custom Bk RISC-V processor delivered 4.24× the performance of the original RV32IMC core but required only a 48% increase in silicon area. Furthermore, the code size shrunk to 43% of the original size1.

So how can you efficiently implement custom instructions? And equally importantly, how do you verify that they are implemented correctly? We will be visiting these topics on future posts.

1 Dan Ganousis & Vijay Subramaniam, Implementing RISC-V for IoT Applications, Design Automation Conference 2017

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