Add ideal-memory MLO RTLSIM performance measurement - #1634
Open
ollycassidy13 wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add ideal-memory MLO RTLSIM performance measurement
Summary
This PR enables
RTLSIM_PERFORMANCEfor stitched multi-level offloading (MLO) designs.MLO performance simulation now uses the existing Python XSI path and MLO AXI-MM pre-hook to exercise:
FINNLoopwrapper;m_axi_hbm;m_axi_MVAU_id_*; andThe simulation records the completion cycle of every output frame and derives steady-state throughput from the spacing between completed frames. Results are explicitly labelled as an ideal-memory upper bound because the AXI-MM models do not reproduce platform HBM latency or contention.
The existing non-MLO C++
xsi_fifosimperformance path is unchanged.Motivation
FINN previously skipped the RTLSIM performance step for MLO models. The normal performance path uses the C++ XSI driver, which only handles AXI-Stream interfaces, while a stitched MLO design also requires AXI-MM service for intermediate activations and external weights.
The existing functional MLO verification path already solves the interface problem through a Python XSI pre-hook. It registers:
m_axi_hbm; andm_axi_MVAU_id_*weight interfaces.However, that path did not provide a continuous multi-frame performance measurement or expose output-frame completion times. A single-frame simulation can measure first-frame latency, but it cannot measure steady-state throughput because there is no output-to-output interval.
Changes
Output-frame timing in Python XSI
The XSI output collector now optionally accepts the number of AXI-Stream transactions per frame. It records a completion tick whenever the final transaction of a frame is accepted with
tvalid && tready.The multi-I/O simulation adapter returns:
latency_cycles;interval_cycles;completed_output_frames;interval_valid;steady_state_frames;steady_state_cycles; andoutput_frame_completion_cycles.For multiple output streams, the result is aggregated conservatively: the completed-frame count is limited by the least-complete stream, while latency and timing spans use the slowest output behavior.
Completion-based throughput calculation
For output-frame completion cycles
the first completion measures pipeline-fill latency:
Steady-state throughput is calculated from the first-to-last completion span:
The most recent individual completion interval is also exposed as:
A one-frame run has no valid steady-state interval. For MLO measurements, a configured
rtlsim_batch_sizebelow two is therefore promoted to two frames.MLO builder integration
When an MLO build requests
RTLSIM_PERFORMANCE, the builder now:report/rtlsim_performance.json.The obsolete configuration warning stating that MLO performance measurement is skipped has been removed.
Report labelling
MLO performance reports include:
{ "measurement_scope": "stitched_mlo", "external_memory_model": "ideal_axi_mm", "external_memory_model_is_ideal": true, "performance_interpretation": "ideal_memory_upper_bound", "io_bandwidth_scope": "top_level_axi_stream_only" }The report also records that platform memory latency, arbitration, contention and refresh are not modelled.
Interpretation and limitations
This measurement exercises the accelerator-side AXI-MM protocol and weight-fetch behavior. The FINNLoop controller must issue and complete the intermediate-memory and weight-memory transactions for output frames to finish.
The memory side is intentionally idealized:
The resulting steady-state FPS is therefore an ideal-memory upper bound for the stitched MLO accelerator.
The
DRAM_in_bandwidth[MB/s]andDRAM_out_bandwidth[MB/s]fields retain their existing meaning and cover top-level AXI-Stream traffic only, as indicated byio_bandwidth_scope.