LIBRARY  |  COMPANIES |   PLATFORMS |   PROCESSORS |   PERIPHERALS
RiscvRV32FreeRTOS



OVP Virtual Platform: RiscvRV32FreeRTOS

This page provides detailed information about the OVP Virtual Platform Model of the imperas.ovpworld.org RiscvRV32FreeRTOS platform.

Licensing

Open Source Apache 2.0

Description

Example platform to instance RISCV RV32I processor core with extensions M and SU. Peripherals and memory address layout to boot pre-compiled FreeRTOS operating system.

Reference

https://github.com/RISCV-on-Microsemi-FPGA/FreeRTOS/tree/master/FreeRTOS_on_Mi-V_Processor

Limitations

Created to executed the specific software

Location

The RiscvRV32FreeRTOS virtual platform is located in an Imperas/OVP installation at the VLNV: imperas.ovpworld.org / module / RiscvRV32FreeRTOS / 1.0.

Platform Summary

Table : Components in platform

TypeInstanceVendorComponent
Processorcpu0riscv.ovpworld.orgriscvRVB32I
Peripheraluart0microsemi.ovpworld.orgCoreUARTapb
Peripheralplic0riscv.ovpworld.orgPLIC
Peripheralprci0riscv.ovpworld.orgCLINT
Memorynvramovpworld.orgram
Memoryddrovpworld.orgram
Busbus0(builtin)address width:32

Platform Simulation Attributes

Table 1: Platform Simulation Attributes

AttributeValueDescription
stoponctrlcstoponctrlcStop on control-C



Processor [riscv.ovpworld.org/processor/riscv/1.0] instance: cpu0

Processor model type: 'riscv' variant 'RVB32I' definition

Imperas OVP processor models support multiple variants and details of the variants implemented in this model can be found in:
- the Imperas installation located at ImperasLib/source/riscv.ovpworld.org/processor/riscv/1.0/doc
- the OVP website: OVP_Model_Specific_Information_riscv_RVB32I.pdf

Description

RISC-V RVB32I 32-bit processor model

Licensing

This Model is released under the Open Source Apache 2.0

Extensions Enabled by Default

The model has the following architectural extensions enabled, and the following bits in the misa CSR Extensions field will be set upon reset:
misa bit 8: RV32I/RV64I/RV128I base integer instruction set
To specify features that can be dynamically enabled or disabled by writes to the misa register in addition to those listed above, use parameter "add_Extensions_mask". This is a string parameter containing the feature letters to add; for example, value "DV" indicates that double-precision floating point and the Vector Extension can be enabled or disabled by writes to the misa register, if supported on this variant.
Legacy parameter "misa_Extensions_mask" can also be used. This Uns32-valued parameter specifies all writable bits in the misa Extensions field, replacing any permitted bits defined in the base variant.
Note that any features that are indicated as present in the misa mask but absent in the misa will be ignored. See the next section.

Available Extensions Not Enabled by Default

The following extensions are supported by the model, but not enabled by default in this variant:
misa bit 0: extension A (atomic instructions)
misa bit 1: extension B (bit manipulation extension)
misa bit 2: extension C (compressed instructions)
misa bit 3: extension D (double-precision floating point)
misa bit 4: RV32E base integer instruction set (embedded)
misa bit 5: extension F (single-precision floating point)
misa bit 7: extension H (hypervisor)
misa bit 10: extension K (cryptographic)
misa bit 12: extension M (integer multiply/divide instructions)
misa bit 13: extension N (user-level interrupts)
misa bit 18: extension S (Supervisor mode)
misa bit 20: extension U (User mode)
misa bit 21: extension V (vector extension)
misa bit 23: extension X (non-standard extensions present)
To add features from this list to the base variant, use parameter "add_Extensions". This is a string parameter containing the feature letters to add; for example, value "DV" indicates that double-precision floating point and the Vector Extension should be enabled, if they are currently absent and are available on this variant.
Legacy parameter "misa_Extensions" can also be used. This Uns32-valued parameter specifies the reset value for the misa CSR Extensions field, replacing any permitted bits defined in the base variant.

General Features

