3. Memory Map¶

This chapter describes the memory map as well as the various memories and their properties of the VeeR EL2 core.

3.1. Address Regions¶

The 32-bit address space is subdivided into sixteen fixed-sized, contiguous 256MB regions. Each region has a set of access control bits associated with it (Region Access Control Register (mrac)).

3.2. Access Properties¶

Each region has two access properties which can be independently controlled. They are:

• Cacheable: Indicates if this region is allowed to be cached or not.

• Side effect: Indicates if read/write accesses to this region may have side effects (i.e., non-idempotent accesses which may potentially have side effects on any read/write access; typical for I/O, speculative or redundant accesses must be avoided) or have no side effects (i.e., idempotent accesses which have no side effects even if the same access is performed multiple times; typical for memory). Note that stores with potential side effects (i.e., to non-idempotent addresses) cannot be combined with other stores in the core’s unified read/write buffer.

3.3. Memory Types¶

There are two different classes of memory types mapped into the core’s 32-bit address range, core local and system bus attached.

3.3.1. Core Local¶

3.3.1.1. ICCM and DCCM¶

Two dedicated memories, one for instruction and the other for data, are tightly coupled to the core. These memories provide low-latency access and SECDED ECC protection. Their respective sizes (4, 8, 16, 32, 48 [1], 64, 128, 256, or 512KB) are set as arguments at build time of the core.

3.3.1.2. Local Memory-Mapped Control/Status Registers¶

To provide control for regular operation, the core requires a number of memory-mapped control/status registers. For example, some external interrupt functions are controlled and serviced with accesses to various registers while the system is running.

3.3.2. Accessed via System Bus¶

3.3.2.1. System ROMs¶

The SoC may host ROMs which are mapped to the core’s memory address range and accessed via the system bus. Both instruction and data accesses are supported to system ROMs.

3.3.2.2. System SRAMs¶

The SoC hosts a variety of SRAMs which are mapped to the core’s memory address range and accessed via the system bus.

3.3.2.3. System Memory-Mapped I/O¶

The SoC hosts a variety of I/O device interfaces which are mapped to the core’s memory address range and accessed via the system bus.

3.3.3. Mapping Restrictions¶

Core-local memories and system bus-attached memories must be mapped to different regions. Mapping both classes of memory types to the same region is not allowed.

Furthermore, it is recommended that all core-local memories are mapped to the same region.

3.4. Memory Type Access Properties¶

Table 3.1 specifies the access properties of each memory type. During system boot, firmware must initialize the properties of each region based on the memory type present in that region.

3.5. Memory Access Ordering¶

Loads and stores to system bus-attached memory (i.e. accesses with no side effects, idempotent) and devices (i.e. accesses with potential side effects, non-idempotent) pass through a unified read/write buffer. The buffer is implemented as a FIFO.

3.5.1. Load-To-Load and Store-To-Store Ordering¶

All loads are sent to the system bus interface in program order. Also, all stores are sent to the system bus interface in program order.

3.5.2. Load/Store Ordering¶

3.5.2.1. Accesses with Potential Side Effects (i.e., Non-Idempotent)¶

When a load with potential side effects (i.e., non-idempotent) enters the buffer, the entire unified buffer is emptied, i.e., both stores with no side effects (i.e., idempotent) and with potential side effects (i.e., non-idempotent) are drained out. Loads with potential side effects (i.e., non-idempotent) are sent out to the system bus with their exact size.

Stores with potential side effects (i.e., non-idempotent) are neither coalesced nor forwarded to a load.

3.5.2.2. Accesses with No Side Effects (i.e., Idempotent)¶

Loads with no side effects (i.e., idempotent) are always issued as double-words and check the contents of the unified buffer:

1. Full address match (all load bytes present in the unified buffer): Data is forwarded from the unified buffer. The load does not go out to the system bus.

2. Partial address match (some of the load bytes are in the unified buffer): The entire unified buffer is emptied, then the load request goes to the system bus.

3. No match (none of the bytes are in the unified buffer): The load is presented to the system bus interface without waiting for the stores to drain.

3.5.2.3. Ordering of Store - Load with No Side Effects (i.e., Idempotent)¶

A fence instruction is required to order an older store before a younger load with no side effects (i.e., idempotent).

3.5.3. Fencing¶

3.5.3.1. Instructions¶

