LIBRARY  |  COMPANIES |   PLATFORMS |   PROCESSORS |   PERIPHERALS
RiscvRv64gcv

Model Information


This page provides detailed information about the OVP Fast Processor Model of the RISC-V RV64GCV core.
Processor IP owner is RISC-V Foundation. More information is available from them here.

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 RV64GCV


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 RV64GCV 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 RV64GCV ISS also provides access to standard GDB/RSP debuggers and connects to the Eclipse IDE and Imperas debuggers.

Overview of RISC-V RV64GCV Fast Processor Model


Model Variant name: RV64GCV
Description:
    RISC-V RV64GCV 64-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 corresponding bits in the misa CSR Extensions field will be set upon reset:
    misa bit 0: extension A (atomic instructions)
    misa bit 2: extension C (compressed instructions)
    misa bit 3: extension D (double-precision floating point)
    misa bit 5: extension F (single-precision floating point)
    misa bit 8: RV32I/RV64I/RV128I base integer instruction set
    misa bit 12: extension M (integer multiply/divide instructions)
    misa bit 18: extension S (Supervisor mode)
    misa bit 20: extension U (User mode)
    misa bit 21: extension V (vector extension)
    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. Parameter "sub_Extensions_mask" can be used to disable dynamic update of features in the same way.
    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.
Enabling Other 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)
    misa bit 4: RV32E base integer instruction set (embedded)
    misa bit 7: extension H (hypervisor)
    misa bit 10: extension K (cryptographic)
    misa bit 13: extension N (user-level interrupts)
    misa bit 15: extension P (DSP instructions)
    misa bit 23: extension X (non-standard extensions present)
    To add features from this list to the visible set in the misa register, use parameter "add_Extensions". This is a string containing identification letters of features to enable; 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.
    To add features from this list to the implicitly-enabled set (not visible in the misa register), use parameter "add_implicit_Extensions". This is a string parameter in the same format as the "add_Extensions" parameter described above.
Disabling Extensions:
    The following extensions are enabled by default in the model and can be disabled:
    misa bit 0: extension A (atomic instructions)
    misa bit 2: extension C (compressed instructions)
    misa bit 3: extension D (double-precision floating point)
    misa bit 5: extension F (single-precision floating point)
    misa bit 12: extension M (integer multiply/divide instructions)
    misa bit 18: extension S (Supervisor mode)
    misa bit 20: extension U (User mode)
    misa bit 21: extension V (vector extension)
    To disable features that are enabled by default, use parameter "sub_Extensions". This is a string containing identification letters of features to disable; for example, value "DF" indicates that double-precision and single-precision floating point extensions should be disabled, if they are enabled by default on this variant.
    To remove features from this list from the implicitly-enabled set (not visible in the misa register), use parameter "sub_implicit_Extensions". This is a string parameter in the same format as the "sub_Extensions" parameter described above.
mtvec CSR:
    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 0xfffffffffffffffd. 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.
    If parameter "mtvec_sext" is True, values written to "mtvec" are sign-extended from the most-significant writable bit. In this variant, "mtvec_sext" is False, indicating that "mtvec" is not sign-extended.
    The initial value of "mtvec" is 0x0. A different value may be specified using parameter "mtvec" if required.
stvec CSR:
    Values written to "stvec" are masked using the value 0xfffffffffffffffd. A different mask of writable bits may be specified using parameter "stvec_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.
    If parameter "stvec_sext" is True, values written to "stvec" are sign-extended from the most-significant writable bit. In this variant, "stvec_sext" is False, indicating that "stvec" is not sign-extended.
Reset:
    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.
NMI:
    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. The cause reported on an NMI is 0x0 by default; a different cause may be specified using parameter "ecode_nmi" or applied using optional input port "nmi_cause" if required.
    If parameter "rnmi_version" is not "none", resumable NMIs are supported, managed by additional CSRs "mnscratch", "mnepc", "mncause" and "mnstatus", following the indicated version of the Resumable NMI extension proposal. In this variant, "rnmi_version" is "none".