On this variant, the Machine trap-vector base-address register (mtvec) is writable. It can instead be configured as read-only using parameter "mtvec_is_ro".
Values written to "mtvec" are masked using the value 0xfffffffd. A different mask of writable bits may be specified using parameter "mtvec_mask" if required. In addition, when Vectored interrupt mode is enabled, parameter "tvec_align" may be used to specify additional hardware-enforced base address alignment. In this variant, "tvec_align" defaults to 0, implying no alignment constraint.
The initial value of "mtvec" is 0x0. A different value may be specified using parameter "mtvec" if required.
On reset, the model will restart at address 0x0. A different reset address may be specified using parameter "reset_address" or applied using optional input port "reset_addr" if required.
On an NMI, the model will restart at address 0x0. A different NMI address may be specified using parameter "nmi_address" or applied using optional input port "nmi_addr" if required.
WFI will halt the processor until an interrupt occurs. It can instead be configured as a NOP using parameter "wfi_is_nop". WFI timeout wait is implemented with a time limit of 0 (i.e. WFI causes an Illegal Instruction trap in Supervisor mode when mstatus.TW=1).
The "cycle" CSR is implemented in this variant. Set parameter "cycle_undefined" to True to instead specify that "cycle" is unimplemented and reads of it should trap to Machine mode.
The "time" CSR is implemented in this variant. Set parameter "time_undefined" to True to instead specify that "time" is unimplemented and reads of it should trap to Machine mode. Usually, the value of the "time" CSR should be provided by the platform - see notes below about the artifact "CSR" bus for information about how this is done.
The "instret" CSR is implemented in this variant. Set parameter "instret_undefined" to True to instead specify that "instret" is unimplemented and reads of it should trap to Machine mode.
Unaligned memory accesses are not supported by this variant. Set parameter "unaligned" to "T" to enable such accesses.
A PMP unit is not implemented by this variant. Set parameter "PMP_registers" to indicate that the unit should be implemented with that number of PMP entries.

CLIC

The model can be configured to implement a Core Local Interrupt Controller (CLIC) using parameter "CLICLEVELS"; when non-zero, the CLIC is present with the specified number of interrupt levels (2-256), as described in the RISC-V Core-Local Interrupt Controller specification, and further parameters are made available to configure other aspects of the CLIC. "CLICLEVELS" is zero in this variant, indicating that a CLIC is not implemented.

Interrupts

The "reset" port is an active-high reset input. The processor is halted when "reset" goes high and resumes execution from the reset address specified using the "reset_address" parameter or "reset_addr" port when the signal goes low. The "mcause" register is cleared to zero.
The "nmi" port is an active-high NMI input. The processor resumes execution from the address specified using the "nmi_address" parameter or "nmi_addr" port when the NMI signal goes high. The "mcause" register is cleared to zero.
All other interrupt ports are active high. For each implemented privileged execution level, there are by default input ports for software interrupt, timer interrupt and external interrupt; for example, for Machine mode, these are called "MSWInterrupt", "MTimerInterrupt" and "MExternalInterrupt", respectively. When the N extension is implemented, ports are also present for User mode. Parameter "unimp_int_mask" allows the default behavior to be changed to exclude certain interrupt ports. The parameter value is a mask in the same format as the "mip" CSR; any interrupt corresponding to a non-zero bit in this mask will be removed from the processor and read as zero in "mip", "mie" and "mideleg" CSRs (and Supervisor and User mode equivalents if implemented).
Parameter "external_int_id" can be used to enable extra interrupt ID input ports on each hart. If the parameter is True then when an external interrupt is applied the value on the ID port is sampled and used to fill the Exception Code field in the "mcause" CSR (or the equivalent CSR for other execution levels). For Machine mode, the extra interrupt ID port is called "MExternalInterruptID".
The "deferint" port is an active-high artifact input that, when written to 1, prevents any pending-and-enabled interrupt being taken (normally, such an interrupt would be taken on the next instruction after it becomes pending-and-enabled). The purpose of this signal is to enable alignment with hardware models in step-and-compare usage.

Debug Mode

