Skip to content

Model Configurations

This project provides several system configurations.

  • core_only
    Models only the SPARC core connected to main memory. Every processor-generated address (a virtual address) is used directly to index into main memory, with no translation.
  • core_mmu
    Adds a Memory Management Unit (MMU) between the core and main memory. Every processor-generated virtual address is translated to a physical address before it reaches main memory.
  • core_mmu_devices (planned)
    Adds a timer, an interrupt controller, and a serial device.
  • core_l1cache_mmu_devices (planned)
    Adds split instruction and data L1 caches between the core and the MMU.

For each configuration, there exist two implementations:

  • cpp_model
    A 0-delay functional model. A plain host C++ function-call chain through the model's components, with no notion of cycles or timing.
  • sitar_model
    A cycle-timed model. The same components, driven through Sitar with real per-opcode, interconnect, and memory timing.

The configurations and their path in the project (linked) are summarized here:

Configuration Type Description
core_only cpp (functional model) The core plus main memory. No MMU, devices, or caches.
core_only sitar (timing model) The core plus main memory. No MMU, devices, or caches.
core_mmu cpp (functional model) Adds an MMU between the core and main memory.
core_mmu sitar (timing model) Adds an MMU between the core and main memory.

For each configuration, both the cpp and sitar models include the same components: core_mmu's MMU, for example, is present in both its cpp_model and its sitar_model, just reached with 0 added delay in the former and real Sitar timing in the latter.

See Model Components for the list of all components, such as the SPARC Core, the MMU, and devices, that are included in this project.


Sitar Model Structure

For specifically the Sitar models, which have a notion of structure and timing, this section describes the structure and component interconnections for each configuration, as well as the code structure.

Configuration: core_only

Structure diagram

core_only structure diagram

No net crossing anywhere. The core talks directly to memory over a procedure handshake, so zero delay communication is possible between the core and memory procedures. The "--||--" symbol indicates direct communication between the two procedures using a handshake and shared variables.

Model description

This shows component instance ownership: which design unit instantiates which, and how many instances.

Top
 |
 +-- Core (module)
      |
      +-- sparcThread : SparcThread (procedure)
      |    |
      |    +-- 5x VirtualMainMemoryInterface (procedure)
      |
      +-- mainMemory : VirtualMainMemory (procedure)

Configuration: core_mmu

Structure diagram

core_mmu structure diagram

The core talks to the MMU over the same procedure handshake core_only uses. The MMU talks to physical memory over two nets, since PhysicalMainMemory is a module, not a procedure. Crossing a net costs Sitar's own unavoidable minimum one cycle each way, so even at every knob's default this configuration cannot reach a fully 0-delay run the way core_only can.

Model description

This shows component instance ownership: which design unit instantiates which, and how many instances.

Top
 |
 +-- System (module)
      |
      +-- core : Core (module)
      |    |
      |    +-- sparcThread : SparcThread (procedure)
      |    |    |
      |    |    +-- 5x VirtualMainMemoryInterface (procedure)
      |    |
      |    +-- mmu : Mmu (procedure)
      |         |
      |         +-- 2x PhysicalMainMemoryInterface (procedure)
      |              |
      |              +-- PullAToken / PushAToken (procedure)
      |
      +-- mainMemory : PhysicalMainMemory (module)
           |
           +-- PullAToken / PushAToken (procedure)

core.requestOut  --requestNet-->  mainMemory.requestIn
core.responseIn  <-responseNet--  mainMemory.responseOut

Configuration: core_mmu_devices (planned)

Adds a timer, an interrupt controller, and a serial device as further sibling submodules of System, each reached over its own net pair through a shared bus. See Peripheral Devices.


Configuration: core_l1cache_mmu_devices (planned)

Adds split instruction and data L1 caches between the core and the MMU.