Architecture

Skill: Architecture Evaluation

Invocation

• If invoked by a user presenting a design task: immediately spawn the digital-chip-design-agents:architecture-orchestrator agent and pass the full user request and any available context. Do not execute stages directly.
• If invoked by the architecture-orchestrator mid-flow: do not spawn a new agent. Treat this file as read-only — return the requested stage rules, sign-off criteria, or loop-back guidance to the calling orchestrator.

Spawning the orchestrator from within an active orchestrator run causes recursive delegation and must never happen.

Pre-run Context

Before executing or advising on any stage, read the following files if they exist:

1. memory/architecture/knowledge.md — known failure patterns, successful tool flags, PDK/tool quirks. Incorporate its guidance into every stage decision. If absent, proceed without it.
2. memory/architecture/run_state.md — current run identity (run_id, design_name, tool, last_stage). Use this to resume correctly after interruption. If absent, a new run is starting; the orchestrator will create this file before the first stage.

This pre-run read applies whether this skill is loaded by a user or called by the orchestrator mid-flow. It ensures the fix database is consulted before any diagnosis step.

Purpose

Guide the full microarchitecture evaluation process from product specification through to a signed-off microarchitecture document ready for RTL handoff. Covers specification decomposition, candidate architecture exploration, performance and PPA modelling, risk assessment, and sign-off.

---

Supported EDA Tools

Open-Source

• gem5 (gem5) — full-system micro-architectural simulator for performance modelling
• McPAT (mcpat) — processor power, area, and timing estimator
• CACTI (cacti) — SRAM/cache power and area estimator
• Python estimation scripts (python3 estimate.py) — custom PPA models

Proprietary

• Synopsys Platform Architect (dialect synopsys) — IP-level performance and power exploration
• ARM Performance Models (dialect arm) — cycle-accurate ARM subsystem models
• Cadence Virtual System Platform (VSP) (dialect cadence) — SoC-level virtual prototyping

---

Stage: spec_analysis

Domain Rules

1. Classify every requirement: functional, performance, power, area, interface, safety/security
2. Identify under-specified areas and flag as open questions for the product team
3. Map each use case to required hardware blocks (datapath, control, memory, IO)
4. Extract all interface requirements with protocols (AXI, PCIe, USB, Ethernet, etc.)
5. Identify safety/security requirements (ISO 26262, FIPS, CC) if applicable
6. Assign priority: Must-Have / Should-Have / Nice-to-Have
7. Produce a structured requirements document before any architecture work begins

QoR Metrics to Evaluate

• Requirements coverage: 100% of spec sections mapped to at least one requirement
• Ambiguity count: all unresolved items captured in open questions list
• Interface completeness: all external interfaces named with protocol and bandwidth

Common Issues & Fixes

Output Required

• Structured requirements document (JSON or Markdown)
• Interface list with protocols and bandwidths
• Open questions list

---

Stage: arch_exploration

Domain Rules

1. Generate minimum 3 candidate architectures: conservative, balanced, aggressive
2. Evaluate pipeline depth trade-offs (deeper = higher frequency, more area/power)
3. Evaluate parallelism: SIMD, superscalar, spatial unrolling — with area/power cost
4. Cache/memory hierarchy: size, associativity, latency vs area trade-off per use case
5. Interconnect topology: bus, crossbar, NoC — evaluate bandwidth vs complexity
6. Consider IP reuse: identify hard macros or licensed IPs before designing custom
7. Document all assumptions for each candidate explicitly
8. Produce a trade-off matrix comparing all candidates

Trade-off Matrix Template

QoR Metrics to Evaluate

• Minimum 3 candidates explored with distinct trade-off profiles
• Each candidate: performance estimate within 20% of target
• Single recommended candidate with clear quantitative justification

Output Required

• Trade-off matrix with all candidates
• Recommended candidate with quantitative justification
• Assumptions and risk summary per candidate
• The same matrix persisted to design_state.architecture.candidates[], one entry per candidate — rejected ones included, each with a rejection_reason — so a downstream refinement can resume from it (architecture-orchestrator Behaviour Rule 10)

---

Stage: perf_modelling

Domain Rules

1. Use analytical models (Amdahl, Roofline) for initial estimates
2. Build TLM/SystemC or Python models for complex pipelines
3. Model all bottlenecks: compute, memory bandwidth, IO throughput
4. Sweep key parameters: clock frequency, parallelism, cache size
5. Validate with representative workloads from the use-case list
6. Include best/typical/worst-case scenarios
7. Flag any model assumption that has not been validated
8. Refinement mode (entered here when architecture.refinement_needed is set): the downstream measurement in refinement_request.measured replaces the model estimate for the selected candidate. Recalibrate the model so it reproduces that measurement, then re-score every persisted candidate with the recalibrated model before choosing one. A model that still predicts the old estimate is uncalibrated, and its scores are not evidence.

QoR Metrics to Evaluate

• Throughput: meets or exceeds target by ≥ 10% margin
• Latency: meets target at worst-case workload
• Memory bandwidth: does not exceed DRAM/SRAM ceiling
• Model confidence: HIGH / MEDIUM / LOW

Output Required

• Performance model (script or spreadsheet)
• Throughput/latency results per use case
• Sensitivity analysis
• Comparison table: modelled vs target

---

Stage: power_area_estimation

Domain Rules

1. Area: use technology library scaling data (gates/mm² at target node)
2. Dynamic power: P = α × C × V² × f (get activity factor from use cases)
3. Leakage: estimate from library characterisation at target Vt mix
4. Memory area: use SRAM compiler estimates for given depth × width
5. IO pad area: per pad ring design rules
6. Apply 15–20% margin — RTL is never minimal
7. Flag immediately if any estimate exceeds 80% of budget

Clock Gating Opportunity Analysis

Perform this analysis using the activity factors already collected for dynamic power:

1. For each identified clock domain, record its activity factor α derived from the use-case workload sweep (gem5 simulation or analytical model).

2. Classify each domain using thresholds from design_state.constraints.power.activity_factors (defaults: {"default": 0.15, "high": 0.40}):

   • α < activity_factors.default (default: 0.15) — high gating opportunity: clock gating will save > 30% dynamic power for that domain; flag as a must-have RTL requirement.
   • activity_factors.default ≤ α < activity_factors.high (defaults: 0.15–0.40) — moderate gating opportunity: clock gating recommended; flag as should-have RTL requirement.
   • α ≥ activity_factors.high (default: 0.40) — always-active: no gating benefit; document as always-on.

3. Produce a clock_power_budget table (one row per domain):

   Domain	Frequency	α (activity)	Est. Clock Power (mW)	Gating Class
   core	1 GHz	0.08	45	high
   dsp	500 MHz	0.55	30	always-on

4. McPAT clocking component already models clock network power — ensure the frequency-sweep input reflects per-domain frequencies, not a single global clock.

5. Include the clock_power_budget table in the hand-off package to RTL design. The RTL agent will use it to target ICG (Integrated Clock Gate) insertion.