The fence.i instruction operates on the instruction memory and/or I-cache. This instruction causes a flush, a flash invalidation of the I-cache, and a refetch of the next program counter (RFNPC). The refetch is guaranteed to miss the I-cache. Note that since the fence.i instruction is used to synchronize the instruction and data streams, it also includes the functionality of the fence instruction (see Data).

3.5.3.2. Data¶

The fence instruction is implemented conservatively in VeeR EL2 to keep the implementation simple. It always performs the most conservative fencing, independent of the instruction’s arguments. The fence instruction is presynced to make sure that there are no instructions in the LSU pipe. It stalls until the LSU indicates that the store buffer and unified buffer have been fully drained (i.e., are empty). The fence instruction is only committed after all LSU buffers are idle and all outstanding bus transactions are completed.

3.5.4. Imprecise Data Bus Errors¶

All store errors as well as non-blocking load errors on the system bus are imprecise. The address of the first occurring imprecise data system bus error is logged and a non-maskable interrupt (NMI) is flagged for the first reported error only. For stores, if there are other stores in the unified buffer behind the store which had the error, these stores are sent out on the system bus and any error responses are ignored. Similarly, for non-blocking loads, any error responses on subsequent loads sent out on the system bus are ignored. NMIs are fatal, architectural state is lost, and the core needs to be reset. The reset also unlocks the first error address capture register again.

3.6. Memory Protection¶

To eliminate issuing speculative accesses to the IFU and LSU bus interfaces, VeeR EL2 provides a rudimentary memory protection mechanism for instruction and data accesses outside of the ICCM and DCCM memory regions. Separate core build arguments for instructions and data are provided by the Memory Protection Unit (MPU) to enable and configure up to 8 address windows each.

An instruction fetch to a non-ICCM region must fall within the address range of at least one instruction access window for the access to be forwarded to the IFU bus interface. If at least one instruction access window is enabled, nonspeculative fetch requests which are not within the address range of any enabled instruction access window cause a precise instruction access fault exception. If none of the 8 instruction access windows is enabled, the memory protection mechanism for instruction accesses is turned off. For the ICCM region, accesses within the ICCM’s address range are allowed. However, any access not within the ICCM’s address range results in a precise instruction access fault exception.

Similarly, a load/store access to a non-DCCM or non-PIC memory-mapped control register region must fall within the address range of at least one data access window for the access to be forwarded to the LSU bus interface. If at least one data access window is enabled, non-speculative load/store requests which are not within the address range of any enabled data access window cause a precise load/store address misaligned or access fault exception. If none of the 8 data access windows is enabled, the memory protection mechanism for data accesses is turned off. For the DCCM and PIC memory-mapped control register region(s), accesses within the DCCM’s or the PIC memory-mapped control register’s address range are allowed. However, any access not within the DCCM’s or PIC memory-mapped control register’s address range results in a precise load/store address misaligned or access fault exception.

The configuration parameters for each of the 8 instruction and 8 data access windows are:

• Enable/disable instruction/data access window 0..7,

• a base address of the window (which must be 64B-aligned), and

• a mask specifying the size of the window (which must be an integer-multiple of 64 bytes minus 1).

See Memory Protection Build Arguments for more information.

3.7. Exception Handling¶

Capturing the faulting effective address causing an exception helps assist firmware in handling the exception and/or provides additional information for firmware debugging. For precise exceptions, the faulting effective address is captured in the standard RISC-V mtval register (see Section 3.1.17 in [2]). For imprecise exceptions, the address of the first occurrence of the error is captured in a platform-specific error address capture register (see D-Bus First Error Address Capture Register (mdseac)).

3.7.1. Imprecise Bus Error Non-Maskable Interrupt¶

Store bus errors are fatal and cause a non-maskable interrupt (NMI). The store bus error NMI has an mcause value of 0xF000_0000.

Likewise, non-blocking load bus errors are fatal and cause a non-maskable interrupt (NMI). The non-blocking load bus error NMI has an mcause value of 0xF000_0001.

3.7.2. Correctable Error Local Interrupt¶

I-cache parity/ECC errors, ICCM correctable ECC errors, and DCCM correctable ECC errors are counted in separate correctable error counters (see sections I-Cache Error Counter/Threshold Register (micect), Iccm Correctable Error Counter/Threshold Register (miccmect), and Dccm Correctable Error Counter/Threshold Register (mdccmect), respectively). Each counter also has its separate programmable error threshold. If any of these counters has reached its threshold, a correctable error local interrupt is signaled. Firmware should determine which of the counters has reached the threshold and reset that counter.