The model can be configured to implement Debug mode using parameter "debug_mode". This implements features described in Chapter 4 of the RISC-V External Debug Support specification with version specified by parameter "debug_version" (see References). Some aspects of this mode are not defined in the specification because they are implementation-specific; the model provides infrastructure to allow implementation of a Debug Module using a custom harness. Features added are described below.
Parameter "debug_mode" can be used to specify three different behaviors, as follows:
1. If set to value "vector", then operations that would cause entry to Debug mode result in the processor jumping to the address specified by the "debug_address" parameter. It will execute at this address, in Debug mode, until a "dret" instruction causes return to non-Debug mode. Any exception generated during this execution will cause a jump to the address specified by the "dexc_address" parameter.
2. If set to value "interrupt", then operations that would cause entry to Debug mode result in the processor simulation call (e.g. opProcessorSimulate) returning, with a stop reason of OP_SR_INTERRUPT. In this usage scenario, the Debug Module is implemented in the simulation harness.
3. If set to value "halt", then operations that would cause entry to Debug mode result in the processor halting. Depending on the simulation environment, this might cause a return from the simulation call with a stop reason of OP_SR_HALT, or debug mode might be implemented by another platform component which then restarts the debugged processor again.

Debug State Entry

The specification does not define how Debug mode is implemented. In this model, Debug mode is enabled by a Boolean pseudo-register, "DM". When "DM" is True, the processor is in Debug mode. When "DM" is False, mode is defined by "mstatus" in the usual way.
Entry to Debug mode can be performed in any of these ways:
1. By writing True to register "DM" (e.g. using opProcessorRegWrite) followed by simulation of at least one cycle (e.g. using opProcessorSimulate), dcsr cause will be reported as trigger;
2. By writing a 1 then 0 to net "haltreq" (using opNetWrite) followed by simulation of at least one cycle (e.g. using opProcessorSimulate);
3. By writing a 1 to net "resethaltreq" (using opNetWrite) while the "reset" signal undergoes a negedge transition, followed by simulation of at least one cycle (e.g. using opProcessorSimulate);
4. By executing an "ebreak" instruction when Debug mode entry for the current processor mode is enabled by dcsr.ebreakm, dcsr.ebreaks or dcsr.ebreaku.
In all cases, the processor will save required state in "dpc" and "dcsr" and then perform actions described above, depending in the value of the "debug_mode" parameter.

Debug State Exit

Exit from Debug mode can be performed in any of these ways:
1. By writing False to register "DM" (e.g. using opProcessorRegWrite) followed by simulation of at least one cycle (e.g. using opProcessorSimulate);
2. By executing an "dret" instruction when Debug mode.
In both cases, the processor will perform the steps described in section 4.6 (Resume) of the Debug specification.

Debug Registers

When Debug mode is enabled, registers "dcsr", "dpc", "dscratch0" and "dscratch1" are implemented as described in the specification. These may be manipulated externally by a Debug Module using opProcessorRegRead or opProcessorRegWrite; for example, the Debug Module could write "dcsr" to enable "ebreak" instruction behavior as described above, or read and write "dpc" to emulate stepping over an "ebreak" instruction prior to resumption from Debug mode.

Debug Mode Execution

The specification allows execution of code fragments in Debug mode. A Debug Module implementation can cause execution in Debug mode by the following steps:
1. Write the address of a Program Buffer to the program counter using opProcessorPCSet;
2. If "debug_mode" is set to "halt", write 0 to pseudo-register "DMStall" (to leave halted state);
3. If entry to Debug mode was handled by exiting the simulation callback, call opProcessorSimulate or opRootModuleSimulate to resume simulation.
Debug mode will be re-entered in these cases:
1. By execution of an "ebreak" instruction; or:
2. By execution of an instruction that causes an exception.
In both cases, the processor will either jump to the debug exception address, or return control immediately to the harness, with stopReason of OP_SR_INTERRUPT, or perform a halt, depending on the value of the "debug_mode" parameter.

Debug Single Step

When in Debug mode, the processor or harness can cause a single instruction to be executed on return from that mode by setting dcsr.step. After one non-Debug-mode instruction has been executed, control will be returned to the harness. The processor will remain in single-step mode until dcsr.step is cleared.

Debug Ports

Port "DM" is an output signal that indicates whether the processor is in Debug mode
Port "haltreq" is a rising-edge-triggered signal that triggers entry to Debug mode (see above).
Port "resethaltreq" is a level-sensitive signal that triggers entry to Debug mode after reset (see above).

Trigger Module

This model is configured with a trigger module, implementing a subset of the behavior described in Chapter 5 of the RISC-V External Debug Support specification with version specified by parameter "debug_version" (see References).

