Env Hierarchy Scaling: Naming and Sub-Env Expansion

Hierarchy growth model

As protocols and blocks grow, split one giant env into composable sub-envs with stable APIs. Keep hierarchy readable for humans and tools.

[ENV][UVM][CHECK] hierarchy scaling

env_top
  +-- fabric_env
  |    +-- req_agts[]
  |    +-- rsp_agts[]
  |    +-- fabric_sb
  |
  +-- ctrl_env
  |    +-- csr_agt
  |    +-- irq_agt
  |
  +-- system_cov
  +-- virtual_sqr

sub-envs publish stable top-level handles only

class env_top extends uvm_env;
  fabric_env f_env;
  ctrl_env   c_env;

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    f_env = fabric_env::type_id::create("f_env", this);
    c_env = ctrl_env::type_id::create("c_env", this);
  endfunction
endclass

• Keep sub-env interfaces small and versioned.

• Avoid deep hierarchy references from tests.

• Use naming patterns that survive refactors.

Key takeaways

• Sub-env layering enables independent evolution of protocol domains.

• Readable hierarchy names speed up every debug session.

Common pitfalls

• Monolithic env classes with mixed ownership and hidden coupling.

• Tests reaching into deep internals to set one knob.

Applied Patterns

Adopt explicit hierarchy naming and sub-env contracts before adding more protocols.

[ENV] naming convention

env_top
  f_env       // fabric domain
  c_env       // control domain
  sb_sys      // top-level system checks
  cov_sys     // system coverage
  v_sqr       // orchestration entry

rules:
  no anonymous generated names
  role-first identifiers
  index suffix for arrays only

function void dump_hierarchy();
  uvm_component c[$];
  this.find_all("*", c);
  foreach (c[i])
    `uvm_info("HIER", c[i].get_full_name(), UVM_LOW)
endfunction

• Hierarchy dumps should be part of smoke output.

• Names should encode role, not temporary implementation details.

• Document sub-env APIs near class declarations.

Integration Drilldown

When introducing a sub-env, compare hierarchy snapshots before and after to ensure only intended nodes changed.

[CHECK] hierarchy diff workflow

snapshot A: baseline branch
snapshot B: sub-env branch

verify:
  expected new nodes present
  old top-level handles still exposed
  no duplicate checker components

Key takeaways

• Hierarchy diffs prevent accidental duplication and broken handle exposure.

Common pitfalls

• Refactoring hierarchy without preserving published top-level handles.