A local-to-the-core interrupt for correctable errors has pending (mceip) and enable (mceie) bits in bit position 30 of the standard RISC-V mip (see Table 12.2) and mie (see Table 12.1) registers, respectively. The priority is lower than the RISC-V External interrupt, but higher than the RISC-V Software and Timer interrupts, (see Table 14.1). The correctable error local interrupt has an mcause value of 0x8000_001E (see Table 12.3).

3.7.3. Rules for Core-Local Memory Accesses¶

The rules for instruction fetch and load/store accesses to core-local memories are:

1. An instruction fetch access to a region

   1. containing one or more ICCM sub-region(s)causes an exception if

      1. the access is not completely within the ICCM sub-region, or

      2. the boundary of an ICCM to a non-ICCM sub-region and vice versa is crossed, even if the region contains a DCCM/PIC memory-mapped control register sub-region.

   2. not containing an ICCM sub-region goes out to the system bus, even if the region contains a DCCM/PIC memory-mapped control register sub-region.

2. A load/store access to a region

   1. containing one or more DCCM/PIC memory-mapped control register sub-region(s) causes an exception if

      1. the access is not completely within the DCCM/PIC memory-mapped control register subregion, or

      2. the boundary of

         1. a DCCM to a non-DCCM sub-region and vice versa, or

         2. a PIC memory-mapped control register sub-region is crossed, even if the region contains an ICCM sub-region.

   2. not containing a DCCM/PIC memory-mapped control register sub-region goes out to the system bus, even if the region contains an ICCM sub-region.

3.7.4. Core-Local / D-Bus Access Prediction¶

In VeeR EL2, a prediction is made early in the pipeline if the access is to a core-local address (i.e., DCCM or PIC memory-mapped register) or to the D-bus (i.e., a memory or register address of the SoC). The prediction is based on the base address (i.e., value of register rs1) of the load/store instruction. Later in the pipeline, the actual address is calculated also taking the offset into account (i.e., value of register rs1 + offset). A mismatch of the predicted and the actual destination (i.e., a core-local or a D-bus access) results in a load/store access fault exception.

3.7.5. Unmapped Addresses¶

3.7.6. Misaligned Accesses¶

General notes:

• The core performs a misalignment check during the address calculation.

• Accesses across region boundaries always cause a misaligned exception.

• Splitting a load/store from/to an address with no side effects (i.e., idempotent) is not of concern for VeeR EL2.

3.7.7. Uncorrectable Ecc Errors¶

3.7.8. Correctable Ecc/Parity Errors¶

3.8. Control/Status Registers¶

A summary of platform-specific control/status registers in CSR space:

• Region Access Control Register (mrac)

• Memory Synchronization Trigger Register (dmst)

• D-Bus First Error Address Capture Register (mdseac)

• D-Bus Error Address Unlock Register (mdeau)

• Machine Secondary Cause Register (mscause)

All reserved and unused bits in these control/status registers must be hardwired to ‘0’. Unless otherwise noted, all read/write control/status registers must have WARL (Write Any value, Read Legal value) behavior.

3.8.1. Region Access Control Register (mrac)¶

A single region access control register is sufficient to provide independent control for 16 address regions.

This register is mapped to the non-standard read/write CSR address space.

3.8.2. Memory Synchronization Trigger Register (dmst)¶

The dmst register provides triggers to force the synchronization of memory accesses. Specifically, it allows a debugger to initiate operations that are equivalent to the fence.i (see Instructions) and fence (see Data) instructions.

The fence_i and fence fields of the dmst register have W1R0 (Write 1, Read 0) behavior, as also indicated in the ‘Access’ column.

This register is mapped to the non-standard read/write CSR address space.

3.8.3. D-Bus First Error Address Capture Register (mdseac)¶

The address of the first occurrence of a store or non-blocking load error on the D-bus is captured in the mdseac register. Latching the address also locks the register. While the mdseac register is locked, subsequent D-bus errors are gated (i.e., they do not cause another NMI), but NMI requests originating external to the core are still honored.