Trigger Module Restrictions

The model currently supports tdata1 of type 0, type 2 (mcontrol), type 3 (icount), type 4 (itrigger), type 5 (etrigger) and type 6 (mcontrol6). icount triggers are implemented for a single instruction only, with count hard-wired to 1 and automatic zeroing of mode bits when the trigger fires.

Trigger Module Parameters

Parameter "trigger_num" is used to specify the number of implemented triggers. In this variant, "trigger_num" is 4.
Parameter "tinfo" is used to specify the value of the read-only "tinfo" register, which indicates the trigger types supported. In this variant, "tinfo" is 0x7d.
Parameter "tinfo_undefined" is used to specify whether the "tinfo" register is undefined, in which case reads of it trap to Machine mode. In this variant, "tinfo_undefined" is 0.
Parameter "tcontrol_undefined" is used to specify whether the "tcontrol" register is undefined, in which case accesses to it trap to Machine mode. In this variant, "tcontrol_undefined" is 0.
Parameter "mcontext_undefined" is used to specify whether the "mcontext" register is undefined, in which case accesses to it trap to Machine mode. In this variant, "mcontext_undefined" is 0.
Parameter "scontext_undefined" is used to specify whether the "scontext" register is undefined, in which case accesses to it trap to Machine mode. In this variant, "scontext_undefined" is 0.
Parameter "mscontext_undefined" is used to specify whether the "mscontext" register is undefined, in which case accesses to it trap to Machine mode. In this variant, "mscontext_undefined" is 0.
Parameter "amo_trigger" is used to specify whether load/store triggers are activated for AMO instructions. In this variant, "amo_trigger" is 0.
Parameter "no_hit" is used to specify whether the "hit" bit in tdata1 is unimplemented. In this variant, "no_hit" is 0.
Parameter "mcontext_bits" is used to specify the number of writable bits in the "mcontext" register. In this variant, "mcontext_bits" is 6.
Parameter "mvalue_bits" is used to specify the number of writable bits in the "mvalue" field in "textra32"/"textra64" registers; if zero, the "mselect" field is tied to zero. In this variant, "mvalue_bits" is 6.
Parameter "mcontrol_maskmax" is used to specify the value of field "maskmax" in the "mcontrol" register. In this variant, "mcontrol_maskmax" is 63.

Debug Mask

It is possible to enable model debug messages in various categories. This can be done statically using the "override_debugMask" parameter, or dynamically using the "debugflags" command. Enabled messages are specified using a bitmask value, as follows:
Value 0x002: enable debugging of PMP and virtual memory state;
Value 0x004: enable debugging of interrupt state.
All other bits in the debug bitmask are reserved and must not be set to non-zero values.

Integration Support

This model implements a number of non-architectural pseudo-registers and other features to facilitate integration.

CSR Register External Implementation

If parameter "enable_CSR_bus" is True, an artifact 16-bit bus "CSR" is enabled. Slave callbacks installed on this bus can be used to implement modified CSR behavior (use opBusSlaveNew or icmMapExternalMemory, depending on the client API). A CSR with index 0xABC is mapped on the bus at address 0xABC0; as a concrete example, implementing CSR "time" (number 0xC01) externally requires installation of callbacks at address 0xC010 on the CSR bus.

Limitations

Instruction pipelines are not modeled in any way. All instructions are assumed to complete immediately. This means that instruction barrier instructions (e.g. fence.i) are treated as NOPs, with the exception of any Illegal Instruction behavior, which is modeled.
Caches and write buffers are not modeled in any way. All loads, fetches and stores complete immediately and in order, and are fully synchronous. Data barrier instructions (e.g. fence) are treated as NOPs, with the exception of any Illegal Instruction behavior, which is modeled.
Real-world timing effects are not modeled: all instructions are assumed to complete in a single cycle.
Hardware Performance Monitor registers are not implemented and hardwired to zero.

Verification

