LIBRARY  |  COMPANIES |   PLATFORMS |   PROCESSORS |   PERIPHERALS
FU540



OVP Virtual Platform: FU540

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

Licensing

Open Source Apache 2.0

Description

SiFive FU540-C000 SoC module. On start up or reset, the reset code at 0x1004 will jump to a jump table entry indexed by the MSEL register at address 0x1000 (default initial MSEL value is 0xf which will cause a jump to address 0x10000). Use the msel peripheral's MSEL parameter to change the initial value of this register. To run a bare metal application use the --program command line option to specify an elf file to be loaded. It must be linked to use addresses corresponding to the implemented memory regions. The --program option will override the initial pc with the ELF file's start address. To facilitate booting Linux an OVP SmartLoader psuedo-peripheral has been included that provides the functionality of the ZSBL/FSBL. The SmartLoader's dtb parameter should be used to specify the device tree blob file to load, and the bbl elf file should be loaded using the --objfilenoentry command line option.

Reference

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

Limitations

Caches and the Cache Controller are not modeled. The Instruction Tightly Integrated Memory (ITIM) is implemented simply as RAM. Deallocation by writing to the byte immediately following the memory is a NOP. The L2 Loosely Integrated Memory (L2-LIM) is implemented simply as RAM. It is always available, since the Cache Controller is not modeled. The L2 Scratchpad memory is not modeled. The Platform DMA Engine (PDMA) is not modeled. The Pulse Width Modulator (PWM) is not modeled. The Inter-Integrated Circuit (I2C) Master Interface is not modeled. The Serial Peripheral Interface (SPI) is not modeled. Instead a Virtio Block MMIO device has been added at reserved address 0x1f000000, using interrupt 54. The General Purpose Input/Output Controller (GPIO) is not modeled. The One-Time Programmable Memory Interface (OTP) is not modeled. DDR controller is not modeled. DDR memory is modeled as RAM. The Debug Interface is not modeled.

Location

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

Platform Summary

Table : Components in platform

TypeInstanceVendorComponent
ProcessorE51_hart0sifive.ovpworld.orgriscvE51
ProcessorU54sifive.ovpworld.orgriscvU54MC
Peripheralmselsifive.ovpworld.orgMSEL
Peripheralclintriscv.ovpworld.orgCLINT
Peripheralplicriscv.ovpworld.orgPLIC
Peripheralprcisifive.ovpworld.orgPRCI
Peripheraluart0sifive.ovpworld.orgUART
Peripheraluart1sifive.ovpworld.orgUART
Peripheralemaccadence.ovpworld.orggem
Peripheralemgmtovpworld.orgtrap
Peripheralvbd0ovpworld.orgVirtioBlkMMIO
PeripheralsmartLoaderriscv.ovpworld.orgSmartLoaderRV64Linux
MemorymaskROMovpworld.orgram
Memorymem1ovpworld.orgram
Memorysafe0addrovpworld.orgram
Memoryhart0DTIMovpworld.orgram
Memoryhart0ITIMovpworld.orgram
Memoryhart1ITIMovpworld.orgram
Memoryhart2ITIMovpworld.orgram
Memoryhart3ITIMovpworld.orgram
Memoryhart4ITIMovpworld.orgram
Memoryl2LIMovpworld.orgram
Busbus0(builtin)address width:38

Platform Simulation Attributes

Table 1: Platform Simulation Attributes

AttributeValueDescription
stoponctrlcstoponctrlcStop on control-C



External Ports for Module FU540

Table 2: External Ports

