Processor Definition Proposal

[Jozott00]

The processor definition is being completely revised.

As defined in #81, the processor has the following syntax:

processor Board implements ISA [with Mia] [for ABI] = {}

However, all definitions within the processor will be replaced with new ones.

Reset Definition

The startup definition is replaced by reset, a procedure that can read and write resources. It runs when the simulator starts and on every CPU reset. Its main job is to initialize the CPU state.

At minimum, it should set the program counter. For example, on RV64IM:

processor Spike implements RV64IM {
  reset = {
    PC := 0x1000  // reset vector in ROM
  }
}

Since reset initializes the PC, the old start definition is removed.

Memory Region Definitions

This replaces the existing firmware definition.

In VADL, a memory definition defines an address space, in the processor this must be divided into memory regions serving different purposes.

Each region has a type defining its usage and accessibility. For now, we support:

• RAM: Read/write memory accessible by the processor.
• ROM: Read-only memory initialized by the machine.

The memory region definitions follow the same type specification format as the logic definition in the MIA.

processor Spike implements RV64IM {

  [ firmware ]
  [ base: 0x8000000 ]
  memory region [RAM] DRAM in MEM

  memory region [ROM] MROM in MEM = {
    MEM<4>(0x1000 as Bits<64>) := 0x00000297  // auipc t0, 0x0  
    MEM<4>(0x1004 as Bits<64>) := 0x02828613  // addi a2, t0, 40  
    MEM<4>(0x1008 as Bits<64>) := 0x00000013  // addi x0, x0, 0  
    MEM<4>(0x100c as Bits<64>) := 0x0202b583  // ld   a1, 32(t0)  
    MEM<4>(0x1010 as Bits<64>) := 0x0182b283  // ld   t0, 24(t0)  
    MEM<4>(0x1014 as Bits<64>) := 0x00028067  // jr   t0  
    MEM<4>(0x1018 as Bits<64>) := 0x80000000  // lo32(start_addr)  
    MEM<4>(0x101c as Bits<64>) := 0x00000000  // hi32(start_addr)  
    MEM<4>(0x1020 as Bits<64>) := 0x00000000  // lo32(fdt_addr)  
    MEM<4>(0x1024 as Bits<64>) := 0x00000000  // hi32(fdt_addr)
  }

}

Explanation

• DRAM: A RAM region in MEM starting at 0x8000000.

  • No size specified, as it uses the full machine RAM allocated by QEMU.
  • The [firmware] tag means firmware passed with -bios is loaded here.
    • A load address can be optionally set; defaults to the region base.
  • If multiple RAM regions exist, all but one must specify a [ size: ... ].

• MROM: A ROM region in MEM initialized with startup machine code.

  • Cannot be modified by the simulator user.
  • [ base: ... ] and [ size: ... ] are optional if they can be inferred.

The [firmware] annotation can also be placed on a ROM region. In that case, both size and base must be specified. It’s the user’s responsibility to ensure the loaded firmware doesn’t overlap initialized content. If the firmware exceeds the region size, initialization will fail.

Stop Exit Address

While the [ htif ] annotation already enables simulation termination, the stop exit address definition introduces a simpler mechanism: writing to a specific address causes QEMU to shut down. The written value is recorded as the exit code.

processor Spike implements RV64IM {
  exit address = 0x2000
}

This is useful for stopping execution without needing ELF firmware (which is required for our HTIF implementation).

In the future, users will be able to define custom memory regions like

memory region [MMIO] Comm in MEM = ...

, possibly backed by C modules, to implement custom read/write behavior. This would allow full control over device-level communication and simulation behavior.

Syntax

Reset

Reset is part of the cpuProcessDefinition, but right now it will be the only one.

reset = <statement>

Memory Region

memory region "[" (RAM | ROM) "]" <identifier> {= <statement>}

Available annotations:

[ base : <pure-expr> ]
[ size : <pure-expr> ]
[ firmware {: <pure-expr> } ]

The firmware has an optional expression that represents the load address.

Stop

stop = <pure-expr>

[AndreasKrall]

The proposal looks great.

I do not understand stop completely. Please can you elaborate. Is the result of <pure-expr interpreted as an address which is some kind of memory mapped IO? When it is written QEMU stops?

What is the cost of such a memory mapped IO address? Would it be cheaper to execute an ECALL instruction which exits QEMU?

I believe we should replace <pure-expr> by <const-expr> as I assume it is must be evaluated during parse time. Is that correct?

[AndreasKrall]

I propose with the same syntax as reset to add an init. From the VADL side there is no difference, but the user can specify anything what he wants. It would make it possible to define the following reset and initialization routines:

Microprocessor Initialization and Configuration

Another possibility would be to just define a process which can be connected to a changing edge on a pin. I have no idea how a signal can be emulated by QEMU. In old VADL we had a signal keyword and ports which we dropped in OpenVADL because it is to low level in the current MiA abstraction.

@linushdot, do you have some ideas and comments on these things?