The mdseac register is unlocked by either a core reset (which is the safer option) or by writing to the mdeau register (see D-Bus Error Address Unlock Register (mdeau)).

This register is mapped to the non-standard read-only CSR address space.

3.8.4. D-Bus Error Address Unlock Register (mdeau)¶

Writing to the mdeau register unlocks the mdseac register (see D-Bus First Error Address Capture Register (mdseac)) after a D-bus error address has been captured. This write access also reenables the signaling of an NMI for a subsequent D-bus error.

The mdeau register has WAR0 (Write Any value, Read 0) behavior. Writing ‘0’ is recommended.

This register is mapped to the non-standard read/write CSR address space.

3.8.5. Machine Secondary Cause Register (mscause)¶

The mscause register, in conjunction with the standard RISC-V mcause register (see Machine Cause Register (mcause)), allows the determination of the exact cause of a trap for cases where multiple, different conditions share a single trap code. The standard RISC-V mcause register provides the trap code and the mscause register provides supporting information about the trap to disambiguate different sources. A value of ‘0’ indicates that there is no additional information available. Table 3.10 lists VeeR EL2’s standard exceptions/interrupts (regular text), platform-specific local interrupts (italic text), and NMI causes (bold text).

The mscause register has WLRL (Write Legal value, Read Legal value) behavior.

This register is mapped to the non-standard read/write CSR address space.

3.9. Memory Address Map¶

Table 3.11 summarizes an example of the VeeR EL2 memory address map, including regions as well as start and end addresses for the various memory types.

3.10. Behavior of Loads to Side-Effect Addresses¶

Loads with potential side-effects do not stall the pipeline and may be committed before the data is returned from the system bus. Other loads and stores in the pipeline continue to be executed unless an instruction uses data from a pending side-effect load. Stalling the instruction control flow until a side-effect load has completed may be accomplished by either issuing a fence instruction or by generating a dependency on the load’s data.

3.11. Partial Writes¶

Rules for partial writes handling are:

• Core-local addresses: The core performs a read-modify-write operation and updates ECC to core-local memories (i.e., I- and DCCMs).

• SoC addresses: The core indicates the valid bytes for each bus write transaction. The addressed SoC memory or device performs a read-modify-write operation and updates its ECC.

3.12. Expected SoC Behavior for Accesses¶

The VeeR EL2 core expects that the SoC responds to all system bus access requests it receives from the core. System bus accesses include instruction fetches, load/store data accesses as well as debug system bus accesses. A response may either be returning the requested data (e.g., instructions sent back to the core for fetches or data for loads), an acknowledgement indicating the successful completion of a bus transaction (e.g., acknowledging a store), an error response (e.g., an error indication in response to an attempt to access an unmapped address). If the SoC does not respond to every single bus transaction, the core may hang.

3.13. Speculative Bus Accesses¶

Deep core pipelines require a certain degree of speculation to maximize performance. The sections below describe instruction and data speculation in the VeeR EL2 core. Note that speculative accesses to memory addresses with side effects may be entirely avoided by adding the buildargument-selected and -configured memory protection mechanism described in Memory Protection.

3.13.1. Instructions¶

Instruction cache misses on VeeR EL2 are speculative in nature. The core may issue speculatively fetch accesses on the IFU bus interface for an instruction cache miss in the following cases:

• due to an earlier exception or interrupt,

• due to an earlier branch mispredict,

• due to an incorrect branch prediction, and

• due to an incorrect Return Address Stack (RAS) prediction.

Issuing speculative accesses on the IFU bus interface is benign as long as the platform is able to handle accesses to unimplemented memory and to prevent accesses to SoC components with read side effects by returning random data and/or a bus error condition. The decision of which addresses are unimplemented and which addresses with potential side effects need to be protected is left to the platform.

Instruction fetch speculation can be limited, though not entirely avoided, by turning off the core’s branch predictor including the return address stack. Writing a ‘1’ to the bpd bit in the mfdc register (see Table 11.1) disables branch prediction including RAS.

3.13.2. Data¶

The VeeR EL2 core does not issue any speculative data accesses on the LSU bus interface.

3.14. DMA Slave Port¶

The Direct Memory Access (DMA) slave port is used for read/write accesses to core-local memories initiated by external masters. For example, external masters could be DMA controllers or other CPU cores located in the SoC.

3.14.1. Access¶

