Model Information

This page provides detailed information about the OVP Fast Processor Model of the RISC-V rv32f (RV32G) core.
This page is information about the RV32F alias of the RV32G variant.
Processor IP owner is RISC-V Foundation.

OVP Fast Processor Model is written in C.
Provides a C API for use in C based platforms.
Provides a native C++ interface for use in SystemC TLM2 platforms.

The model is written using the OVP VMI API that provides a Virtual Machine Interface that defines the behavior of the processor.
The VMI API makes a clear line between model and simulator allowing very good optimization and world class high speed performance.

The model is provided as a binary shared object and is also available as source (different models have different licensing conditions). This allows the download and use of the model binary or the use of the source to explore and modify the model.

The model has been run through an extensive QA and regression testing process.

Parallel Simulation using Imperas QuantumLeap
Traditionally, processor models and simulators make use of one thread on the host PC. Imperas have developed a technology, called QuantumLeap, that makes use of the many host cores found in modern PC/workstations to achieve industry leading simulation performance. To find out about the Imperas parallel simulation lookup Imperas QuantumLeap. There are videos of QuantumLeap on ARM here, and MIPS here. For press information related to QuantumLeap for ARM click here or for MIPS click here.
Many of the OVP Fast Processor Models have been qualified to work with QuantumLeap - this is indicated for this model below.

Embedded Software Development tools
This model executes instructions of the target architecture and provides an interface for debug access. An interface to GDB is provided and this allows the connection of many industry standard debuggers that use the GDB/RSP interface. For more information watch the OVP video here.
The model also works with the Imperas Multicore Debugger and advanced Verification, Analysis and Profiling tools.

Instruction Set Simulator (ISS) for RISC-V rv32f (RV32G)
An ISS is a software development tool that takes in instructions for a target processor and executes them. The heart of an ISS is the model of the processor. Imperas has developed a range of ISS products for use in embedded software development that utilize this fast Fast Processor Model. The Imperas RISC-V rv32f (RV32G) ISS runs on Windows/Linux x86 systems and takes a cross compiled elf file of your program and allows very fast execution. The RISC-V rv32f (RV32G) ISS also provides access to standard GDB/RSP debuggers and connects to the Eclipse IDE and Imperas debuggers.

Overview of RISC-V rv32f (RV32G) Fast Processor Model
Model Variant name: rv32f (RV32G)
Description:
    RISC-V RV32G 32-bit processor model
Licensing:
    This Model is released under the Open Source Apache 2.0
Extensions:
    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 0: extension A (atomic instructions)
    misa bit 3: extension D (double-precision floating point)
    misa bit 5: extension F (single-precision floating point)
    misa bit 8: RV32I/64I/128I base ISA
    misa bit 12: extension M (integer multiply/divide instructions)
    misa bit 18: extension S (Supervisor mode)
    misa bit 20: extension U (User mode)
    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.
    Legacy parameter "misa_Extensions_mask" can also be used. This Uns32-valued parameter specifies all writable bits in the misa Extensions field, replacing any value 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.
    Legacy parameter "misa_Extensions" can also be used. This Uns32-valued parameter specifies the reset value for the misa CSR Extensions field, replacing any value defined in the base variant.
Available (But Not Enabled) Extensions:
    The following extensions are supported by the model, but not enabled by default in this variant:
    misa bit 1: extension B (bit manipulation extension) (NOT ENABLED)
    misa bit 2: extension C (compressed instructions) (NOT ENABLED)
    misa bit 4: RV32E base ISA (NOT ENABLED)
    misa bit 13: extension N (user-level interrupts) (NOT ENABLED)
    misa bit 21: extension V (vector extension) (NOT ENABLED)
    misa bit 23: extension X (non-standard extensions present) (NOT ENABLED)
    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 absent.
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.
    Values written to "stvec" are masked using the value 0xfffffffd. A different mask of writable bits may be specified using parameter "stvec_mask" if required. parameter "tvec_align" may be used to specify additional hardware-enforced base address alignment in the same manner as for the "mtvec" register, described above.
    On reset, the model will restart at address 0x0. A different reset address may be specified using parameter "reset_address" if required.
    On an NMI, the model will restart at address 0x0. A different NMI address may be specified using parameter "nmi_address" 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.
    A 9-bit ASID is implemented. Use parameter "ASID_bits" to specify a different implemented ASID size if required.
    This variant supports address translation modes 0 and 1. Use parameter "Sv_modes" to specify a bit mask of different modes if required.
    Unaligned memory accesses are not supported by this variant. Set parameter "unaligned" to "T" to enable such accesses.
    Unaligned memory accesses are not supported for AMO instructions by this variant. Set parameter "unalignedAMO" to "T" to enable such accesses.
    16 PMP entries are implemented by this variant. Use parameter "PMP_registers" to specify a different number of PMP entries; set the parameter to 0 to disable the PMP unit. The PMP grain size (G) is 0, meaning that PMP regions as small as 4 bytes are implemented. Use parameter "PMP_grain" to specify a different grain size if required.
    LR/SC instructions are implemented with a 1-byte reservation granule. A different granule size may be specified using parameter "lr_sc_grain".