WFI:
    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).
cycle CSR:
    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 cause Illegal Instruction traps.
time CSR:
    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 cause Illegal Instruction traps. 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.
instret CSR:
    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 cause Illegal Instruction traps.
hpmcounter CSRs:
    "hpmcounter" CSRs are implemented in this variant. Set parameter "hpmcounter_undefined" to True to instead specify that "hpmcounter" CSRs are unimplemented and reads of them should cause Illegal Instruction traps.
Virtual Memory:
    This variant supports address translation modes 0 (bare), 8 (Sv39), 9 (Sv48) and 10 (Sv57). Use parameter "Sv_modes" to specify a bit mask of different implemented modes if required; for example, setting "Sv_modes" to (1<<0)+(1<<8) indicates that mode 0 (bare) and mode 8 (Sv39) are implemented. These indices correspond to writable values in the satp.MODE CSR field.
    A 16-bit ASID is implemented. Use parameter "ASID_bits" to specify a different implemented ASID size if required.
    TLB behavior is controlled by parameter "ASIDCacheSize". If this parameter is 0, then an unlimited number of TLB entries will be maintained concurrently. If this parameter is non-zero, then only TLB entries for up to "ASIDCacheSize" different ASIDs will be maintained concurrently initially; as new ASIDs are used, TLB entries for less-recently used ASIDs are deleted, which improves model performance in some cases. If the model detects that the TLB entry cache is too small (entry ejections are very frequent), it will increase the cache size automatically. In this variant, "ASIDCacheSize" is 8.
Unaligned Accesses:
    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.
PMP:
    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. Unaligned PMP accesses are not decomposed into separate aligned accesses; use parameter "PMP_decompose" to modify this behavior if required.
LR/SC Granule:
    LR/SC instructions are implemented with a 1-byte reservation granule. A different granule size may be specified using parameter "lr_sc_grain".
Compressed Extension:
    Standard compressed instructions are present in this variant.
    Parameter Zcea_version is used to specify the version of Zcea instructions present. By default, Zcea_version is set to "none" in this variant. Updates to this parameter require a commercial product license.
    Parameter Zceb_version is used to specify the version of Zceb instructions present. By default, Zceb_version is set to "none" in this variant. Updates to this parameter require a commercial product license.
    Parameter Zcee_version is used to specify the version of Zcee instructions present. By default, Zcee_version is set to "none" in this variant. Updates to this parameter require a commercial product license.
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.
    Half precision floating point is not implemented. Use parameter "Zfh" to enable this if required.
    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".
Privileged Architecture:
    This variant implements the Privileged Architecture with version specified in the References section of this document. Note that parameter "priv_version" can be used to select the required architecture version; see the following sections for detailed information about differences between each supported version.
Legacy Version 1.10:
    1.10 version of May 7 2017.
Version 20190608:
    Stable 1.11 version of June 8 2019, with these changes compared to version 1.10:
    - mcountinhibit CSR defined;
    - pages are never executable in Supervisor mode if page table entry U bit is 1;
    - mstatus.TW is writable if any lower-level privilege mode is implemented (previously, it was just if Supervisor mode was implemented);
Version master:
    Unstable master version corresponding to evolving 1.12 specification, with these changes compared to version 20190608:
    - mstatush, mseccfg, mseccfgh, menvcfg, menvcfgh, senvcfg, henvcfg, henvcfgh and mconfigptr CSRs defined;
    - xret instructions clear mstatus.MPRV when leaving Machine mode if new mode is less privileged than M-mode;
    - maximum number of PMP registers increased to 64;
    - data endian is now configurable.
    Unstable master version as of 20 September 2021 (commit 3570f99) with these changes compared to version 1.0-rc1-20210608:
    - instruction vpopc.m renamed vcpop.m;
    - instruction vmandnot.mm renamed vmandn.mm;
    - instruction vmornot.mm renamed vmorn.mm.
