stellarion_get_flow_graph [Pro · EDA]

Groups the indexed EDA categories into 18 canonical flow stages and emits a directed graph showing which procs/files own each stage and which transitions exist between stages. Captures the EDA-specific architecture in a way the generic call graph cannot, because the flow is staged (project_setup → synthesis → place → route → timing) rather than call-driven.

When to Use

• To visualize the EDA flow architecture of an unfamiliar codebase
• To find flow orchestrators — procs that span 3+ stages (often the right entry points to study)
• To detect missing stages (no verification calls in a synthesis-stage codebase is suspicious)
• Before a refactor — see which procs are doing too much across stages and need splitting
• To generate an architecture diagram from the graph data

Parameters

Stage map

The 18 flow stages, in canonical order:

Examples

Whole-workspace flow graph

Show me the EDA flow architecture of this codebase.

Calls with no filters; surfaces all active stages, their top members, and the strongest cross-stage transitions.

Scoped to one FPGA family

What does the Agilex flow look like?

Sets filePattern: "fpga_family/agilex".

Suppress single-caller transitions

Show only flow couplings shared by 5+ procs.

Sets minTransition: 5 to filter out one-off transitions that aren't architectural patterns.

Skip noise stages

Hide tiny stages with fewer than 10 calls.

Sets minCalls: 10.

Output Format

{
  "total_calls": 3327,
  "stages": [
    {
      "name": "ip_composition",
      "call_count": 2531,
      "member_count": 28,
      "categories": {
        "qsys_interface": 962,
        "qsys_parameter": 619,
        "...": 0
      },
      "members": [
        { "file": "...", "caller": "...", "call_count": 384 }
      ]
    }
  ],
  "transitions": [
    {
      "from": "project_setup",
      "to": "logging",
      "spanning_callers": 9
    }
  ]
}

A transition from → to means at least spanning_callers distinct callers have calls in both stages. The transition list is sorted by spanning count (highest first).

Tips

• Top-3 stages by call count = where most of the EDA activity lives. If your top is ip_composition, the codebase is IP-component-heavy (_hw.tcl files); if configuration dominates, it's Quartus-script-heavy (*_design_files.tcl).
• Procs spanning ≥3 stages are flow orchestrators. They're typically the right entry points to study but can also be refactor candidates if they're doing too much.
• A transition with spanning_callers ≥ 10 is structural; one with spanning_callers = 1 is incidental.
• Empty stages matter as much as full ones. No verification calls in a synthesis codebase suggests missing test-bench glue. No timing calls suggests SDC isn't indexed (check that .sdc files are in scope).
• Combine with stellarion_find_eda_calls to drill into a stage's specific call sites.