Floating Point Features:
    The D extension is enabled in this variant independently of the F extension. Set parameter "d_requires_f"to "T" to specify that the D extension requires the F extension to be enabled.
    By default, the processor starts with floating-point instructions disabled (mstatus.FS=0). Use parameter "mstatus_FS" to force mstatus.FS to a non-zero value for floating-point to be enabled from the start.
    The specification is imprecise regarding the conditions under which mstatus.FS is set to Dirty state (3). Parameter "mstatus_fs_mode" can be used to specify the required behavior in this model, as described below.
    If "mstatus_fs_mode" is set to "always_dirty" then the model implements a simplified floating point status view in which mstatus.FS holds values 0 (Off) and 3 (Dirty) only; any write of values 1 (Initial) or 2 (Clean) from privileged code behave as if value 3 was written.
    If "mstatus_fs_mode" is set to "write_1" then mstatus.FS will be set to 3 (Dirty) by any explicit write to the fflags, frm or fcsr control registers, or by any executed instruction that writes an FPR, or by any executed floating point compare or conversion to integer/unsigned that signals a floating point exception. Floating point compare or conversion to integer/unsigned instructions that do not signal an exception will not set mstatus.FS.
    If "mstatus_fs_mode" is set to "write_any" then mstatus.FS will be set to 3 (Dirty) by any explicit write to the fflags, frm or fcsr control registers, or by any executed instruction that writes an FPR, or by any executed floating point compare or conversion even if those instructions do not signal a floating point exception.
    In this variant, "mstatus_fs_mode" is set to "write_1".
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 (see references). When "CLICLEVELS" is non-zero, further parameters are made available to configure other aspects of the CLIC, as described below.
    The model can configured either to use an internal CLIC model (if parameter "externalCLIC" is False) or to present a net interface to allow the CLIC to be implemented externally in a platform component (if parameter "externalCLIC" is True). When the CLIC is implemented internally, net ports for standard interrupts and additional local interrupts are available. When the CLIC is implemented externally, a net port interface allowing the highest-priority pending interrupt to be delivered is instead present. This is described below.
CLIC Common Parameters:
    This section describes parameters applicable whether the CLIC is implemented internally or externally. These are:
    "CLICANDBASIC": this Boolean parameter indicates whether both CLIC and basic interrupt controller are present (if True) or whether only the CLIC is present (if False).
    "CLICXNXTI": this Boolean parameter indicates whether xnxti CSRs are implemented (if True) or unimplemented (if False).
    "CLICXCSW": this Boolean parameter indicates whether xscratchcsw and xscratchcswl CSRs registers are implemented (if True) or unimplemented (if False).
    "mclicbase": this parameter specifies the CLIC base address in physical memory.
    "tvt_undefined": this Boolean parameter indicates whether xtvt CSRs registers are implemented (if True) or unimplemented (if False). If the registers are unimplemented then the model will use basic mode vectored interrupt semantics based on the xtvec CSRs instead of Selective Hardware Vectoring semantics described in the specification.
    "intthresh_undefined": this Boolean parameter indicates whether xintthresh CSRs registers are implemented (if True) or unimplemented (if False).
    "mclicbase_undefined": this Boolean parameter indicates whether the mclicbase CSR register is implemented (if True) or unimplemented (if False).