Unprivileged Architecture:
    This variant implements the Unprivileged Architecture with version specified in the References section of this document. Note that parameter "user_version" can be used to select the required architecture version; see the following sections for detailed information about differences between each supported version.
Legacy Version 2.2:
    2.2 version of May 7 2017.
Version 20191213:
    Stable 20191213-Base-Ratified version of December 13 2019, with these changes compared to version 2.2:
    - floating point fmin/fmax instruction behavior modified to comply with IEEE 754-201x.
    - numerous other optional behaviors can be separately enabled using Z-prefixed parameters.
Vector Extension:
    This variant implements the RISC-V base vector extension with version specified in the References section of this document. Note that parameter "vector_version" can be used to select the required version, including the unstable "master" version corresponding to the active specification. See section "Vector Extension Versions" for detailed information about differences between each supported version.
Vector Extension Parameters:
    Parameter ELEN is used to specify the maximum size of a single vector element in bits (32 or 64). By default, ELEN is set to 64 in this variant.
    Parameter VLEN is used to specify the number of bits in a vector register (a power of two in the range 32 to 65536). By default, VLEN is set to 512 in this variant.
    Parameter SLEN is used to specify the striping distance (a power of two in the range 32 to 65536). By default, SLEN is set to 512 in this variant.
    Parameter EEW_index is used to specify the maximum supported EEW for index load/store instructions (a power of two in the range 8 to ELEN). By default, EEW_index is set to 64 in this variant.
    Parameter SEW_min is used to specify the minimum supported SEW (a power of two in the range 8 to ELEN). By default, SEW_min is set to 8 in this variant.
    Parameter Zvlsseg is used to specify whether the Zvlsseg extension is implemented. By default, Zvlsseg is set to 1 in this variant.
    Parameter Zvamo is used to specify whether the Zvamo extension is implemented. By default, Zvamo is set to 1 in this variant.
    Parameter Zvediv will be used to specify whether the Zvediv extension is implemented. This is not currently supported.
    Parameter Zvqmac is used to specify whether the Zvqmac extension is implemented (from version 0.8-draft-20191117 only). By default, Zvqmac is set to 1 in this variant.
    Parameter Zve32x is used to specify whether the Zve32x extension is implemented. By default, Zve32x is set to 0 in this variant.
    Parameter Zve32f is used to specify whether the Zve32f extension is implemented. By default, Zve32f is set to 0 in this variant.
    Parameter Zve64x is used to specify whether the Zve64x extension is implemented. By default, Zve64x is set to 0 in this variant.
    Parameter Zve64f is used to specify whether the Zve64f extension is implemented. By default, Zve64f is set to 0 in this variant.
    Parameter Zve64d is used to specify whether the Zve64d extension is implemented. By default, Zve64d is set to 0 in this variant.
    Parameter require_vstart0 is used to specify whether non-interruptible vector instructions require vstart=0. By default, require_vstart0 is set to 0 in this variant.
    Parameter align_whole is used to specify whether whole-register load and store instructions require alignment to the encoded EEW. By default, align_whole is set to 0 in this variant.
    Parameter vill_trap is used to specify whether attempts to write illegal values to vtype cause an Illegal Instruction trap. By default, vill_trap is set to 0 in this variant.
    Parameter agnostic_ones is used to specify whether agnostic fields are filled with all-ones (from Vector Extension version 0.9 only). By default, agnostic_ones is set to 0 in this variant, meaning mask tails, vector tail elements and vector masked-off elements all show undisturbed behavior.
Vector Extension Features:
    The model implements the base vector extension with a maximum ELEN of 64. Striping, masking and polymorphism are all fully supported. Zvlsseg and Zvamo extensions are fully supported. The Zvediv extension specification is subject to change and therefore not yet supported.
    Single precision and double precision floating point types are supported if those types are also supported in the base architecture (i.e. the corresponding D and F features must be present and enabled). Vector floating point operations may only be executed if the base floating point unit is also enabled (i.e. mstatus.FS must be non-zero). Attempting to execute vector floating point instructions when mstatus.FS is 0 will cause an Illegal Instruction exception.
    The model assumes that all vector memory operations must be aligned to the memory element size. Unaligned accesses will cause a Load/Store Address Alignment exception.
    By default, the processor starts with vector extension disabled (mstatus.VS=0). Use parameter "mstatus_VS" to force mstatus.VS to a non-zero value for the vector extension to be enabled from the start.
