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

1 participant