CLIC Internal-Implementation Parameters:
    This section describes parameters applicable only when the CLIC is implemented internally. These are:
    "CLICCFGMBITS": this Uns32 parameter indicates the number of bits implemented in cliccfg.nmbits, and also indirectly defines CLICPRIVMODES. For cores which implement only Machine mode, or which implement Machine and User modes but not the N extension, the parameter is absent ("CLICCFGMBITS" must be zero in these cases).
    "CLICCFGLBITS": this Uns32 parameter indicates the number of bits implemented in cliccfg.nlbits.
    "CLICSELHVEC": this Boolean parameter indicates whether Selective Hardware Vectoring is supported (if True) or unsupported (if False).
CLIC External-Implementation Net Port Interface:
    When the CLIC is externally implemented, net ports are present allowing the external CLIC model to supply the highest-priority pending interrupt and to be notified when interrupts are handled. These are:
    "irq_id_i": this input should be written with the id of the highest-priority pending interrupt.
    "irq_lev_i": this input should be written with the highest-priority interrupt level.
    "irq_sec_i": this 2-bit input should be written with the highest-priority interrupt security state (00:User, 01:Supervisor, 11:Machine).
    "irq_shv_i": this input port should be written to indicate whether the highest-priority interrupt should be direct (0) or vectored (1). If the "tvt_undefined parameter" is False, vectored interrupts will use selective hardware vectoring, as described in the CLIC specification. If "tvt_undefined" is True, vectored interrupts will behave like basic mode vectored interrupts.
    "irq_id_i": this input should be written with the id of the highest-priority pending interrupt.
    "irq_i": this input should be written with 1 to indicate that the external CLIC is presenting an interrupt, or 0 if no interrupt is being presented.
    "irq_ack_o": this output is written by the model on entry to the interrupt handler (i.e. when the interrupt is taken). It will be written as an instantaneous pulse (i.e. written to 1, then immediately 0).
    "irq_id_o": this output is written by the model with the id of the interrupt currently being handled. It is valid during the instantaneous irq_ack_o pulse.
    "sec_lvl_o": this output signal indicates the current secure status of the processor, as a 2-bit value (00=User, 01:Supervisor, 11=Machine).
Load-Reserved/Store-Conditional Locking:
    By default, LR/SC locking is implemented automatically by the model and simulator, with a reservation granule defined by the "lr_sc_grain" parameter. It is also possible to implement locking externally to the model in a platform component, using the "LR_address", "SC_address" and "SC_valid" net ports, as described below.
    The "LR_address" output net port is written by the model with the address used by a load-reserved instruction as it executes. This port should be connected as an input to the external lock management component, which should record the address, and also that an LR/SC transaction is active.
    The "SC_address" output net port is written by the model with the address used by a store-conditional instruction as it executes. This should be connected as an input to the external lock management component, which should compare the address with the previously-recorded load-reserved address, and determine from this (and other implementation-specific constraints) whether the store should succeed. It should then immediately write the Boolean success/fail code to the "SC_valid" input net port of the model. Finally, it should update state to indicate that an LR/SC transaction is no longer active.
    It is also possible to write zero to the "SC_valid" input net port at any time outside the context of a store-conditional instruction, which will mark any active LR/SC transaction as invalid.
    Irrespective of whether LR/SC locking is implemented internally or externally, taking any exception or interrupt or executing exception-return instructions (e.g. MRET) will always mark any active LR/SC transaction as invalid.
Active Atomic Operation Indication:
    The "AMO_active" output net port is written by the model with a code indicating any current atomic memory operation while the instruction is active. The written codes are:
    0: no atomic instruction active
    1: AMOMIN active
    2: AMOMAX active
    3: AMOMINU active
    4: AMOMAXU active
    5: AMOADD active
    6: AMOXOR active
    7: AMOOR active
    8: AMOAND active
    9: AMOSWAP active
    10: LR active
    11: SC active
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 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 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 (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);
    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).
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.
LR/SC Active Address:
    Artifact register "LRSCAddress" shows the active LR/SC lock address. The register holds all-ones if there is no LR/SC operation active or if LR/SC locking is implemented externally as described above.
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.
    The processor fully supports the architecturally-specified floating-point instructions.
    Hardware Performance Monitor and Debug registers are not implemented and hardwired to zero.
    The TLB is architecturally-accurate but not device accurate. This means that all TLB maintenance and address translation operations are fully implemented but the cache is larger than in the real device.
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 Foundations 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)
    RISC-V Core-Local Interrupt Controller (CLIC) Version 0.9-draft-20191208
    RISC-V External Debug Support Version 0.14.0-DRAFT

Model downloadable (needs registration and to be logged in) in package riscv.model for Windows32 and for Linux32. Note that the Model is also available for 64 bit hosts as part of the commercial products from Imperas.
OVP simulator downloadable (needs registration and to be logged in) in package OVPsim for Windows32 and for Linux32. Note that the simulator is also available for 64 bit hosts as part of the commercial products from Imperas.
OVP Download page here.
OVP documentation that provides overview information on processor models is available OVP_Guide_To_Using_Processor_Models.pdf.

Full model specific documentation on the variant rv32f (RV32G) is available OVP_Model_Specific_Information_riscv_RV32G.pdf.

Configuration
Location: The Fast Processor Model source and object file is found in the installation VLNV tree: riscv.ovpworld.org/processor/riscv/1.0
Processor Endian-ness: This model can be set to either endian-ness (normally by a pin, or the ELF code).
Processor ELF Code: The ELF code for this model is: 0xf3
QuantumLeap Support: The processor model is qualified to run in a QuantumLeap enabled simulator.

TLM Initiator Ports (Bus Ports)
Port TypeNameWidth (bits)Description
masterINSTRUCTION32
masterDATA32
SystemC Signal Ports (Net Ports)
Port TypeNameDescription
resetinput
nmiinput
SSWInterruptinput
MSWInterruptinput
STimerInterruptinput
MTimerInterruptinput
SExternalInterruptinput
MExternalInterruptinput
irq_ack_ooutput
irq_id_ooutput
sec_lvl_ooutput
LR_addressoutput
SC_addressoutput
SC_validinput
AMO_activeoutput
deferintinput

No FIFO Ports in RV32F.

Exceptions
NameCodeDescription
InstructionAddressMisaligned0
InstructionAccessFault1
IllegalInstruction2
Breakpoint3
LoadAddressMisaligned4
LoadAccessFault5
StoreAMOAddressMisaligned6
StoreAMOAccessFault7
EnvironmentCallFromUMode8
EnvironmentCallFromSMode9
EnvironmentCallFromMMode11
InstructionPageFault12
LoadPageFault13
StoreAMOPageFault15
SSWInterrupt65
MSWInterrupt67
STimerInterrupt69
MTimerInterrupt71
SExternalInterrupt73
MExternalInterrupt75
Execution Modes
ModeCodeDescription
User0
Supervisor1
Machine3
More Detailed Information

The RV32F OVP Fast Processor Model also has parameters, model commands, and many registers.
The model may also have hierarchy or be multicore and have other attributes and capabilities.
To see this information, please have a look at the model variant specific documents.
Click here to see the detailed document OVP_Model_Specific_Information_riscv_RV32G.pdf.

Other Sites/Pages with similar information

Information on the RV32F OVP Fast Processor Model can also be found on other web sites::
www.ovpworld.org has the library pages http://www.ovpworld.org/library/wikka.php?wakka=CategoryProcessor
www.imperas.com has more information on the model library

A couple of documents (from other related sites that might be of interest)
http://www.ovpworld.org: iGen Model Generator Introduction
http://www.ovpworld.org: VMI Morph Time (VMI MT) API Reference Guide

Two Videos on these models (from other sites)
http://www.ovpworld.org: ARM Bare Metal Demos Video Presentation
http://www.ovpworld.org: RISC-V Bare Metal Demos Video Presentation


Currently available Fast Processor Model Families.