Vector Extension Versions:
    The Vector Extension specification has been under active development. To enable simulation of hardware that may be based on an older version of the specification, the model implements behavior for a number of previous versions of the specification. The differing features of these are listed below, in chronological order.
Version 0.7.1-draft-20190605:
    Stable 0.7.1 version of June 10 2019.
Version 0.7.1-draft-20190605+:
    Version 0.7.1, with some 0.8 and custom features. Not intended for general use.
Version 0.8-draft-20190906:
    Stable 0.8 draft of September 6 2019, with these changes compared to version 0.7.1-draft-20190605:
    - tail vector and scalar elements preserved, not zeroed;
    - vext.s.v, vmford.vv and vmford.vf instructions removed;
    - encodings for vfmv.f.s, vfmv.s.f, vmv.s.x, vpopc.m, vfirst.m, vmsbf.m, vmsif.m, vmsof.m, viota.m and vid.v instructions changed;
    - overlap constraints for slideup and slidedown instructions relaxed to allow overlap of destination and mask when SEW=1;
    - 64-bit vector AMO operations replaced with SEW-width vector AMO operations;
    - vsetvl and vsetvli instructions when rs1 = x0 preserve the current vl instead of selecting the maximum possible vl;
    - instruction vfncvt.rod.f.f.w added (to allow narrowing floating point conversions with jamming semantics);
    - instructions that transfer values between vector registers and general purpose registers (vmv.s.x and vmv.x.s) sign-extend the source if required (previously, it was zero-extended).
Version 0.8-draft-20191004:
    Stable 0.8 draft of October 4 2019, with these changes compared to version 0.8-draft-20190906:
    - vwmaccsu and vwmaccus instruction encodings exchanged;
    - vwsmaccsu and vwsmaccus instruction encodings exchanged.
Version 0.8-draft-20191117:
    Stable 0.8 draft of November 17 2019, with these changes compared to version 0.8-draft-20191004:
    - indexed load/store instructions zero-extend offsets (previously, they were sign-extended);
    - vslide1up/vslide1down instructions sign-extend XLEN values to SEW length (previously, they were zero-extended);
    - vadc/vsbc instruction encodings require vm=0 (previously, they required vm=1);
    - vmadc/vmsbc instruction encodings allow both vm=0, implying carry input is used, and vm=1, implying carry input is zero (previously, only vm=1 was permitted, implying carry input is used);
    - vaaddu.vv, vaaddu.vx, vasubu.vv and vasubu.vx instructions added;
    - vaadd.vv and vaadd.vx, instruction encodings changed;
    - vaadd.vi instruction removed;
    - all widening saturating scaled multiply-add instructions removed;
    - vqmaccu.vv, vqmaccu.vx, vqmacc.vv, vqmacc.vx, vqmacc.vx, vqmaccsu.vx and vqmaccus.vx instructions added;
    - CSR vlenb added (vector register length in bytes);
    - load/store whole register instructions added;
    - whole register move instructions added.
Version 0.8-draft-20191118:
    Stable 0.8 draft of November 18 2019, with these changes compared to version 0.8-draft-20191117:
    - vsetvl/vsetvli with rd!=zero and rs1=zero sets vl to the maximum vector length.
Version 0.8:
    Stable 0.8 official release (commit 9a65519), with these changes compared to version 0.8-draft-20191118:
    - vector context status in mstatus register is now implemented;
    - whole register load and store operations have been restricted to a single register only;
    - whole register move operations have been restricted to aligned groups of 1, 2, 4 or 8 registers only.
