Skip to content

Add ideal-memory MLO RTLSIM performance measurement - #1634

Open
ollycassidy13 wants to merge 1 commit into
Xilinx:devfrom
ollycassidy13:feature/mlo-rtlsim-performance
Open

Add ideal-memory MLO RTLSIM performance measurement#1634
ollycassidy13 wants to merge 1 commit into
Xilinx:devfrom
ollycassidy13:feature/mlo-rtlsim-performance

Conversation

@ollycassidy13

Copy link
Copy Markdown

Add ideal-memory MLO RTLSIM performance measurement

Summary

This PR enables RTLSIM_PERFORMANCE for stitched multi-level offloading (MLO) designs.

MLO performance simulation now uses the existing Python XSI path and MLO AXI-MM pre-hook to exercise:

  • the complete stitched FINNLoop wrapper;
  • queue-backed intermediate loop storage through m_axi_hbm;
  • external MVAU weight fetches through m_axi_MVAU_id_*; and
  • continuous multi-frame AXI-Stream input and output traffic.

The 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_fifosim performance 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:

  • a read/write AXI-MM queue for m_axi_hbm; and
  • read-only AXI-MM images for the m_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; and
  • output_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

t1, t2, ..., tN

the first completion measures pipeline-fill latency:

latency_cycles = t1

Steady-state throughput is calculated from the first-to-last completion span:

steady_state_frames = N - 1
steady_state_cycles = tN - t1

stable_throughput[images/s] =
    (N - 1) * 1e9 / (clock_period_ns * (tN - t1))

The most recent individual completion interval is also exposed as:

fps_from_interval = 1e9 / (clock_period_ns * interval_cycles)

A one-frame run has no valid steady-state interval. For MLO measurements, a configured rtlsim_batch_size below two is therefore promoted to two frames.

MLO builder integration

When an MLO build requests RTLSIM_PERFORMANCE, the builder now:

  1. prepares a copy of the stitched MLO model for Python XSI;
  2. creates the existing MLO AXI-MM pre-hook;
  3. drives at least two frames continuously;
  4. collects output-frame completion timing;
  5. calculates batch and steady-state throughput separately; and
  6. writes 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:

  • address channels are accepted without backpressure;
  • data can be returned at up to one beat per cycle;
  • weight interfaces have independent memory images; and
  • realistic HBM latency, arbitration, shared-port contention, refresh and platform effects are not included.

The resulting steady-state FPS is therefore an ideal-memory upper bound for the stitched MLO accelerator.

The DRAM_in_bandwidth[MB/s] and DRAM_out_bandwidth[MB/s] fields retain their existing meaning and cover top-level AXI-Stream traffic only, as indicated by io_bandwidth_scope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant