Startseite > International > From the basics to the prototype

Design Practice RISC-V

From the basics to the prototype

10. März 2019, 19:51 Uhr | Dr. Constantin Tomaras, DESIGN&ELEKTRONIK

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

I. Behaviour in the environment

The Privileged Specification [2] describes a model for the processor in a software or hardware environment. In the software stack model, an application accesses the binary interface (ABI) with the ISA, under which an additional execution layer (AEE) is located. The execution layer is invisible to the application. It can be replaced with an operating system that integrates its own binary interface (SBI) and execution layer (SEE). Different applications can be based on this simultaneously. The execution layer of the operating system can be replaced by a hypervisor, which in turn has its own binary interface (HBI) and execution layer (HEE). Different execution environments can then be simultaneously set up on the HBI.

A RISC-V core has several harts, i.e. hardware-defined call chains (threads*) with their own address space and command pointer. A call chain works with fixed access rights, either at application level (U), in the execution environment (S) or at machine level (M). In the future, the hypervisor level (H) will also be specified. If an exception transfers the system to a trap state, the execution is continued from there, usually at a higher access level (vertical trap). If the trap remains on the same hierarchy level, it is called horizontal trap. Each level has its own valid instruction sets.

The debug mode [6] can be considered as an execution mode with access rights above the machine level. It uses some special CSR registers and physical space on the chip. However, the specification of the debug interface is still at an early stage.

In total, the RISC-V ISA provides a 12-bit field, i.e. 4096 possible CSR entries. The highest bits of an entry code the access type and level. Apart from the timers, the standard does not yet know any other CSR shadow registers.

Some M-CSR and Commands

The machine mode has access to the entire CSR. Here you can, for example set the ISA support of a hart, the JEDEC manufacturer can be viewed, a micro architecture and processor implementation can be read, a hart-ID can be read, the execution status of a hart can be set or read, interrupts can be activated with access rights, the length of the standard register can be set on different execution levels, write and save operations are regulated, virtualization allowed or restricted, extensions managed, a trap defined, the threshold level for exceptions and traps set, interrupt status read, a real-time clock read, hardware performance evaluated, and the cause of a trap or exception read.

M-Mode specific commands can trigger an exception from the environment, trigger a breakpoint, continue execution from a trap, or wait for an interrupt event.

Only part of the M-Mode CSRs are accessible to the S-level, including ABE status, ISA properties, interrupts and timers, exception, trap and address offset.

In addition, the virtual memory model for the execution environment is established. The satp register contains the physical page number and the translation mode, for RV32 an address space > 4 GiB is supported. For RV64 further methods for memory virtualization are planned (Sv39, Sv48, Sv57 and Sv64).

The implemented page length affects the performance, Sv32 and Sv64 are executed with 4 KiB by default, so the navigation (TLB) between the pages can be done in hardware. The virtual page address measures 20 bits and can be translated into a physical page address of 22 bits. The page entry contains the physical page address, along with a number of access declarations.

At the physical level, RISC-V only specifies a highly relaxed memory model, which needs to be formulated even more clearly from the point of view of high-level languages. A type R command provides for the synchronization of different harts, or one hart with I/O-s [1]. A corresponding sfence command synchronizes virtual memory constructs in the execution environment.