Version 0.9:
    Stable 0.9 official release (commit cb7d225), with these significant changes compared to version 0.8:
    - mstatus.VS and sstatus.VS fields moved to bits 10:9;
    - new CSR vcsr added and fields VXSAT and VXRM relocated there from CSR fcsr;
    - vfslide1up.vf, vfslide1down.vf, vfcvt.rtz.xu.f.v, vfcvt.rtz.x.f.v, vfwcvt.rtz.xu.f.v, vfwcvt.rtz.x.f.v, vfncvt.rtz.xu.f.v, vfncvt.rtz.x.f.v, vzext.vf2, vsext.vf2, vzext.vf4, vsext.vf4, vzext.vf8 and vsext.vf8 instructions added;
    - fractional LMUL support added, controlled by an extended vtype.vlmul CSR field;
    - vector tail agnostic and vector mask agnostic fields added to the vtype CSR;
    - all vector load/store instructions replaced with new instructions that explicitly encode EEW of data or index;
    - whole register load and store operation encodings changed;
    - VFUNARY0 and VFUNARY1 encodings changed;
    - MLEN is always 1;
    - for implementations with SLEN != VLEN, striping is applied horizontally rather than the previous vertical striping;
    - vmsbf.m, vmsif.m and vmsof.m no longer allow overlap of destination with source or mask registers.
Version 1.0-draft-20210130:
    Stable 1.0-draft-20210130 official release (commit 8e768b0), with these changes compared to version 0.9:
    - SLEN=VLEN register layout is mandatory;
    - ELEN>VLEN is now supported for LMUL>1;
    - whole register moves and load/stores now have element size hints;
    - whole register load and store operations now permit use of aligned groups of 1, 2, 4 or 8 registers.
    - overlap constraints for different source/destination EEW changed;
    - instructions vfrsqrt7.v, vfrec7.v and vrgatherei16.vv added;
    - CSR vtype format changed to make vlmul bits contiguous.
    - vsetvli x0, x0, imm instruction is reserved if it would cause vl to change;
    - ordered/unordered indexed vector memory instructions added;
    - instructions vle1.v, vse1.v and vsetivli added.
Version 1.0-rc1-20210608:
    Stable 1.0-rc1-20210608 official release (commit 795a4dd), with these changes compared to version 1.0-draft-20210130:
    - instructions vle1.v/vse1.v renamed vlm.v/vsm.v;
    - instructions vfredsum.vs/vfwredsum.vs renamed vfredusum.vs/vfwredusum.vs;
    - whole-register load/store instructions now use the EEW encoded in the instruction to determine element size (previously, this was a hint and element size 8 was used).
Other Extensions:
    Other extensions that can be configured are described in this section.
Zmmul:
    Parameter "Zmmul" is 0 on this variant, meaning that all multiply and divide instructions are implemented. if "Zmmul" is set to 1 then multiply instructions are implemented but divide and remainder instructions are not implemented.
Zicsr:
    Parameter "Zicsr" is 1 on this variant, meaning that standard CSRs and CSR access instructions are implemented. if "Zicsr" is set to 0 then standard CSRs and CSR access instructions are not implemented and an alternative scheme must be provided as a processor extension.
Zifencei:
    Parameter "Zifencei" is 1 on this variant, meaning that the fence.i instruction is implemented (but treated as a NOP by the model). if "Zifencei" is set to 0 then the fence.i instruction is not implemented.
Zicbom:
    Parameter "Zicbom" is 0 on this variant, meaning that code block management instructions are undefined. if "Zicbom" is set to 1 then code block management instructions cbo.clean, cbo.flush and cbo.inval are defined.
    If Zicbom is present, the cache block size is given by parameter "cmomp_bytes". The instructions may cause traps if used illegally but otherwise are NOPs in this model.
Zicbop:
    Parameter "Zicbop" is 0 on this variant, meaning that prefetch instructions are undefined. if "Zicbop" is set to 1 then prefetch instructions prefetch.i, prefetch.r and prefetch.w are defined (but behave as NOPs in this model).
