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 needed to support an operating system?


October 15, 2020

For each embedded product, software developers need to consider whether they need an operating system; and if so, what type of embedded OS. Operating systems vary considerably, from real-time operating systems with a very small memory footprint to general-purpose OSes such as Linux with a rich set of features.

Which type of OS is typically found on an embedded system?

Choosing a proper type of operating system for your product – and consequently working out the required features of the embedded processor – depends significantly on whether you face a hard real-time requirement. Safety-critical and industrial systems such as an anti-lock braking system or motor control will have hard maximum response times. At the other end of the spectrum, consumer systems such as audio or gaming devices may be able to tolerate buffering, as long as the average performance is adequate. Such systems are said to have soft real-time requirements.

Bare metal

A hard real-time requirement can be achieved by writing so-called bare-metal software that directly controls the underlying hardware. Bare-metal programming is typically used when the processor resources are very limited, the software is simple enough, and/or the real-time requirements are so tight that introduction of a further abstraction layer would complicate meeting these hard real-time requirements. The disadvantage to this approach is that such bare-metal software needs to be written as a single task (plus interrupt routines), making it difficult for programmers to maintain the software as its complexity grows.

Real-time Operating Systems

When dealing with more complex embedded software, it is often advantageous to employ a Real-Time Operating System (RTOS). It allows the programmer to split the embedded software into multiple threads whose execution is managed by the small, low-overhead “kernel” of the RTOS. The use of the multi-threaded paradigm enables developers to create and maintain more complex software while still allowing for sufficient reactivity.

RTOSes typically operate with a concept of “priority” assigned to individual threads. The RTOS can then “pre-empt” (temporarily halt) lower-priority threads in favour of those with higher priority, so that the required real-time constraints can be met. The use of an RTOS often becomes necessary when adopting complex libraries or protocol stacks (such as TCP/IP or Bluetooth) as this third-party software normally consists of multiple threads already.

The embedded processor requirements of a simple RTOS, such as FreeRTOS or Zephyr, are truly modest. It is sufficient to have a RISC-V processor with just machine mode (M) and a timer peripheral. However, rigorous software development is needed as machine mode offers unconstrained access to all memory and peripherals with associated risks. Extra protection is possible through a specialized RTOS such as those developed for functional safety, like SAFERTOS, or for security.

If a processor core supports both machine (M) and user (U) privilege modes and has physical memory protection (PMP), it is possible to establish separation between trusted code (with unconstrained access) and other application code. With PMP, the trusted code sets up rules for each portion of the application code, saying which parts of memory (or peripherals) it is allowed to access. PMP can for instance be used to prevent third-party code from interfering with the data of the rest of the application, or to detect stack overflows. Employing PMP therefore increases the safety and security of a system, but at the cost of additional hardware required for its support.

We also discuss embedded OS support in this video!

Rich operating systems

For applications requiring a more advanced user interface, sophisticated I/O and networking, such as in set-top boxes or entertainment systems, an RTOS is likely to be too simplistic. The same applies if there are complex computations, requirements for a full process isolation and multitasking, filesystem & storage support, or a full separation of application code from hardware via device drivers. Systems like these generally have soft real-time requirements and can be best served by a general-purpose rich operating system such as Linux. As mentioned in our blog post dedicated to processor complexity, Linux requires multiple RISC-V privilege modes – machine, supervisor, and user modes (M, S, U) – as well as a memory management unit (MMU) for virtual-to-physical address translation. Also, the memory footprint of such a system is significantly larger compared to a simple RTOS.

Finally, for embedded systems that require both hard real-time responses and features of a rich OS like Linux, it is common to design them with two communicating processor subsystems, one supporting an RTOS and the other running Linux.

The OS support will impact your processor choice

Choosing the appropriate embedded OS for your product and identifying the features required for your embedded processor depends heavily on the type of real-time requirements you face. Together with processor performance and complexity, among other key considerations, the OS support you need should be taken into account when choosing a processor. To find out more, read our white paper on “What you should consider when choosing a processor IP core”.

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 processor core complexity?


September 10, 2020

