coreblocks.telemetry package
Submodules
coreblocks.telemetry.events module
- class coreblocks.telemetry.events.ExecComplete
Bases:
EventThe instruction finished executing: its result was announced and the ROB entry was marked done.
- class coreblocks.telemetry.events.FTQAlloc
Bases:
EventAn FTQ entry was allocated for the fetch block at pc.
- class coreblocks.telemetry.events.FTQCommit
Bases:
EventThe FTQ commit pointer advanced to ftq_ptr: this entry is now the oldest live one, and all entries strictly before it are fully retired and freed. Emitted per retired instruction, so an entry with several instructions produces multiple commits of the same pointer.
- class coreblocks.telemetry.events.FTQRollback
Bases:
EventFTQ allocation was rolled back: ftq_ptr is the new allocation pointer, so all entries from ftq_ptr onward are squashed.
- class coreblocks.telemetry.events.FetchRequest
Bases:
EventThe FTQ issued a request to the instruction fetch unit for the fetch block owned by the FTQ entry.
- class coreblocks.telemetry.events.FuIssue
Bases:
EventThe instruction was issued from a reservation station to a functional unit.
- class coreblocks.telemetry.events.InstrDecoded
Bases:
EventAn instruction landed in the decode stage. The instruction is identified by its FTQ entry and the slot index within it.
- class coreblocks.telemetry.events.InstrFetched
Bases:
EventThe fetch unit produced a single instruction and sent it towards the decode stage. ftq_offset is the instruction’s slot index within its fetch block.
- class coreblocks.telemetry.events.RobAllocate
Bases:
EventA ROB entry was allocated for the instruction; from this point on the instruction is identified by its rob_id.
- class coreblocks.telemetry.events.RobFlush
Bases:
EventThe instruction was squashed from the ROB without retiring.
- class coreblocks.telemetry.events.RobRetire
Bases:
EventThe instruction retired.
coreblocks.telemetry.konata module
Converter from captured event logs to the Kanata pipeline-visualization format (https://github.com/shioyadan/Konata).
Since Kanata files are append-only with monotonically increasing time, and the concrete instructions of a fetch block are only known when they leave the fetch unit, the converter buffers everything: event handlers build per-instruction stage timelines, and the log is written out at the end, sorted by cycle. This allows backdating an instruction’s fetch stages to the times its fetch block was allocated and requested.
- class coreblocks.telemetry.konata.KonataParser
Bases:
EventConsumerConverts instruction lifetime events into a Kanata log.
An instruction’s lifetime starts at the fetch request for its fetch block. Stages:
“F” from the fetch request until the instruction leaves the fetch unit,
“Q” while it waits in the frontend instruction queue,
“D” from landing in the decode stage,
“Rn” (rename) from entering the scheduler,
“Ds” (dispatch) from ROB allocation (which is where the instruction becomes identified by its ROB id),
“Is” (issue) from being issued to a functional unit,
“Cm” once execution completes.
The instruction terminates by retiring (RobRetire) or being squashed. Instructions still in flight when the event log ends are left unterminated.
- on_alloc(rec: DecodedEvent)
- on_commit(rec: DecodedEvent)
- on_exec_complete(rec: DecodedEvent)
- on_fetch_request(rec: DecodedEvent)
- on_fu_issue(rec: DecodedEvent)
- on_instr_decoded(rec: DecodedEvent)
- on_instr_fetched(rec: DecodedEvent)
- on_rob_allocate(rec: DecodedEvent)
- on_rob_flush(rec: DecodedEvent)
- on_rob_retire(rec: DecodedEvent)
- on_rollback(rec: DecodedEvent)
- on_scheduler_enter(rec: DecodedEvent)
coreblocks.telemetry.rvvi module
- class coreblocks.telemetry.rvvi.RVVIAggregator
Bases:
ComponentA module that aggregates multiple RVVIHartCollector modules into a RVVI-TRACE interface.
- __init__(rvvi_harts: list[RVVIHartCollector])
- class coreblocks.telemetry.rvvi.RVVIHartCollector
Bases:
ComponentA module that collects information required for RVVI-TRACE interface for a single hart.
Currently doesn’t implement pc_wdata, f_*, v_*, csr_*.
Made as a simulation module, so critical path nor area is not optimized. Either way exposing more than 128k wires is not feasible.