The linked Gist may load directly when you open this HTML online. If your browser blocks remote requests, download the Gist's raw log and import it here. The demo is synthetic and never presented as the Gist.
No log has been loaded yet. Choose Load linked Gist, import a file, or paste the original log.
Paste a log
Parsed locally · No upload
—
Observed cycles
—
Cores logged
—
Distinct core / lanes
—
Instruction PCs seen
—
Completion cycles reported
Learn the hardware: Core FSM + LSU + ALU
Interactive · grounded in Tiny-GPU RTL
FSM = Finite-State Machine: a hardware controller that remembers its current state and changes state on clock edges. LSU = Load/Store Unit: the hardware in each thread lane that sends LDR (load) and STR (store) requests to data memory. The LSU itself also contains an FSM.ALU = Arithmetic Logic Unit: each active lane has a registered arithmetic datapath, but the ALU has no separate FSM; the Core Scheduler triggers it during EXECUTE.
1 · Core Scheduler FSM One per core
One scheduler controls the instruction being executed by all enabled lanes. The timeline row “Core 0 · FSM” is this state machine. These are sequential control states, not overlapping pipeline stages.
IDLE→FETCH→DECODE→REQUEST→WAIT→EXECUTE→UPDATE
After UPDATE: return to FETCH for the next instruction, or go to DONE on RET. FETCH can last many cycles; WAIT can also repeat until the relevant LSUs finish.
2 · Load/Store Unit FSM One per active lane
The row “Lane 2 · LSU” shows this lane’s memory transaction progress, not an instruction pipeline. Non-memory instructions normally leave it IDLE.
IDLE→REQUESTING→WAITING→DONE→IDLE
REQUESTING: preparing/issuing the memory request; WAITING: request is outstanding; DONE: received ready/acknowledgment; IDLE: returns after the core’s UPDATE edge.
3 · Arithmetic Logic Unit (ALU) One per lane · no FSM
Each lane has an 8-bit ALU with a registered alu_out. The shared decoder selects ADD, SUB, MUL, DIV or CMP. The ALU calculates on the rising edge while the Core FSM is in EXECUTE.
rs + rt→EXECUTE edge→alu_out→UPDATE edge
No IDLE/WAIT/DONE state machine here. Arithmetic results are truncated to 8 bits. During UPDATE, the register file copies alu_out into the destination for arithmetic instructions. CMP instead uses the ALU output to update NZP condition flags. For LDR/STR, ALU output is not selected for data writeback.
● ACTIVE · USEFUL● ACTIVE · UNUSED● IDLE● UNOBSERVED
How it is derived: enabled lane + core_state == EXECUTE means the ALU computes/updates its output on the next rising edge. Arithmetic/CMP opcodes make the result useful; memory/control opcodes do not. The displayed alu_out is sampled before that edge and can still be the previous result. Unchanged output does not imply idle.
Conceptual states for one lane; repeated WAIT cycles depend on the memory handshake
Load a log and select a cycle to see the actual observed Core FSM + LSU FSM + ALU output together. Until then, the walkthrough above is a conceptual teaching example.
Click a timeline cell to inspect that cycle. Arrow keys step between cycles.
③ Instruction execution map
Load a trace to reconstruct the observed instruction stream.
④ Data-memory snapshots
When present in original text log
Load a text log containing the initial and final DATA MEMORY tables.
How to read the timeline
Hardware mental model
Core is the instruction owner
Each core fetches one instruction and moves through FETCH → DECODE → REQUEST → WAIT → EXECUTE → UPDATE. Stages are FSM states, not overlapped pipeline slots.
Threads carry different data
Each lane has a register file, ALU (Arithmetic Logic Unit), LSU (Load/Store Unit), and PC (Program Counter) calculation. The core shares the decoded instruction.
Memory can stall everything
LDR/STR uses valid/ready handshakes. While LSUs wait, the core remains in WAIT; multiple lanes can have different LSU states even with a shared instruction.
Tip: Start at an LDR or STR instruction. Watch the LSU states change while the core waits, then inspect register updates after UPDATE.