Port TypePort NameInternal Connection
netportgi1gi1
netportgi2gi2
netportgi3gi3
netportgi4gi4
netportgi5gi5
netportgi6gi6
netportgi7gi7
netportgi8gi8
netportgi9gi9
netportgi10gi10
netportgi11gi11
netportgi12gi12
netportgi13gi13
netportgi14gi14
netportgi15gi15
netportgi16gi16
netportgi17gi17
netportgi18gi18
netportgi19gi19
netportgi20gi20
netportgi21gi21
netportgi22gi22
netportgi23gi23
netportgi24gi24
netportgi25gi25
netportgi26gi26
netportgi27gi27
netportgi28gi28
netportgi29gi29
netportgi30gi30
netportgi31gi31
netportgi32gi32
netportgi33gi33
netportgi34gi34
netportgi35gi35
netportgi36gi36
netportgi37gi37
netportgi38gi38
netportgi39gi39
netportgi40gi40
netportgi41gi41
netportgi42gi42
netportgi43gi43
netportgi44gi44
netportgi45gi45
netportgi46gi46
netportgi47gi47
netportgi48gi48
netportgi49gi49
netportgi50gi50
netportgi51gi51
netportgi52gi52
netportgi53gi53



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

Processor model type: 'riscv' variant 'E51' 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/sifive.ovpworld.org/processor/riscv/1.0/doc
- the OVP website: OVP_Model_Specific_Information_sifive_riscv_E51.pdf

Description

