Architecture

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 — IP-level performance and power exploration
• ARM Performance Models — cycle-accurate ARM subsystem models
• Cadence Virtual System Platform (VSP) — 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

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

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

QoR Metrics to Evaluate

• Area estimate: < 80% of budget
• Dynamic power: < 80% of budget
• Leakage: < 15% of total estimated power
• Confidence: HIGH / MEDIUM / LOW

Output Required

• Area breakdown by block
• Power breakdown: dynamic, leakage, per domain
• Margin analysis vs targets

Stage: risk_assessment

Domain Rules

1. Risk categories: schedule, technical feasibility, IP availability, tool support, verification complexity, power closure, manufacturing yield
2. Score every risk: Probability (1–5) × Impact (1–5) = Risk Score
3. Risk score ≥ 15: classified HIGH — must have mitigation plan before sign-off
4. IP risks: verify availability, licensing timeline, silicon-proven status
5. Tool risks: verify EDA tool certification for chosen technology node
6. Verification risks: flag if testbench complexity > 6 months estimated effort
7. Every risk must have an assigned owner

QoR Metrics to Evaluate

• No unmitigated HIGH risks at sign-off
• All risks: assigned owner and mitigation plan
• Schedule risk assessed vs team capacity

Output Required

• Risk register (ID, description, score, mitigation, owner)
• Top 5 risks for management review

Stage: arch_signoff

Sign-off Checklist

• All Must-Have requirements addressed
• Performance targets met in model (≥ 10% margin)
• Power and area within budget (< 80%)
• All HIGH risks have mitigation plans and owners
• Interface specifications complete and agreed
• Memory map defined
• Clock domains identified; CDC strategy agreed
• Reset strategy defined
• DFT strategy agreed
• Verification strategy agreed
• RTL coding guidelines documented
• Hand-off package complete for RTL team

Output Required

• Signed-off microarchitecture document
• Final trade-off decision record
• RTL design guidelines
• Hand-off package

Memory

Write on stage completion

After each stage completes (regardless of whether an orchestrator session is active), write or overwrite one JSON record in memory/architecture/experiences.jsonl keyed by run_id. This ensures data is persisted even if the flow is interrupted or called without full orchestrator context.

Use run_id = architecture_<YYYYMMDD>_<HHMMSS> (set once at flow start; reuse on each stage update). Set signoff_achieved: false until the final sign-off stage completes.