Child-ILA (Child Instructions)

Overview

Within the Instruction-Level Abstraction (ILA) formalism, a Child-ILA is a hierarchical sub-model used to represent the internal steps of a complex instruction defined in a parent ILA. The ILA framework allows for hierarchy, and child-instructions defined in a Child-ILA play a role analogous to micro-instructions for complex processor instructions. By decomposing one macro-level instruction into several child-instructions, a Child-ILA enables the model to capture multi-step operations—such as loading, transforming, and storing data—in a structured, modular way.

Formal Structure

A Child-ILA mirrors the five-element tuple of an ILA model $\langle S, W, S_0, D, N \rangle$, but is scoped to the operation of a single parent instruction. From the ILA execution model in the source paper, a Child-ILA introduces:

Child variables ($S^c$) — a private set of architectural state variables used only while the parent instruction is executing. The parent ILA's state $S$ is still visible to the child, so the child can read from and write to parent state as well as its own $S^c$.
Child inputs — taken from the same input space $W$ as the parent ILA.
Child decode functions ($D^c$) — a set of decoder conditions (e.g., $D_0^c, D_1^c, \ldots$) that determine which child-instruction is active on each iteration.
Child next-state functions ($N^c$) — state-transition functions of the form $N_0^c(S, S^c), N_1^c(S, S^c), \ldots$ that take both the parent state $S$ and the child state $S^c$ as arguments, allowing the child to update parent and child variables jointly.

The joint dependency on $S$ and $S^c$ in the next-state functions is what allows a Child-ILA to manipulate parent-level architectural variables as it executes its internal steps.

Execution Semantics

In the ILA kernel template, the Child-ILA is invoked from the parent ILA after the parent's own instructions have been dispatched. Conceptually, execution proceeds as:

// Below are for child-ILAs
do {
    if (D0c) child_i0.update();
    ...
} until ( no executable child instr )

That is, once the parent instruction is decoded, the parent ILA enters a tight loop that repeatedly checks the child decode conditions and fires the matching child next-state functions, terminating when no child-instruction can be fired any more. This loop is the Child-ILA's execution kernel: each iteration of the loop corresponds to one micro-step of the parent instruction.

Example: AES `START_ENCRYPT`

The source paper illustrates Child-ILA with the AES cryptographic accelerator ILA. The START_ENCRYPT instruction, when modeled as a single monolithic instruction, would be too coarse to expose the internal data movement. Instead, it is described using child-instructions that correspond to the natural phases of the AES operation:

Load — fetch the plaintext/ciphertext from memory into the accelerator's working registers.
Encrypt — perform the AES round transformation on the loaded block.
Store — write the encrypted or decrypted result back out.

Each of these phases is captured as a child-instruction in the Child-ILA associated with START_ENCRYPT, so the entire encryption operation is the sequential firing of these child-instructions within the parent instruction's kernel loop. The architectural variables of the AES ILA (such as the encryption key and the text length) are read and updated through the child next-state functions $N^c(S, S^c)$.

Role in Tandem Simulation

Because a Child-ILA's state-transition functions are still state-transition functions over architectural variables, they translate directly into the high-level executable model (ILEM) used in tandem simulation. This means a Child-ILA can be co-simulated against the corresponding RTL one child-instruction at a time, providing fine-grained visibility into the behavior of complex instructions—an important property for the instruction-by-instruction checking scenario described in the source paper.