RISC-V E51 64-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 2: extension C (compressed instructions)
misa bit 8: RV32I/64I/128I base ISA
misa bit 12: extension M (integer multiply/divide instructions)
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 3: extension D (double-precision floating point) (NOT ENABLED)
misa bit 4: RV32E base ISA (NOT ENABLED)
misa bit 5: extension F (single-precision floating point) (NOT ENABLED)
misa bit 13: extension N (user-level interrupts) (NOT ENABLED)
misa bit 18: extension S (Supervisor mode) (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 0x3ffffffffd. 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 64.
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" 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 not implemented in this variant and reads of it will require emulation in Machine mode. Set parameter "time_undefined" to False to instead specify that "time" is implemented.
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.
Unaligned memory accesses are not supported for AMO instructions by this variant. Set parameter "unalignedAMO" to "T" to enable such accesses.
8 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 64-byte reservation granule. A different granule size may be specified using parameter "lr_sc_grain".

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.
Hardware Performance Monitor and Debug 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 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
SiFive E51 Core Complex Manual v1p2
SiFive Custom Extensions

Instance Parameters

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

Table 3: Processor Instance 'E51_hart0' Parameters (Configurations)

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

Table 4: Processor Instance 'E51_hart0' Parameters (Attributes)

Parameter NameValueType
mhartid0Uns64
local_int_num48Uns32
reset_address0x1004Uns64
variantE51enum

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

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

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

Table 5: Memory Map ( 'E51_hart0' / 'bus0' [width: 38] )

Lo AddressHi AddressInstanceComponent
0x00xFFsafe0addrram
remappableremappableemgmttrap
0x10000x1FFFmselMSEL
0x100000x17FFFmaskROMram
0x10000000x1001FFFhart0DTIMram
0x18000000x1802000hart0ITIMram
0x18080000x180F000hart1ITIMram
0x18100000x1817000hart2ITIMram
0x18180000x181F000hart3ITIMram
0x18200000x1827000hart4ITIMram
0x20000000x200BFFFclintCLINT
0x80000000x9FFFFFFl2LIMram
0xC0000000xFFFFFFFplicPLIC
0x100000000x10000FFFprciPRCI
0x100100000x1001001Buart0UART
0x100110000x1001101Buart1UART
0x100900000x10090FFFemacgem
0x1F0000000x1F0001FFvbd0VirtioBlkMMIO
0x800000000xBFFFFFFFmem1ram

Net Connections to processor: 'E51_hart0'

Table 6: Processor Net Connections ( 'E51_hart0' )

Net PortNetInstanceComponent
MTimerInterruptMTimerInterrupt0clintCLINT
MSWInterruptMSWInterrupt0clintCLINT
MExternalInterruptirqT0plicPLIC



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

Processor model type: 'riscv' variant 'U54MC' 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/sifive.ovpworld.org/processor/riscv/1.0/doc
- the OVP website: OVP_Model_Specific_Information_sifive_riscv_U54MC.pdf

Description

RISC-V U54MC 64-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 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/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 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

This is a multicore variant with 4 cores by default. The number of cores may be overridden with the "numHarts" parameter.
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 0x3ffffffffd. 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 64.
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 0xfffffffffffffffd. 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 not implemented in this variant and reads of it will require emulation in Machine mode. Set parameter "time_undefined" to False to instead specify that "time" is implemented.
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 0-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 8. 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.
8 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 64-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 only if the F extension is also enabled. Set parameter "d_requires_f"to "F" to allow D and F to be independently 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 "always_dirty".

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
SiFive U54-MC Core Complex Manual v1p0
SiFive Custom Extensions

Instance Parameters

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

Table 7: Processor Instance 'U54' Parameters (Configurations)

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

Table 8: Processor Instance 'U54' Parameters (Attributes)

Parameter NameValueType
mhartid1Uns64
local_int_num48Uns32
reset_address0x1004Uns64
numHarts4Uns32
variantU54MCenum

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

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

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

Table 9: Memory Map ( 'U54' / 'bus0' [width: 38] )

Lo AddressHi AddressInstanceComponent
0x00xFFsafe0addrram
remappableremappableemgmttrap
0x10000x1FFFmselMSEL
0x100000x17FFFmaskROMram
0x10000000x1001FFFhart0DTIMram
0x18000000x1802000hart0ITIMram
0x18080000x180F000hart1ITIMram
0x18100000x1817000hart2ITIMram
0x18180000x181F000hart3ITIMram
0x18200000x1827000hart4ITIMram
0x20000000x200BFFFclintCLINT
0x80000000x9FFFFFFl2LIMram
0xC0000000xFFFFFFFplicPLIC
0x100000000x10000FFFprciPRCI
0x100100000x1001001Buart0UART
0x100110000x1001101Buart1UART
0x100900000x10090FFFemacgem
0x1F0000000x1F0001FFvbd0VirtioBlkMMIO
0x800000000xBFFFFFFFmem1ram

Net Connections to processor: 'U54'

Table 10: Processor Net Connections ( 'U54' )

Net PortNetInstanceComponent
hart1_MTimerInterruptMTimerInterrupt1clintCLINT
hart1_MSWInterruptMSWInterrupt1clintCLINT
hart1_MExternalInterruptirqT1plicPLIC
hart1_SExternalInterruptirqT2plicPLIC
hart2_MTimerInterruptMTimerInterrupt2clintCLINT
hart2_MSWInterruptMSWInterrupt2clintCLINT
hart2_MExternalInterruptirqT3plicPLIC
hart2_SExternalInterruptirqT4plicPLIC
hart3_MTimerInterruptMTimerInterrupt3clintCLINT
hart3_MSWInterruptMSWInterrupt3clintCLINT
hart3_MExternalInterruptirqT5plicPLIC
hart3_SExternalInterruptirqT6plicPLIC
hart4_MTimerInterruptMTimerInterrupt4clintCLINT
hart4_MSWInterruptMSWInterrupt4clintCLINT
hart4_MExternalInterruptirqT7plicPLIC
hart4_SExternalInterruptirqT8plicPLIC



Peripheral Instances



Peripheral [sifive.ovpworld.org/peripheral/MSEL/1.0] instance: msel

Limitations

None

Licensing

Open Source Apache 2.0

Reference

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

Description

Mode Select reset module. Entered on reset and calls boot code based on MSEL pin state. Override the MSEL parameter to specify the initial value for the MSEL pin state (default 0xf). From application code or debugger write to the MSEL register at offset 0 to change the MSEL pin state.

There are no configuration options set for this peripheral instance.



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

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)

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.

Table 11: Configuration options (attributes) set for instance 'clint'

AttributesValue
num_harts5
clockMHz1.0



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

Reference

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

Limitations

Sufficient functionality to boot Virtio BusyBear Linux Kernel. The num_priorities parameter is currently ignored. All 32 bits of priority registers are supported.

Licensing