The more complex a processor core, the larger the area and power consumption. But increasing complexity is not a single dimension as processors can be more complex in different ways. In selecting a processor IP core, it is important to choose the right sort of processor complexity for your project.

What defines the complexity of a processor?

There are different ways of thinking about processor complexity. Word length, execution units, privilege modes, virtual memory and security features are important considerations that will make your processor core more complex. It is important to understand what you really need for your project.

Word length

Generally, the smaller the word length, the smaller the core and the lower the power, however this is not always the case. An 8-bit core, such as the 8051, is comparable in gate count to the smallest 32-bit cores, but power consumption is usually worse. An 8-bit core requires more memory accesses due to less computation per clock cycle requiring more cycles. The net impact is that it requires more power to complete a computation.

Execution units

Processor cores vary considerably in the complexity of their execution units. The simplest are basic single ALUs requiring many common operations to be implemented by the simple instructions – for example using shift and add to implement a multiplication. It is therefore commonplace for cores to have a hardware multiplier and divider. In the event of needing good floating-point performance, adding a hardware Floating Point Unit (FPU) will provide significantly better performance. This option is available for Codasip’s Low-Power (L) and High-Performance (H) Embedded RISC-V processor cores but at the price of roughly doubling the core size.

Superscalar architectures with instruction-level parallelism

So far, we have assumed a single computational thread and scalar processing units which execute one instruction at a time. Superscalar architectures have instruction-level parallelism able to fetch multiple instructions and dispatch them to different execution units. A dual-issue core processing one thread can theoretically have up to double the performance of a single-issue core. However, a thread can stall making both execution units temporarily inactive. If there are two hardware threads (harts), then if one thread stalls, the other can continue execution.

Processors can vary considerably in pipeline depth and there is a direct relationship between this depth and latency. Some applications can tolerate high latency, with the consequence being slower response to interrupts, in return for high clock frequencies and throughput. Other applications require rapid responses to interrupts so need shorter pipelines.

We also discuss processor complexity in this video!

Privilege modes

Another area of complexity is privilege modes. The more modes, the more complex the core logic. Many embedded applications run in machine mode, which means that the code has full access to the core – like root privilege in Linux. Such code must be completely trusted to avoid negative consequences. In more sophisticated applications, a range of privileges such as machine, supervisor and user may be offered. Normal applications will run in user mode with the greatest amount of protection and some software requiring greater privilege will use supervisor mode.

Virtual memory

Virtual memory also requires additional processor resources such as a memory management unit (MMU) and translation lookaside buffer (TLB) to handle translating virtual memory addresses to physical addresses. This brings additional costs in terms of area and power dissipation without improving processor throughput. Nevertheless, virtual memory is necessary for using rich operating systems such as Linux which enable more complex software to be used.

So, when choosing a processor core, work out what sort of execution units, memory management, privilege and security you need. That combination will determine the complexity of the core.

Consider processor complexity when choosing a core – but not only that!

So, when choosing a processor core, work out what sort of execution units, memory management, privilege and security you need. That combination will determine the complexity of the core. But that’s not all. If PPA numbers are typically considered when looking at the wide choice of processor IP cores on the market, that’s not enough. Processor complexity is one element, but processor performance, software requirements and the ISA, among others, are key considerations to investigate. We cover these in our white paper “What you should consider when choosing a processor IP core”.

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

Understanding the Performance of Processor IP Cores


August 20, 2020

Looking at any processor IP, you will find that their vendors emphasize PPA (performance, power & area) numbers. In theory, they should provide a level playing field for comparing different processor IP cores, but in reality, the situation is more complex. Let us consider processor performance.

What does processor performance mean?

The first thing to think about is what aspect of performance you care about. Do you care more about the absolute throughput that you want (performance per second), or the performance per MHz? In an application such as machine vision, which is continuously running and requiring the use of complex algorithms, it is likely that you will care about the absolute throughput. However, if you have a wireless sensor node with a low duty cycle, when the node wakes up, you will want it to be active for as few clock cycles as possible. This means you will care about how much computation you achieve per MHz.

About 40 years ago, computers were compared on the basis of MIPS (millions of instructions per second) although the problem is – what is an instruction? Instructions vary considerably in complexity and from one architecture to another, thus an operation will generally require less cycles in a CISC processor than a RISC one. MIPS were only helpful when comparing products with similar architectures and were called “meaningless indices of performance” by some!

