Custom graphics extensions boost RISC-V

Custom graphics extensions boost RISC-V

Technology News |
By Nick Flaherty

Pixilica in the US has worked with the RV64X to propose a new set of graphics instructions designed for 3D graphics and media processing in a fused CPU-GPU ISA, creating an open source reference implementation for FPGAs.

The RV64X Reference Implementation includes an Instruction/Data SRAM Cache (32KB), a Microcode SRAM(8KB), a Dual Function Instruction Decoder, an Hardwired implementing RV32V and X, a Micro-coded Instruction Decoder for custom ISA, a Quad Vector ALU (32 bits/ALU – fixed/float), a 136-bit Register Files (1K elements), a Special Function Unit, a Texture Unit, and a Configurable local Frame Buffer.

​The implementation is designed to be flexible enough so that it can implement custom pipeline stages, custom geometry/pixel/frame buffer stages, custom tessellators, and custom instancing operations. This implementation is optimized to be small and area-efficient with custom programmability and extensibility.

This is one of the strengths of the RISC-V eco-system, says Roddy Urquhart, senior marketing director at Europena tool developer Codasip.

“The RV64X GPU is a fantastic win for the R5 ecosystem,” he said. “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,” said Roddy Urqhart at Codasip

“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 an excellent starting point and a software ecosystem,” he said.

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.

He points to the base ISA of RISC-V (RV32I) with 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.

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 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 and once such hotspots are known, a designer can create custom instructions to address them,” he said.

This allows designers to iterate by experimenting with adding or deleting instructions, then profiling the software again and assessing whether the changes have achieved their objectives. This could be done in 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,” said Urquhart.

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

Related RISC-V articles 

Other articles on eeNews Europe


If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News


Linked Articles