Zicboz:
    Parameter "Zicboz" is 0 on this variant, meaning that the cbo.zero instruction is undefined. if "Zicboz" is set to 1 then the cbo.zero instruction is defined.
    If Zicboz is present, the cache block size is given by parameter "cmoz_bytes".
Svnapot:
    Parameter "Svnapot_page_mask" is 0x0 on this variant, meaning that NAPOT Translation Contiguity is not implemented. if "Svnapot_page_mask" is non-zero then NAPOT Translation Contiguity is enabled for page sizes indicated by that mask value when page table entry bit 63 is set.
    If Svnapot is present, "Svnapot_page_mask" is a mask of page sizes for which contiguous pages can be created. For example, a value of 0x10000 implies that 64KiB contiguous pages are supported.
Svpbmt:
    Parameter "Svpbmt" is 0 on this variant, meaning that page-based memory types are not implemented. if "Svpbmt" is set to 1 then page-based memory types are indicated by page table entry bits 62:61.
    Note that except for their effect on Page Faults, the encoded memory types do not alter the behavior of this model, which always implements strongly-ordered non-cacheable semantics.
Svinval:
    Parameter "Svinval" is 0 on this variant, meaning that fine-grained address-translation cache invalidation instructions are not implemented. if "Svinval" is set to 1 then fine-grained address-translation cache invalidation instructions sinval.vma, sfence.w.inval and sfence.inval.ir are implemented.
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.
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 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 "no_sselect_2" is used to specify whether the "sselect" field in "textra32"/"textra64" registers is unable to hold value 2 (indicating match by ASID is not allowed). In this variant, "no_sselect_2" is 0.
    Parameter "mcontext_bits" is used to specify the number of writable bits in the "mcontext" register. In this variant, "mcontext_bits" is 13.
    Parameter "scontext_bits" is used to specify the number of writable bits in the "scontext" register. In this variant, "scontext_bits" is 34.
    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 13.
    Parameter "svalue_bits" is used to specify the number of writable bits in the "svalue" field in "textra32"/"textra64" registers; if zero, the "sselect" is tied to zero. In this variant, "svalue_bits" is 34.
    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.
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.
Page Table Walk Introspection:
    Artifact register "PTWStage" shows the active page table translation stage (0 if no stage active, 1 if HS-stage active, 2 if VS-stage active and 3 if G-stage active). This register is visibly non-zero only in a memory access callback triggered by a page table walk event.
    Artifact register "PTWInputAddr" shows the input address of active page table translation. This register is visibly non-zero only in a memory access callback triggered by a page table walk event.
    Artifact register "PTWLevel" shows the active level of page table translation (corresponding to index variable "i" in the algorithm described by Virtual Address Translation Process in the RISC-V Privileged Architecture specification). This register is visibly non-zero only in a memory access callback triggered by a page table walk event.
Artifact Register "fflags_i":
    If parameter "enable_fflags_i" is True, an 8-bit artifact register "fflags_i" is added to the model. This register shows the floating point flags set by the current instruction (unlike the standard "fflags" CSR, in which the flag bits are sticky).
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.
    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 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 20191213)
    RISC-V Instruction Set Manual, Volume II: Privileged Architecture (Privileged Architecture Version Ratified-IMFDQC-and-Priv-v1.11)
    RISC-V "V" Vector Extension (Vector Architecture Version 1.0-rc1-20210608)

Model downloadable (needs registration and to be logged in) in package riscv.model for Windows32 and for Linux32
OVP simulator downloadable (needs registration and to be logged in) in package OVPsim for Windows32 and for Linux32
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 RV64GCV is available OVP_Model_Specific_Information_riscv_RV64GCV.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
reset_addrinput
nmiinput
nmi_causeinput
nmi_addrinput
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 RV64GCV.


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 RV64GCV 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_RV64GCV.pdf.

Other Sites/Pages with similar information

Information on the RV64GCV OVP Fast Processor Model can also be found on other web sites:
www.imperas.com has more information on the model library.



RiscVprocessors
Page was generated in 0.3311 seconds