Another thing to think about is the type of computation that you expect to care most about. Is it integer operations – and if so, which ones – or, say, floating-point computations? In the past, MFLOPS (million floating point operations per second) was a popular measure. But again, what is an ‘operation’?

Popular synthetic benchmarks

Today, synthetic benchmarks are universally used with processor IP cores. They have the following characteristics:

  • They are relatively small and portable.
  • They are representative of commonly used relevant applications.
  • They are reproducible and transparent.
  • They can be applied to a range of processors fairly.
  • They express the benchmark result as a single number.

Dhrystone

A benchmark that has been popular for the last 36 years is the Dhrystone benchmark. Its name is a play on words comparing it with the once-popular Whetstone benchmark. While Whetstone focused on floating point operations, Dhrystone focused on integer and string operations. The Dhrystone benchmark results are generally quoted as DMIPS (the Dhrystone score divided by that of a nominally 1 MIPS machine). The benchmark has been criticized because modern compilers can optimize away parts of the work, meaning that it partly tests compiler rather than processor performance.

For floating point, Whetstone is rarely used at present and it is more likely that LINPACK would be used. LINPACK involves LU decomposition of a matrix using floating point numbers. The result is expressed in MFLOPS.

CoreMark

Another popular synthetic benchmark for embedded applications has been EEMBC’s CoreMark® which aims to undertake operations that are representative of embedded integer processing needs. These include list processing, matrix operations, finite state machines, and CRC.

Find more details and some tips to measure processor performance according to your needs in this video!

Assessing performance when choosing a processor

There are various benchmark systems out there, each suited for measuring a slightly different type of performance. So how do you assess performance when choosing processor IP for your project?

If your embedded software has similar operations to a synthetic benchmark, then that benchmark may give you useful initial guidance quickly and simply. However, normally such benchmarks are quoted per MHz, for example CoreMark/MHz. The per MHz figure is normally a good indication for a low-power application where you are looking for good results per cycle. However, if you are looking for high absolute performance, this may be misleading. Instead you should consider, say, the CoreMarks achievable at your target clock frequency.

If your main issue is floating-point performance, bear in mind that DMIPS and CoreMark are integer benchmarks. You would be better comparing cores on the basis of a floating-point benchmark such as LINPACK.

Ultimately, it always makes sense to invest the time in running realistic software on a processor core to assess whether the core gives you the performance you need. If you are looking at RISC-V, then profiling your software to understand where the computational bottlenecks are can also lead to assessing whether adding custom instructions can give you improvements in performance.

It is not just about processor performance and scores

In this article we have looked at processor performance, but that is only one aspect of PPA and one factor to consider when choosing a processor. PPA numbers are always about balance and all of them matter when choosing an IP for a project, among other key considerations. The ISA, processor complexity, processor memory or even the licensing model will impact your choice. Find out more in our white paper “What you should consider when choosing a processor IP core“.

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

Codasip Announces Bk5-64, a New 64-bit RISC-V Processor


November 28, 2017

Brno, Czech Republic – November 28th, 2017 – Codasip, the leading supplier of RISC-V® embedded processor IP, today announced that it has expanded its Berkelium processor portfolio to include the Bk5-64, its first implementation of the 64-bit RISC-V ISA.

Codasip now offers customers the broadest selection of RISC-V processors in the market, spanning from the ultra-low-power zero-stage Bk1 to the high-data-bandwidth, energy-efficient Bk5-64. All Berkelium processors are generated via the unique Codasip Studio customization tool, allowing for fast configuration and optimization of the cores.

With the rapid expansion of data-intensive applications such as storage and wireless networking, the market is asking for embedded processor solutions with the right balance of performance and energy efficiency that 64-bit computing requires,” stated Karel Masařík, founder and CEO of Codasip. “By introducing the Bk5-64, Codasip is addressing the need for affordable 64-bit embedded processors, complete with a state-of-the-art LLVM-based software development toolchain with advanced profiling.”