The DMA slave port allows read/write access to the core’s ICCM and DCCM. However, the PIC memory-mapped control registers are not accessible via the DMA port.

3.14.2. Write Alignment Rules¶

For writes to the ICCM and DCCM through the DMA slave port, accesses must be 32- or 64-bit aligned, and 32 bits (word) or 64 bits (double-word), respectively, wide to avoid read-modify-write operations for ECC generation.

More specifically, DMA write accesses to the ICCM or DCCM must have a 32- or 64-bit access size and be aligned to their respective size. The only write byte enable values allowed for AXI4 are 0x0F, 0xF0, and 0xFF.

3.14.3. Quality Of Service¶

Accesses to the ICCM and DCCM by the core have higher priority if the DMA FIFO is not full. However, to avoid starvation, the DMA slave port’s DMA controller may periodically request a stall to get access to the pipe if a DMA request is continuously blocked.

The dqc field in the mfdc register (see Table 11.1) specifies the maximum number of clock cycles a DMA access request waits at the head of the DMA FIFO before requesting a bubble to access the pipe. For example, if dqc is 0, a DMA access requests a bubble immediately (i.e., in the same cycle); if dqc is 7 (the default value), a waiting DMA access requests a bubble on the 8th cycle. For a DMA access to the ICCM, it may take up to 3 additional cycles25 before the access is granted. Similarly, for a DMA access to the DCCM, it may take up to 4 additional cycles before the access is granted.

3.14.4. Ordering Of Core and DMA Accesses¶

Accesses to the DCCM or ICCM by the core and the DMA slave port are asynchronous events relative to one another. There are no ordering guarantees between the core and the DMA slave port accessing the same or different addresses.

3.15. Reset Signal and Vector¶

The core provides a 31-bit wide input bus at its periphery for a reset vector. The SoC must provide the reset vector on the rst_vec[31:1] bus, which could be hardwired or from a register. The rst_l input signal is active-low, asynchronously asserted, and synchronously deasserted (see also Reset). When the core is reset, it fetches the first instruction to be executed from the address provided on the reset vector bus. Note that the applied reset vector must be pointing to the ICCM, if enabled, or a valid memory address, which is within an enabled instruction access window if the memory protection mechanism (see Memory Protection) is used.

3.16. Non-Maskable Interrupt (NMI) Signal and Vector¶

The core provides a 31-bit wide input bus at its periphery for a non-maskable interrupt (NMI) vector. The SoC must provide the NMI vector on the nmi_vec[31:1] bus, either hardwired or sourced from a register.

The SoC may trigger an NMI by asserting the low-to-high edge-triggered, asynchronous nmi_int input signal. This signal must be asserted for at least two full core clock cycles to guarantee it is detected by the core since shorter pulses might be dropped by the synchronizer circuit. Furthermore, the nmi_int signal must be deasserted for a minimum of two full core clock cycles and then reasserted to signal the next NMI request to the core. If the SoC does not use the pin-asserted NMI feature, it must hardwire the nmi_int input signal to 0.

In addition to NMIs triggered by the SoC, a core-internal NMI request is signaled when a D-bus store or non-blocking load error has been detected.

When the core receives either an SoC-triggered or a core-internal NMI request, it fetches the next instruction to be executed from the address provided on the NMI vector bus. The reason for the NMI request is reported in the mcause register according to Table 3.12.

3.17. Software Interrupts¶

The VeeR EL2 core provides a software-interrupt input signal for its hart (see soft_int in Table 16.1). The soft_int signal is an active-high, level-sensitive, asynchronous input signal which feeds the msip (machine software-interrupt pending) bit of the standard RISC-V mip register (see Table 12.2). When the msie (machine software-interrupt enable) bit of the standard RISC-V mie register (see Table 12.1) is set, a machine software interrupt occurs if the msip bit of the mip register is asserted.

The SoC must implement Machine Software Interrupt (MSI) memory-mapped I/O registers. These registers provide interrupt control bits which are directly connected to the respective soft_int pins of each core. Writing to the corresponding bit of one of these registers enables remote harts to trigger machine-mode interprocessor interrupts.

Each hart can read its own mhartid register (see Machine Hardware Thread ID Register (mhartid)) to determine the memory address of the associated memory-mapped MSI register within the platform. In this manner, an interrupt service routine can reset the corresponding memory-mapped MSI register bit before returning from a software interrupt.