Hierarchy and Component Count

Structural overhead at scale

Very deep or extremely wide component hierarchies add build/connect/report overhead and memory footprint. The issue appears when benches model every small data element as a component.

[PERF] hierarchy pressure signals

  build/connect time large relative to run time
  excessive memory before stimulus starts
  report traversal expensive on final summary
  debug paths become hard to navigate

When to use components vs data objects

• Use components for active behavior and phase participation.

• Use plain objects/queues for passive data aggregation.

• Avoid component-per-entry designs for large tables/maps.

Design patterns for scalable hierarchy

Prefer aggregated collectors and parameterized arrays over many tiny leaf components when behavior is homogeneous.

class lane_monitor_bank extends uvm_component;
  `uvm_component_utils(lane_monitor_bank)

  localparam int LANES = 64;
  virtual lane_if vif[LANES];
  lane_sample     samples_q[LANES][$];

  task run_phase(uvm_phase phase);
    fork
      for (int i = 0; i < LANES; i++) begin
        automatic int lane = i;
        fork
          monitor_lane(lane);
        join_none
      end
    join
  endtask

  task monitor_lane(int lane);
    forever begin
      @(posedge vif[lane].clk);
      if (vif[lane].valid) begin
        lane_sample s = new();
        s.data = vif[lane].data;
        samples_q[lane].push_back(s);
      end
    end
  endtask
endclass

[UVM] scaling tradeoff

  option A: 64 independent monitor components
    + isolation
    - more hierarchy overhead

  option B: one bank component with lane arrays
    + lower component overhead
    + easier aggregate stats
    - requires careful lane indexing discipline

Operational guardrails

Set practical limits and monitor hierarchy growth over time. Structural regressions should be visible in CI metrics.

# Example hierarchy summary extraction from log
rg "UVM_INFO.*COMPONENT_COUNT|BUILD_TIME_MS|CONNECT_TIME_MS" out/logs/nightly.log

# Track trend in dashboard
python3 tools/publish_perf_metrics.py out/metrics/hierarchy_metrics.json

Metrics worth tracking

• component count at end_of_elaboration

• build/connect phase elapsed time

• memory usage before run_phase

• per-test hierarchy variance over commits

Key takeaways

• Model behavior with components, bulk data with plain objects where possible.

• Avoid component explosion for homogeneous repeated structures.

• Track hierarchy and phase-construction metrics in CI.

• Refactor structure when build/connect overhead becomes dominant.

Common pitfalls

• Creating component-per-entry models for large static tables.

• Ignoring hierarchy growth until farm runtime suddenly regresses.

• Refactoring structure without preserving debug traceability.