architecture v1.0.0A

Immutable. This exact content never changes and is served at /api/v1/blob/ec4a794b1016e90b.

---
name: architecture
description: >
  Microarchitecture exploration, PPA estimation, risk assessment, and architecture
  sign-off for digital chip design. Use when evaluating design candidates, estimating
  power/area/performance, assessing technical risk, or producing a microarchitecture
  document for handoff to RTL design.
version: 1.0.0
author: chuanseng-ng
license: MIT
allowed-tools: Read, Write, Bash
---

# 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.

## 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** — 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
| Issue | Fix |
|-------|-----|
| Spec section not mapped | Add to open questions; do not assume |
| Interface bandwidth unspecified | Request from product team before proceeding |
| Conflicting requirements | Flag as blocker; request resolution |

### 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
| Candidate | Freq Target | Area Est. | Power Est. | Risk  | Notes |
|-----------|-------------|-----------|------------|-------|-------|
| Option A  | 1GHz        | 3mm²      | 300mW      | Low   | ...   |
| Option B  | 2GHz        | 6mm²      | 700mW      | High  | ...   |

### 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.