Open Source Apache 2.0

Description

PLIC Interrupt Controller

Table 12: Configuration options (attributes) set for instance 'plic'

AttributesValue
num_targets9
num_sources53



Peripheral [sifive.ovpworld.org/peripheral/PRCI/1.0] instance: prci

Reference

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

Licensing

Open Source Apache 2.0

Limitations

Register only model. Reset values based on typical post-ZSBL configuration (1GHz coreclk, 500MHz tlclk).

Description

Power Reset Clocking Interrupt (PRCI) block for SiFive FU540 chip

Limitations

None

There are no configuration options set for this peripheral instance.



Peripheral [sifive.ovpworld.org/peripheral/UART/1.0] instance: uart0

Reference

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

Licensing

Open Source Apache 2.0

Description

Sifive UART

Limitations

When simulatebaud parameter is set to true baud rate delays are modeled for receive only, not transmit. Data always sent immediately.

Table 13: Configuration options (attributes) set for instance 'uart0'

AttributesValue
refClkFreq500000000



Peripheral [sifive.ovpworld.org/peripheral/UART/1.0] instance: uart1

Reference

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

Licensing

Open Source Apache 2.0

Description

Sifive UART

Limitations

When simulatebaud parameter is set to true baud rate delays are modeled for receive only, not transmit. Data always sent immediately.

Table 14: Configuration options (attributes) set for instance 'uart1'

AttributesValue
refClkFreq500000000



Peripheral [cadence.ovpworld.org/peripheral/gem/1.0] instance: emac

Limitations

Does not implement: VLAN, pause frames, filtering or timestamps.
This model is based upon the data from the Xilinx Zynq platform, other registers may not be included.

Description

Tested with Xilinx SDK Example driver.

Licensing

Open Source Apache 2.0

Description

Basic network Tx/Rx functionality tested using Xilinx Linux Kernel using wget and other similar tools
This model is based upon the data and use in the Xilinx Zynq
Model of Cadence Gigabit Ethernet Controller (GEM). For further details please consult README-EMAC.txt

Reference

Zynq-7000 TRM (https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf)

There are no configuration options set for this peripheral instance.



Peripheral [ovpworld.org/peripheral/trap/1.0] instance: emgmt

Reference

This is not based upon the operation of a real device but is intended to be used for bring up and development of new virtual platforms.

Limitations

This peripheral cannot be used in a hardware description used to generate a TLM platform.

Licensing

Open Source Apache 2.0

Description

Open a port and allocate a region that is defined by parameters.
The region can be configured to act as standard memory or can report read/write accesses.

Table 15: Configuration options (attributes) set for instance 'emgmt'

AttributesValue
portAddress0x100a0000



Peripheral [ovpworld.org/peripheral/VirtioBlkMMIO/1.0] instance: vbd0

Reference

http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf

Licensing

Open Source Apache 2.0

Limitations

Only supports the Legacy (Device Version 1) interface. Only little endian guests are supported.

Description

VIRTIO version 1 mmio block device This model implements a VIRTIO MMIO block device as described in: http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf. Use the VB_DRIVE parameter to specify the disk image file to use. Set the VB_DRIVE_DELTA parameter to 1 to prevent writes to disk during simulation from changing the image file.

There are no configuration options set for this peripheral instance.



Peripheral [riscv.ovpworld.org/peripheral/SmartLoaderRV64Linux/1.0] instance: smartLoader

Limitations

Only supports little endian

Description

Psuedo-peripheral to insert boot code for a Riscv 64-bit Linux kernel boot. Loads simulated memory with a device tree blob file and boot code to set regs and jump to a Risc-v Linux Kernel.

Licensing

Open Source Apache 2.0

Reference

RISC-V Linux Kernel development

Table 16: Configuration options (attributes) set for instance 'smartLoader'

AttributesValue
bootaddr0x80000000
slbootaddr0x10000
membase0x80000000
memsize0x40000000



SiFivePlatforms
Page was generated in 0.1458 seconds