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

Building the highway to automotive innovation


May 5, 2022

The semiconductor industry has changed and nowhere is this more visible than in the automotive industry. Global chip shortages have highlighted how dependent we are on silicon to keep cars on the roads. These shortages are also keeping wait times for new vehicles at an all-time high.

Add to this an influx of non-traditional players into the market and it’s easy to see why the automotive sector is arguably the hottest in the tech world right now. A new marketplace in automotive innovation and technology is taking shape with a battleground between existing pillars, tech giants and new business models. The ability to differentiate in this market is the key to success, bringing subtly different needs and requiring solutions with a different approach.

The electronics needs of the car are changing but always come back to compute

Two things are fundamentally changing in the automotive industry: the concept of software-defined vehicles (SDVs) and the need for democratizing innovation at design level. This transition from hardware to software unlocks new services and solutions for car manufacturers, enabling the delivery of updates and upgrades over the air for a better driver experience. And here, computing is a focus for the next generations of vehicles.

Bringing hardware closer to the system engineering is a different approach and exactly what Codasip can enable. The combination of Codasip Studio technology with RISC-V processor IP delivers access to rapid innovation, ownership and cost reduction right into the hands of automotive players. These are companies of all sizes that are experiencing the pains today. Democratizing processor design is a real demand that is accelerating automotive innovation in the supply chain. Codasip and RISC-V offer the ability to innovate rapidly at design level by reducing cost and complexity.

The need for ownership in the automotive sector

The ability to differentiate in a rapidly evolving sector such as automotive is key to success, or even survival. Owning the ability to Design for Differentiation is crucial and that is exactly what Codasip enables.

Centered in Europe, we are surrounded by the world’s largest market for automotive innovation and manufacturing and away from geopolitical challenges. We are surrounded by leading experts and customers and are able to work closely with them to build a world-class capability by deeply understanding the challenges and find solutions. These solutions benefit our automotive customers and their end customers – as well as the wider automotive industry, to some extent.

Design for differentiation is our buzzword. We are unlocking the true potential of RISC-V by providing our customers with best-in-class quality IP and processor design automation technology with the potential to enable and accelerate the innovation that the automotive industry needs through processor customization. In a reshaping world and supply chain, we are enabling innovation at a much lower cost, removing the barrier to entry, leading into ownership of the processor design.

Security and safety embedded by design

Having security and safety embedded by design and allowing our customers to rapidly make changes to the design while maintaining safety, security integrity and proof of the design – without a lengthy design cycle – is fundamental.

Despite chip shortages, chip innovation is booming and that applies especially to the automotive sector. It is abundantly clear that the future of automotive is through innovation and differentiation. Codasip’s processor design automation technology and EDA tooling has the potential to accelerate innovation in the automotive supply chain, and to enable innovation in electrification and safe and secure applications for connected and autonomous vehicles.

Jamie Broome recently joined Codasip as VP Automotive after more than 20 years at Imagination Technologies. Read the press release on his appointment and the exciting opportunities ahead for Codasip and the industry.

Jamie Broome photo 2

Jamie Broome

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

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 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

Domain-Specific Accelerators


May 21, 2021

Semiconductor scaling has fundamentally changed

For about fifty years, IC designers have been relying on different types of semiconductor scaling to achieve gains in performance. Best known is Moore’s Law which predicted that the number of transistors in a given silicon area and clock frequency would double every two years. This was combined with Dennard scaling which predicted that with silicon geometries and supply voltages shrinking, the power density would remain the same from generation to generation, meaning that power would remain proportional to silicon area. Combining these effects, the industry became used to processor performance per watt doubling approximately every 18 months. With successively smaller geometries, designers could use similar processor architectures but rely on more transistors and higher clock frequencies to deliver improved performance.

48 Years of Microprocessor Trend Data. Source K. Rupp.

Since about 2005, we have seen the breakdown of these predictions. Firstly, Dennard scaling ended with leakage current rather than transistor switching being the dominant component of chip power consumption. Increased power consumption means that a chip is at the risk of thermal runaway. This has also led to maximum clock frequencies levelling out over the last decade.

Secondly, the improvements in transistor density have fallen short of Moore’s Law. It has been estimated that by 2019, actual improvements were 15× lower than predicted by Moore in 1975. Additionally, Moore predicted that improvements in transistor density would be accompanied by the same cost. This part of his prediction has been contradicted by the exponential increases in building wafer fabs for newer geometries. It has been estimated that only Intel, Samsung, and TSMC can afford to manufacture in the next generation of process nodes.

Change in design is inevitable

With the old certainties of scaling silicon geometries gone forever, the industry is already changing. As shown in the chart above, the number of cores has been increasing and complex SoCs, such as mobile phone processors, will combine application processors, GPUs, DSPs, and microcontrollers in different subsystems.

However, in a post-Dennard, post-Moore world, further processor specialization will be needed to achieve performance improvements. Emerging applications such as artificial intelligence are demanding heavy computational performance that cannot be met by conventional architectures. The good news is that for a fixed task or limited range of tasks, energy scaling works better than for a wide range of tasks. This inevitably leads to creating special purpose, domain-specific accelerators.
This is a great opportunity for the industry.