All instructions have been extensively tested by Imperas, using tests generated specifically for this model and also reference tests from https://github.com/riscv/riscv-tests.
Also reference tests have been used from various sources including:
https://github.com/riscv/riscv-tests
https://github.com/ucb-bar/riscv-torture
The Imperas OVPsim RISC-V models are used in the RISC-V Foundation Compliance Framework as a functional Golden Reference:
https://github.com/riscv/riscv-compliance
where the simulated model is used to provide the reference signatures for compliance testing. The Imperas OVPsim RISC-V models are used as reference in both open source and commercial instruction stream test generators for hardware design verification, for example:
http://valtrix.in/sting from Valtrix
https://github.com/google/riscv-dv from Google
The Imperas OVPsim RISC-V models are also used by commercial and open source RISC-V Core RTL developers as a reference to ensure correct functionality of their IP.

References

The Model details are based upon the following specifications:
RISC-V Instruction Set Manual, Volume I: User-Level ISA (User Architecture Version 20190305-Base-Ratification)
RISC-V Instruction Set Manual, Volume II: Privileged Architecture (Privileged Architecture Version 20190405-Priv-MSU-Ratification)

Instance Parameters

Several parameters can be specified when a processor is instanced in a platform. For this processor instance 'cpu0' it has been instanced with the following parameters:

Table 2: Processor Instance 'cpu0' Parameters (Configurations)

ParameterValueDescription
simulateexceptionssimulateexceptionsCauses the processor simulate exceptions instead of halting
mips50The nominal MIPS for the processor

Table 3: Processor Instance 'cpu0' Parameters (Attributes)

Parameter NameValueType
variantRVB32Ienum
add_ExtensionsMSUstring

Memory Map for processor 'cpu0' bus: 'bus0'

Processor instance 'cpu0' is connected to bus 'bus0' using master port 'INSTRUCTION'.

Processor instance 'cpu0' is connected to bus 'bus0' using master port 'DATA'.

Table 4: Memory Map ( 'cpu0' / 'bus0' [width: 32] )

Lo AddressHi AddressInstanceComponent
0x400000000x43FFFFFFplic0PLIC
0x440000000x4400BFFFprci0CLINT
0x600000000x6003FFFFnvramram
0x700010000x70001017uart0CoreUARTapb
0x800000000x8FFFFFFFddrram

Net Connections to processor: 'cpu0'

Table 5: Processor Net Connections ( 'cpu0' )

Net PortNetInstanceComponent
MExternalInterrupteipplic0PLIC
MTimerInterruptMTimerInterruptprci0CLINT
MSWInterruptMSWInterruptprci0CLINT



Peripheral Instances



Peripheral [microsemi.ovpworld.org/peripheral/CoreUARTapb/1.0] instance: uart0

Licensing

Open Source Apache 2.0

Description

Microsemi CoreUARTapb

Limitations

Basic functionality for transmit and receive

Reference

CoreUARTapb handbook v5.2 https://www.microsemi.com/document-portal/doc_view/130958-coreuartapb-handbook

There are no configuration options set for this peripheral instance.



Peripheral [riscv.ovpworld.org/peripheral/PLIC/1.0] instance: plic0

Licensing

Open Source Apache 2.0

Limitations

None

Description

PLIC Interrupt Controller
Use parameters to configure specific implementation.
Default model is based on SiFive PLIC implementation details - other variations are available (e.g. Andes NCEPLIC100).

Reference

The RISC-V Instruction Set Manual Volume II: Privileged Architecture Version 1.10 (https://riscv.org/specifications/privileged-isa)
SiFive Freedom U540-C000 Manual FU540-C000-v1.0.pdf (https://www.sifive.com/documentation/chips/freedom-u540-c000-manual)

Table 6: Configuration options (attributes) set for instance 'plic0'

AttributesValue
num_sources256
num_targets1



Peripheral [riscv.ovpworld.org/peripheral/CLINT/1.0] instance: prci0

Licensing

Open Source Apache 2.0

Description

Risc-V Core Local Interruptor (CLINT). Use the num_harts parameter to specify the number of harts suported (default 1). For each supported hart there will be an MTimerInterruptN and MSWInterruptN net port, plus msipN and mtimecmpN registers implemented, where N is a value from 0..num_harts-1 There is also a single mtime register.

Limitations

Writes to mtime register are not supported

Reference

SiFive Freedom U540-C000 Manual FU540-C000-v1.0.pdf (https://www.sifive.com/documentation/chips/freedom-u540-c000-manual)

Table 7: Configuration options (attributes) set for instance 'prci0'

AttributesValue
clockMHz1.0



ImperasPlatforms RiscVplatforms
Page was generated in 0.0327 seconds