RISC-V is an open, free instruction set architecture (ISA) enabling a new era of processor innovation through open standard collaboration. Born in academia and research, RISC-V ISA delivers a new level of free, extensible software and hardware freedom on architecture, paving the way for the next 50 years of computing design and innovation.

Said Rick O’Connor, Executive Director of the non-profit RISC-V Foundation, “Today’s announcement from Codasip shows continued growth of the RISC-V architecture and the industry’s need for a new open, free ISA. We look forward to seeing more developments from Codasip and others from the RISC-V ecosystem in the future.

The Berkelium Bk5-64 RISC-V processor is available later in Q4 of 2017.

About Codasip

Codasip delivers leading-edge processor IP and high-level design tools that provide ASIC designers with all the advantages of the RISC-V open-standard ISA, along with the unique ability to automatically optimize the processor IP. As a founding member of the RISC-V Foundation and a long-term supplier of LLVM and GNU-based processor solutions, Codasip is committed to open standards for embedded processors.

Formed in 2006 and headquartered in Brno, Czech Republic, Codasip currently has offices in the US and Europe, with representatives in Asia and Israel.

For more information about Codasip’s products and services, visit codasip.com.

Kava

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

Codasip Announces Latest RISC-V Processor


August 21, 2017

The Newest Codasip RISC-V Processor is Ideal for IoT Designs

Brno, Czech Republic – August 21st 2017 – Codasip, the leading supplier of RISC-V® embedded CPU cores, today announced the newest addition to their Berkelium (Bk) family of RISC-V processors. The Codasip Bk-1 processor is an FSM processor targeted at the Internet of Things (IoT) by offering ultra-low power, the lowest cost of all comparable embedded processors, and optimal performance/power efficiency.

Karel Masařík, CEO and founder of Codasip, stated: “This processor is perfect for IoT ASIC designers looking to move up from 8-bit processors to 32-bit processors. Like all members of the Codasip Bk family of processors, the Bk-1 is fully compliant with the RISC-V open standard, assuring customers that their embedded software is truly portable and their designs are not locked into a proprietary instruction set architecture (ISA) such as Arm.”

The Bk-1 processor was designed to provide impressive 32-bit performance, small code size, and minimal power, area, and cost. In its basic configuration, the Bk-1 starts at 9k gates while delivering a maximum clock frequency of up to 350 MHz in a 55nm process. The Bk-1 has an optional power management unit, JTAG debug controller, and bridges to the AMBA buses so it can be easily integrated into existing Arm designs.

Codasip provides their customers with high-level design tools that automatically profile the embedded SW and allow ASIC designers to tailor the Bk-1 processor exactly to its intended application. This unique ability to automatically modify the Codasip cores results in far better implementations compared to other processor IP vendors, and allows for the process to be easily completed in a day or two with the silicon proven Codasip Studio tool suite.

“Codasip’s new Bk-1 processor is another great milestone for the RISC-V ecosystem and shows ongoing market growth of its open and free architecture,” said Rick O’Connor, executive director of the non-profit RISC-V Foundation. “The Foundation will continue to support member organizations, such as Codasip, in bringing to market RISC-V-based processors that enable new designs and innovation.”

About Codasip

Codasip delivers leading-edge processor IP and high-level design tools that provide ASIC designers with all the advantages of an open standard, such as the RISC-V ISA, along with the unique ability to automatically optimize the processor IP. As a founding member of the RISC-V foundation (riscv.org) and a long-term supplier of LLVM and GNU based processor solutions, Codasip is committed to open standards for embedded processors. Formed in 2006 and headquartered in Brno, Czech Republic, Codasip currently has offices in the US and Europe, with representatives in Asia and Israel. More information on Codasip’s products and services is available at codasip.com.

Press Contact

Codasip North America
Dan Ganousis
ganousis@codasip.com
+1 (303) 859-3048

Codasip EMEA
Roddy Urquhart
urquhart@codasip.com
+44 753 158 7023

Kava

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 RISC-V? Why We Care and Why You Should Too


September 22, 2016

The RISC-V revolution is happening and changing the way we do business in the semiconductor industry. However, there is one big misconception about it: No, RISC-V is not an open-source processor. Let me try and answer the question “What RISC-V?” and tell you why Codasip truly cares about it – and why you should too.