What is a domain-specific accelerator?

A domain-specific accelerator (DSA) is a processor or set of processors that are optimized to perform a narrow range of computations. They are tailored to meet the needs of the algorithms required for their domain. For example, for audio processing, a processor might have a set of instructions to optimally implement algorithms for echo-cancelling. In another example, an AI accelerator might have an array of elements including multiply-accumulate functionality in order to efficiently undertake matrix operations.

Accelerators should also match their wordlength to the needs of their domain. The optimal wordlength might not match common ones (like 32-bits or 64-bits) encountered with general-purpose cores. Commonly used formats, such as IEEE 754 which is widely used, may be overkill in a domain-specific accelerator.

Also, accelerators can vary considerably in their specialization. While some domain-specific cores may be similar to or derived from an existing embedded core, others might have limited programmability and seem closer to hardwired logic.  More specialized cores will be more efficient in terms of silicon area and power consumption.
With many and varied DSAs, the challenge will be how to define them efficiently and cost-effectively.

Roddy Urquhart

Roddy Urquhart

Related Posts

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

Building the highway to automotive innovation

May 5, 2022
By Jamie Broome

RISC-V Summit 2021

December 17, 2021
By Rupert Baines

Why and How to Customize a Processor

October 1, 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

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

When Considering Processor PPA, Don’t Forget the Instruction Memory


November 12, 2020

The area of any part of a processor design contributes both to the silicon cost and to the power consumption. A simplistic following of the “A” in a processor IP vendor’s PPA numbers can be misleading. A processor is never used in isolation but is part of a subsystem additionally including instruction memory, data memory, and peripherals. In most cases, instruction memory will be dominant and the processor area is much less important.

What impacts the size of the instruction memory in a processor?

The size of the instruction memory will be influenced by the target instruction set, the compiler and the compiler switches used. In the case of RISC-V, the choice of optional standard extensions and custom extensions can greatly influence the codesize.

Instruction set and processor memory: the example of Microsemi

To illustrate this, the following table shows the effect of adding extensions to both core and codesize.

ISA Core size (kgates) Increase over base Codesize (kbytes) Decrease over base
RV32I (base) 16.0 × 1.0 232 × 1.0
RV32IM 26.2 × 1.6 148 × 1.6
RV32IM+DSP 38.7 × 2.4 64 × 3.6

Source: Implementing RISC-V for IoT applications, Dan Ganousis & Vijay Subramaniam, DAC 2017

In this example, Microsemi used a Codasip RISC-V L31 processor to implement an audio processing application. Starting with just the 32-bit base instruction set, they had an unacceptably high codesize and cycle count. Some improvement was achieved by adding multiplication [M] extensions, but the breakthrough was using custom DSP instructions. These led to a 3.6× reduction in codesize at the price of a 2.4× increase in core size compared with the base core. With instruction memory dominating the area, this was a good trade-off; furthermore, the performance goals were readily achieved.

Compilers, complex switches and PPA

With typical vendor PPA data, synthetic benchmarks such as CoreMark/MHz are often quoted with a complex set of compiler switches – this is something we discussed in our article dedicated to processor performance. But in practice, embedded software is probably going to be compiled using common switches such as ‑Os or ‑O3.

Consider compiling the CoreMark benchmark with different switches using the common GCC compiler. In this case, the target was a Codasip RV32IMC RISC-V core with a 3-stage pipeline. 

The chart below shows CoreMark/MHz and codesize measures for different compiler settings. The last example is one that is typical of vendor performance data where many switches are used for CoreMark (CM = “-O3 -flto -fno-common -funroll-loops -finline-functions -falign-functions=16 -falign-jumps=8 -falign-loops=8 -finline-limit=1000 -fno-if-conversion2 -fselective-scheduling -fno-tree-dominator-opts -fno-reg-struct-return -fno-rename-registers –param case-values-threshold=8 -fno-crossjumping -freorder-blocks-and-partition -fno-tree-loop-if-convert -fno-tree-sink -fgcse-sm -fgcse-las -fno-strict-overflow”).

In this example, the CoreMark/MHz score grows as the switches change from left to right. However, it is interesting to note that the most complex set of switches increases the codesize by 40 % over ‘‑O3’ while the performance only improves by 14 %.

Not every example will behave in this way, but compiler switches influence both performance and codesize. It is important to be realistic about what compiler switches you would like to use, and to ensure that the switches for any performance benchmark data matches those you would use for assessing codesize.

The impact of PPA on your processor choice

PPA numbers will inevitably be used to compare processors. However, these indicators need context to be representative of your actual needs, and not be misleading. Some key considerations, including OS support and ISA choices, will also influence your processor choice. 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!

Building the highway to automotive innovation

May 5, 2022
By Jamie Broome

Why and How to Customize a Processor

October 1, 2021
By Roddy Urquhart

What is the difference between processor configuration and customization?

August 12, 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