EDA
Processor design automation for RISC-V domain-specific accelerators
By Roddy Urquhart, senior director of marketing, Codasip F
or decades, electronic design automation (EDA) has been essential for developing integrated circuits. On the digital side, the focus has been on providing a design flow from a hardware description language (HDL) to a database that can be used for silicon production with associated verification steps. This has been applied to processor cores as well as to other types of logic blocks. Unlike other logic blocks, processor development must take care of a software toolchain such as compilers, assemblers, linkers, debuggers, and profilers. Traditionally the toolchain development has been handled quite separately from the core hardware design. One result has been that relatively few IP cores have been designed.
With the majority of systems on chip (SoCs) using off-the-shelf processor cores, processor design automation has been a fairly obscure niche within EDA. Tools have existed that would allow the development of both RTL and toolchains but there have been few groups that would take advantage of them or have the skills to use them.
Today, the semiconductor industry is facing an inflection point due to the end of ‘laws’ such as Dennard Scaling and Moore’s Law. There are, for example, practical limits to clock frequency due to the need to avoid thermal runaway. Although some very advanced process nodes exist, they are prohibitively expensive for most applications with costs per gate higher than older nodes such as 28 nm. New applications are requiring the efficient execution of algorithms for processing, audio, video or sensor data. With semiconductor scaling no longer being a choice in most situations the only way forward is architectural innovation. Hennessey and Patterson have described a class of programmable, domain-specific accelerators (DSAs) in their 2018 book1
. Such
accelerators are heterogeneous and highly specialised through being architected to match their software workload.
If a traditional design approach is used to 28 July/August 2022
Fig. 1 Different types of RISC-V instructions
create DSAs, most design groups would lack the skills to develop their own instruction sets and microarchitectures. However, the good news is that RISC-V is a game-changer with its open ISA. So why does RISC-V make such a difference?
Firstly, the RISC-V instruction set is free and open. One of the barriers to creating a special processor is creating an instruction set from scratch. The ISAs from leading commercial processor IP companies such as Arm, Cadence and Synopsys are not available to DSA designers without prohibitively expensive architectural licenses. RISC-V however, grants the designer architectural license rights to the ISA for no license fee.
Secondly, the RISC-V instruction set is modular, consisting of a base integer instruction set plus optional standardised extensions. If you create your own DSA, you can take the base integer set and combine it with those optional extensions that best meet the needs of your workload.
Thirdly, RISC-V allows custom non-standard extensions which can significantly contribute to increasing computational performance and to reducing code size with an acceptable overhead in silicon area.
Just as it is not necessary to develop a whole instruction set to develop a DSA, it is also unnecessary to develop all the microarchitecture. A more sensible approach is to take an existing RISC-V core
Components in Electronics
and to customise it to meet the needs of the software. The customisation effort is incremental to the original design work and requires less expertise.
There are many open-source RISC-V cores which are available and could be possible starting points for a specialised DSA design.
However, a challenge with many open-source cores is the lack of solid verification and support. If you modify a core’s instruction set, you need to reflect that in both hardware and software and verify both. A limitation is that open-source cores are almost universally described in an HDL.
Fig 2. Describing a processor with HDL provides no support for SW toolchain or verification. Using a processor description language such as CodAL supports all of them.
www.cieonline.co.uk
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76 |
Page 77 |
Page 78 |
Page 79 |
Page 80 |
Page 81 |
Page 82