FamilyModel Variant
RISC-V Models    RISC-V Models aliases RV32I RV32IM RV32IMC RV32IMAC RV32G RV32GC RV32GCN RV32E RV32EC RV64I RV64IM RV64IMC RV64IMAC RV64G RV64GC RV64GCN (aliases)
MIPS Models    MIPS Models aliases ISA M14K M14KcTLB M14KcFMM 4KEc 4KEm 4KEp M4K 4Kc 4Km 4Kp 24Kc 24Kf 24KEc 24KEf 34Kc 34Kf 34Kn 74Kc 74Kf 1004Kc 1004Kf 1074Kc 1074Kf microAptivC microAptivP microAptivCF interAptiv interAptivUP proAptiv 5Kf 5Kc 5KEf 5KEc M5100 M5150 M6200 M6250 MIPS32R6 P5600 P6600 I6400 MIPS64R6 I6500 (aliases)
ARM Models    ARM Models aliases ARMv4T ARMv4xM ARMv4 ARMv4TxM ARMv5xM ARMv5 ARMv5TxM ARMv5T ARMv5TExP ARMv5TE ARMv5TEJ ARMv6 ARMv6K ARMv6T2 ARMv6KZ ARMv7 ARM7TDMI ARM7EJ-S ARM720T ARM920T ARM922T ARM926EJ-S ARM940T ARM946E ARM966E ARM968E-S ARM1020E ARM1022E ARM1026EJ-S ARM1136J-S ARM1156T2-S ARM1176JZ-S Cortex-R4 Cortex-R4F Cortex-A5UP Cortex-A5MPx1 Cortex-A5MPx2 Cortex-A5MPx3 Cortex-A5MPx4 Cortex-A8 Cortex-A9UP Cortex-A9MPx1 Cortex-A9MPx2 Cortex-A9MPx3 Cortex-A9MPx4 Cortex-A7UP Cortex-A7MPx1 Cortex-A7MPx2 Cortex-A7MPx3 Cortex-A7MPx4 Cortex-A15UP Cortex-A15MPx1 Cortex-A15MPx2 Cortex-A15MPx3 Cortex-A15MPx4 Cortex-A17MPx1 Cortex-A17MPx2 Cortex-A17MPx3 Cortex-A17MPx4 AArch32 AArch64 Cortex-A32MPx1 Cortex-A32MPx2 Cortex-A32MPx3 Cortex-A32MPx4 Cortex-A35MPx1 Cortex-A35MPx2 Cortex-A35MPx3 Cortex-A35MPx4 Cortex-A53MPx1 Cortex-A53MPx2 Cortex-A53MPx3 Cortex-A53MPx4 Cortex-A55MPx1 Cortex-A55MPx2 Cortex-A55MPx3 Cortex-A55MPx4 Cortex-A57MPx1 Cortex-A57MPx2 Cortex-A57MPx3 Cortex-A57MPx4 Cortex-A72MPx1 Cortex-A72MPx2 Cortex-A72MPx3 Cortex-A72MPx4 Cortex-A73MPx1 Cortex-A73MPx2 Cortex-A73MPx3 Cortex-A73MPx4 Cortex-A75MPx1 Cortex-A75MPx2 Cortex-A75MPx3 Cortex-A75MPx4 MultiCluster ARMv6-M ARMv7-M Cortex-M0 Cortex-M0plus Cortex-M1 Cortex-M3 Cortex-M4 Cortex-M4F (aliases)
POWER Models    POWER Models aliases mpc82x UISA m476 m470 m460 m440 (aliases)
Renesas Models    Renesas Models aliases V850 V850E1 V850E1F V850ES V850E2 V850E2M V850E2R RH850G3M m16c r8c RL78-S1 RL78-S2 RL78-S3 (aliases)
Other Models    Other Models aliases Synopsys ARC_600 Synopsys ARC_605 Synopsys ARC_700 Synopsys ARC_0x21 Synopsys ARC_0x22 Synopsys ARC_0x31 Synopsys ARC_0x32 openCores_generic Andes_N25 Andes_NX25 Microsemi_CoreRISCV Microsemi_MiV_RV32IMA SiFive_E31 SiFive_E51 SiFive_U54 Xilinx MicroBlaze_V7_00 Xilinx MicroBlaze_V7_10 Xilinx MicroBlaze_V7_20 Xilinx MicroBlaze_V7_30 Xilinx MicroBlaze_V8_00 Xilinx MicroBlaze_V8_10 Xilinx MicroBlaze_V8_20 Xilinx MicroBlaze_V9_50 Xilinx MicroBlaze_V10_00 Xilinx MicroBlaze_ISA Altera Nios II_Nios_II_F Altera Nios II_Nios_II_S Altera Nios II_Nios_II_E (aliases)