SoC Architecture Review Checklist

An SoC architecture review is the point where a chip's architecture is checked by people who didn't design it, and a checklist is what stops that review from depending on anyone's memory. The serious problems in SoC projects fall into known categories: a bandwidth budget that assumed peak efficiency, a clock crossing nobody synchronized, a power domain that can't wake up, a DMA engine that can reach secure memory. This article gathers the questions from across this tutorial into one practical list, organized by area, with a short explanation of why each matters and how to run the review.

11 min read | Intermediate

What You'll Learn

• Run an SoC architecture review with a clear structure
• Check requirements, the memory map, interconnect and memory system
• Review clocks, resets, power, security, safety and test
• Record decisions and follow them through to tapeout

Why Use a Checklist

Reviewers are experienced, but a long meeting wears down attention, and the questions that get skipped are often the dull ones. Nobody finds "who can reach the firewall registers?" exciting, but a single missed answer can undo a chip's security. A checklist makes sure each question is at least asked.

Use this list for the main architecture review, for reviews of each subsystem, or as your own check before presenting a spec. Not every question applies to every chip: a small microcontroller has no DRAM and perhaps one clock domain. Skip what doesn't apply, and add the lessons your own projects have taught you.

Running a Review

1. Send material ahead. The architecture spec, the block diagram, the address map and the budgets, a few days before.
2. Invite the right people. Architects, an integration lead, verification, physical design, software, and for specific topics security, safety and test experts.
3. Start with the requirements. What must the chip achieve, in which use cases, and how will we know?
4. Walk the normal flows, then the corners. Boot, the main use cases, then power transitions, errors and attacks. Spend most of the time on the corners.
5. Record actions with an owner and a date. A review without actions was only a presentation.

Keep it about the design, not the designer. The aim is for everyone to find problems while they are still cheap to fix, and a reviewer who asks an awkward question is doing the project a favour.

Requirements and Use Cases

• Are the use cases written down, with numbers: resolutions, frame rates, data rates, battery life, cost?
• Does each requirement trace to a use case, and each block to a requirement? See From Use Cases to Requirements.
• Which use cases are worst for bandwidth, latency, power and heat, and are they analysed?
• What is out of scope, and does everyone agree?
• Which assumptions could change, and what would that affect?

Blocks and IP

• For each IP: who supplies it, is it proven in silicon on this process, and what are its deliverables? See Buy, Reuse or Build: Choosing IP.
• Are the IP configurations, versions and licence terms recorded?
• Has the hardware and software split been decided with numbers, for each accelerator?
• Does every block have an owner, a spec and a verification plan?

Memory Map and Registers

• Is there one address map, generated into documentation, RTL and software headers? See Memory Maps and Address Decoding.
• Do any regions overlap? What happens on an access to an unmapped address: an error response, or a hang?
• Is there room to grow each region in the next chip?
• Does every register have a reset value, an access type and a description, from one source?
• Can every manager reach exactly the regions it should, and no others?

Interconnect

• Is the topology, bus, crossbar or network-on-chip, justified by a traffic analysis?
• Does each manager support enough outstanding transactions for its bandwidth and latency?
• Which arbitration policy does each shared target use? Can any manager starve? See Arbitration and Quality of Service.
• Do deadline-driven managers, such as displays and audio, have priority or bandwidth guarantees?
• Can a slow or hung peripheral block the interconnect for everyone? Is there a timeout?
• Are error responses propagated to the requester, and reported?

Memory System

• Does the bandwidth budget use a realistic DRAM efficiency, not the peak? With how much margin? See Memory Bandwidth Budgets.
• Is the worst-case latency for deadline-driven managers analysed, including refresh and contention?
• Is the address mapping across channels, banks and rows chosen for the main access patterns?
• Which memories have ECC or parity, and is that decision recorded with its reason?
• Are SRAM sizes and the system cache justified by a model?

Interrupts, Timers and Multicore

• Does every interrupt source reach the controller, with its type, level or edge, documented?
• Are priorities and routing to cores defined? Can an interrupt wake every sleep state it needs to?
• Is there a watchdog, on a clock software can't stop, with a reset that records it fired?
• Which managers are coherent? How do non-coherent DMA engines and caches stay consistent?

Clocks and Resets

• Is every clock domain listed, with its source, frequency range and which blocks it drives? See Clock Architecture and Clock Domain Crossings.
• Is every crossing listed with its method: two-flop synchronizer, handshake or asynchronous FIFO?
• Are clock switches glitch-free, and can every clock be controlled in test mode?
• Is every reset source listed, with what it resets and in what order?
• Do resets assert asynchronously and deassert synchronously? Are reset domain crossings checked?
• What survives each kind of reset, such as fault records and the reason for the reset?

Power

• Are power domains, their states and their transitions listed, with the power intent written in a standard format? See Power Domains and Power Management.
• Does every signal leaving a switchable domain have isolation, and every crossing between voltages a level shifter?
• What state is retained in each sleep state, and how long does wake-up take?
• Are DVFS operating points defined, and is timing closed at each? See Dynamic Voltage and Frequency Scaling.
• Is there a power estimate for each use case, and a thermal limit?

Security

• Is there a written threat model with assets, attackers and what is out of scope? See Security Architecture.
• Does every manager on the interconnect, including DMA and debug, carry a security tag, and does every protected target check it?
• Where are keys stored, and can any software read them?
• Is debug locked in production, with a defined life-cycle and a signed unlock?
• Are the boot ROM's checks resistant to faults, and is the ROM code frozen and reviewed?

Safety and Reliability

• Is there a target safety level, and an FMEDA showing it is met? See Safety and Reliability.
• Does every alarm, from ECC, lockstep, monitors and watchdogs, reach a fault collection unit with a defined reaction?
• Are latent faults in the safety mechanisms themselves tested?
• Are lifetime, temperature and wear-out requirements stated and checked?

Test and Debug

• Are scan, MBIST, repair and JTAG planned, with coverage targets? See Design for Test at SoC Level.
• Is the test schedule within the package's and tester's power limits?
• Can software and debuggers see what they need: trace, performance counters, error logs?
• Are there chicken bits and spare cells for fixes after tapeout?

Package and Physical

• Is the floorplan consistent with the block diagram: are heavily connected blocks close together?
• Is the pad ring or bump map agreed with the package design, including power and ground counts?
• If there are several dies, are the cuts placed where traffic is low? See Chiplets, Packaging and System Partitioning.

Verification and Software

• Is there a verification plan for SoC-level features, with connectivity, register, scenario and system tests? See SoC-Level Verification Strategy.
• Is there a performance model, correlated with simulation, for the key use cases? See System Performance Modeling.
• When are emulation and FPGA prototypes available, and for which teams?
• Are the boot flow, drivers and bring-up software planned, and who writes them?

After the Review

The output of a review is a list of actions, each with an owner, a date and a definition of done. Track them in the same place as the rest of the project's readiness items, as Tapeout Readiness and SoC Sign-Off describes, and review them at each milestone. Some actions are decisions rather than changes: record what was decided and why, so the question isn't reopened in every meeting. Update the spec with the outcome, since the spec, not the meeting notes, is what other teams read.

Finally, feed the checklist itself. When a later review, verification or silicon finds a problem that the checklist should have caught, add the question. Over a few projects, the list becomes a record of the team's experience, which is its real value, and new team members learn from it quickly.

Common Mistakes