Execution and Resource Model

Each Core advances instructions through a four-stage pipeline with cycle-level granularity. This section covers issue gating, resource conflicts, control semantics, and completion rules.

Instruction Lifecycle

The core runtime follows a four-stage pipeline: Instruction Fetch (IF) → Instruction Decode (ID) → Instruction Schedule (IS) → Instruction Execute (IE). Different instructions can occupy different stages concurrently.

Stage Graph

The graph below corresponds to the per-core runtime path.

Instruction Fetch (IF)

Instruction Decode (ID)

Instruction Schedule (IS)

Instruction Execute (IE)

The four pipeline stages map to distinct runtime behaviors.

IF — Instruction Fetch

Fetches the instruction at the current ins_index

ID — Instruction Decode

Decodes instruction into a typed payload and conflict metadata

IS — Instruction Schedule

Evaluates stall/conflicts, gates id_ex_enable, issues to target unit

IE — Instruction Execute

Target execute unit starts when enabled and ready

Per-Cycle Progress Rules

The decoder and PC update operate on separate phase offsets within each cycle, allowing instruction decode and issue to be pipelined.

Each cycle, the core independently evaluates decode, issue, and PC advancement.

Decode and PC Update

Decode

Starts with period_ns / 2 phase offset, then runs once per cycle

Decode Gate

Only proceeds when current conflict metadata has been cleared

PC Update

Applies ins_index += pc_increment only when id_stall == false

Conflict Reset

After the PC advances, conflict metadata is cleared for the next instruction

Issue

At each issue point, processIssue broadcasts a payload to all execute units. Only the matched unit type receives a non-null payload — all others receive nullptr.

Completion

Decode Finish

id_finish = true when the instruction stream has been fully decoded

Unit Finish

Each execute unit reports done after decode is finished and all local instructions are drained

Core Finish

Core run completes only when all execute units report unit_finish

Stall and Conflict Arbitration

The core stalls when either condition holds:

The instruction stream has been fully decoded (id_finish is true)
Any execute-unit conflict signal is true

Each unit has a ConflictHandler that checks whether its currently allocated resources (memory regions, data paths, functor configurations) overlap with those required by the incoming instruction.

Issue vs Execute

Decode/issue does not imply immediate execution. An issued instruction waits until the target unit is ready and the enable signal is asserted before execution begins.

Control Runtime Semantics

Branch and Jump

Branch/jump condition and pc_increment are resolved during decode
No dedicated execute-unit operation is required for branch/jump decision

Timing and Energy Accounting

The simulator charges dynamic energy per-event during compute, memory, and network operations. Static energy comes from configured static power and total simulated runtime.

Stall Energy Impact

Stall cycles produce no dynamic energy but extend the runtime, increasing static energy. Pipeline stalls from resource conflicts or synchronization waits affect the energy/performance tradeoff even though no useful work is performed.

For output format and metric definitions, see Output and Metrics.

Execution and Resource Model

Resource Conflict Types

TAG and WAIT Semantics

BARRIER Synchronization

On this page