What is RISC-V?

RISC-V is an open specification of an Instruction Set Architecture (ISA). That is, it describes the way in which software talks to an underlying processor – just like the x86 ISA for Intel/AMD processors and the Armv8 ISA for the latest and greatest Arm processors. Unlike those however, the RISC-V ISA is open (we discuss commercial vs. open-source architecture licenses in a separate blog post) so that anyone can build a processor that supports it. We often get two questions: “Is RISC-V a processor?” and “Does RISC-V mean open-source processors?”. Now you know the answer is No.

What’s the big deal about RISC-V vs. Arm or Intel/AMD?

For companies supplying products to customers, lock-in is a wonderful thing. It means that once the vendor has the customer it is very hard for the customer to change to a competitor’s product. The best way to create lock-in is to have good-enough products and a rich ecosystem. That way, once you have the customer, they have invested too much into the implementation and you have them locked-in for a very long time. Any new competitor must have a better product, but also build an equivalent ecosystem. Even then it will be almost impossible for a customer to do an apples-to-apples comparison based on the merits of the solution.

Just like the old saying that no one ever got fired for buying IBM, these days it is accepted that no-one ever gets fired for using Arm processors. There is a dark side to this however. If companies are not able to compete on the merit of their solutions, progress stagnates. Companies invest just enough to keep customers happy – no more, no less.

RISC-V changes this dynamic since a single software ecosystem built on the RISC-V standard supports many different processor vendors, and the processor vendors must now compete on the merit of their product for different applications. Customers don’t need to settle for good-enough, and competition will mean a significant acceleration of innovation in embedded processors. Also, without the need for each new processor startup to build an expensive ecosystem, many new innovative processor companies will appear.

What’s the downside of commercial architecture licenses?

For customers there is none. For processor IP companies, good-enough is no longer enough. Vendors like Codasip will have to ensure we are meeting and exceeding the customer’s needs and supplying the best possible solution, or they can easily move to a new supplier. Some analysts believe RISC-V will lead to commoditization of the processor IP, however, I believe it will lead to specialization and innovation. It will not be a race to the bottom, but rather an opportunity to supply additional value to customers and users.

Is the RISC-V ISA open source?

Thanks to the work of a number of academic institutions – especially UC-Berkley, the original creators of the RISC-V specification – there are a number of free open-source implementations of the RISC-V ISA. These open-source implementations are already allowing various academic and open-source SoC projects to do work that would have been impossible without an open standard. More importantly, however, commercial companies are free to create their own implementation of RISC-V processors. This gives customers an even greater range of options.

How does RISC-V fit with Codasip and application optimized processors?

RISC-V is a layered and extensible ISA which means a processor can implement the minimal instruction set, well-defined extensions, and custom extensions for a given application. As long as the minimal set needed for a given application is implemented, that application will run on any compatible processor.

This removes one of the biggest barriers for application optimized processors, the effort required to develop the ancillary software around the processor. As such, up until now, most ASIPs (Application Specific Instruction-set Processors) have been used in deeply embedded environments where the software environment was limited, and well defined. Having a common software ecosystem means customers will now be free to add application extensions to any processor, being able to take advantage of the significant improvements they provide, without the downside.

“For many systems, the best processor is one tailored for its task”. Check our blog post on How to extend the “unscalable” RISC architectures.

Who maintains the RISC-V standard?

The standard is maintained by RISC-V International, with members (including Codasip) coming from across the industry including software, systems, semiconductor and IP. The focus of member companies is on building a rich ecosystem of hardware and software that will rival or surpass that of companies like Arm.

What is the future of RISC-V?

Unfortunately I don’t have a magic crystal ball, but after many years in the semiconductor industry, what I can say is that I have never before seen so much interest in a new standard, and such a diverse set of companies working together to make it a reality – including processor IP competitors all targeting the same specification.
Is RISC-V the future? I expect that we will see an explosion of innovation and growth, very similar to what happened in the enterprise software space once people were able to build on common open standards.

As they say – A rising tide lifts all boats. It will be an exciting few years!

Karel Masarik

Karel Masařík

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