An SoC architecture starts from use cases: concrete descriptions of what the product must do, such as "record 4K video for an hour" or "send a sensor reading every 10 ms for two years on a coin cell". The architect turns each use case into requirements, numbers that the hardware must meet, and those numbers drive every block choice. This article explains use cases, requirements and the attributes that make a requirement useful, derives a design limit from a requirement with a simple model and checks it against a simulation of a UART, and works through a power budget that turns a battery life into a limit on how long the processor may stay awake.
13 min read | Beginner to Intermediate
What You'll Learn
- Explain the difference between a use case, a requirement and a design choice
- Write requirements as numbers that a test can check, with source, owner and method
- Derive a hardware limit from a requirement with a simple model, and check it by measurement
- Turn a battery-life requirement into an energy and cycle budget
Use Cases First
A use case describes one thing the product does, from the user's point of view, with enough detail to estimate the work involved. A phone SoC might have dozens: video recording, a video call, gaming, standby with notifications, fast charging. Each one loads the chip differently. Video recording keeps the camera pipeline, the video encoder and DRAM busy; standby needs almost nothing except a low leakage current.
Use cases come from product managers, customers and the software team, and the architect's first job is to make them precise. "Video recording" is not enough; "4K at 60 frames per second, H.265, for 60 minutes, with the screen on" is something the architect can compute with. Use cases also come in combinations: during a video call, the camera, encoder, decoder, display, audio and modem all run at once, and the chip must handle the combination, not just each part alone.
From Use Case to Requirement
A requirement is a statement the finished chip must satisfy, written so that it can be tested. Good requirements are quantified, state their conditions, have a measurement method, and trace back to the use case they come from:
| Weak | Testable |
|---|---|
| The UART should be fast | A 256-byte burst leaves the chip within 200 µs at a 100 MHz clock |
| Low power in standby | Standby current below 50 µA at 25 °C with RAM retained |
| Enough memory bandwidth | 3.2 GB/s sustained DRAM bandwidth for the camera and display together |
| Boots quickly | First line of firmware output within 50 ms of the supply becoming stable |
Kinds of Requirements
Functional requirements say what the chip does: it has a UART, it boots from flash, it supports a given bus protocol. Non-functional requirements say how well, and they fall into recurring groups:
| Group | Examples |
|---|---|
| performance | throughput, latency, frames per second, interrupt response time |
| power and energy | active power per use case, standby current, battery life |
| area and cost | die size, package, number of pins, bill of materials |
| reliability and safety | lifetime, error rates, safety integrity levels for cars |
| security | secure boot, key storage, resistance to physical attacks |
| compliance | interface standards, temperature range, regulations |
Most architecture work is about the non-functional ones, because they decide the size and kind of every block: a UART exists in either case, but how fast it must be decides its design.
The Attributes of a Requirement
In a real project, every requirement is a row in a table or a requirements tool, with fields like these:
| Field | Example |
|---|---|
| ID | REQ-UART-003 |
| statement | a 256-byte burst leaves the chip within 200 µs at 100 MHz |
| source | use case UC-7, sensor data logging |
| owner | the architect responsible for peripherals |
| verification method | system simulation of a 256-byte burst, then measurement on silicon |
| priority | must have |
The links between rows form a traceability chain: every requirement traces up to a use case, and down to the design choice that meets it and the test that proves it. If a use case changes, traceability shows which requirements, blocks and tests are affected. Before tape-out, every row must show a passing result.
Quick Check
Q: "The interrupt controller must handle interrupts quickly." Rewrite it as a testable requirement.
Show Answer
For example: "From the timer interrupt being raised to the first instruction of its handler, at most 50 clock cycles, with no higher-priority interrupt pending." It names the event, the end point, a number with a unit, and the conditions, so a test can measure it.
Deriving a Design Limit
A requirement constrains the design, and a simple model turns it into a limit on a parameter. Take a sensor node that collects data and sends it in 256-byte bursts over its UART. The use case asks for a burst to finish within 200 µs, so that the next burst can start on time.
A UART on a small SoC sends each byte as 10 bits (a start bit, 8 data bits and a stop bit), and each bit lasts DIV clock cycles, where DIV is a register software can set. At 100 MHz a cycle is 10 ns, so a burst takes at least 256 x 10 x DIV x 10 ns. Setting that to 200 µs or less gives DIV of 7.8 or less. The reset value of 16 cannot meet the requirement; 4 should.
Checking the Limit by Measurement
A model is only a prediction, so the next step is to measure. A small test program sends 256 bytes as fast as the UART accepts them, polling the UART's status register before each byte. It was run in simulation at both divider settings. At DIV = 16 the burst took 412.8 µs, and at DIV = 4 it took 105.6 µs. DIV = 16 misses the 200 µs limit and DIV = 4 meets it.
The measurements agree with the model to within 1 percent at DIV = 16 and about 3 percent at DIV = 4. The difference is time the model leaves out: the program has to start, set the divider and wait for the last byte to finish. A model that is a few percent optimistic is normal, and the architect keeps a margin for it: here DIV = 4 meets 200 µs with almost half the time to spare.
The measurement shows a second effect that no requirement mentioned. While the UART sends, the processor does nothing but poll: at DIV = 16 it reads the status register about 13 times per byte. If another use case needs the processor during the burst, that becomes a new requirement on processor load, and its answer is architectural: a deeper UART buffer, an interrupt, or a DMA engine that feeds the UART by itself. Polling, Interrupts and DMA compares polling, interrupts and DMA. Discovering requirements that nobody wrote down is one of the most valuable results of early measurement.
Where Does This Happen?
System architects keep a requirements table that links every number to its use case, its owner and the test that checks it. Reviews go through the table row by row; requirements that nobody can test are sent back to be rewritten, and requirements without a source are questioned, because each one costs design and verification effort.
A Power Budget: From Battery Life to Cycles
Power requirements are derived the same way, from the use case down to numbers per block. Take the use case from the introduction: a sensor that takes a reading every 10 ms and must run for two years on a coin cell. The following numbers are assumptions chosen for this example, of the kind an architect would take from datasheets and early estimates:
| Assumption | Value |
|---|---|
| usable battery capacity (a typical coin cell) | 225 mAh |
| required lifetime | 2 years = 17,520 hours |
| current while asleep (clock stopped, RAM retained) | 2 µA |
| current while awake and computing at 100 MHz | 3 mA |
The battery can supply an average current of 225 mAh / 17,520 h = 12.8 µA over two years. Sleep alone uses 2 µA of that, leaving 10.8 µA for the time awake. If the chip is awake for a fraction f of the time, the average current is 2 µA + f x (3,000 µA - 2 µA). Setting this to 12.8 µA gives f = 10.8 / 2,998 = 0.36 percent.
average current allowed 225 mAh / 17,520 h = 12.8 µA awake fraction (12.8 - 2) / (3,000 - 2) = 0.36 % awake time per 10 ms 0.0036 x 10 ms = 36 µs cycles per wake-up 36 µs x 100 MHz = 3,600 cycles
So the requirement "two years on a coin cell" becomes "at most about 3,600 cycles of work per reading". That is a hard constraint on everything the processor does when it wakes: reading the sensor, processing the value, sending it. It also shows immediately what does not fit: sending a 256-byte burst by polling at DIV = 16 took about 41,000 cycles in the test above, more than eleven times the budget. Either the data must be sent less often, or the UART must send while the processor sleeps, using DMA or a UART that runs from its own small clock.
Budgets like this are made for every important use case. They tell each block team how much power it may use, and they show early which use cases are at risk.
Quick Check
Q: In the power budget, the sleep current turns out to be 5 µA instead of 2 µA. How does the cycle budget per reading change?
Show Answer
The awake budget drops to 12.8 - 5 = 7.8 µA, so f = 7.8 / 2,995 = 0.26 percent: 26 µs or about 2,600 cycles per 10 ms. A small change in sleep current costs over a quarter of the processing budget, which is why sleep current is often the hardest power requirement.
Budgets and Margins
A requirement on the whole chip must be divided among its blocks before anyone can design them. A budget is that division: of the 12.8 µA average current in the example above, so much goes to the processor, so much to the sensor interface, so much to leakage of the memories. Area, latency and power are all budgeted this way, and each block team receives its share as its own requirement.
Every budget keeps a margin, a reserve that is not given to any block. Early numbers are estimates; models leave things out, as the UART measurement showed; and designs grow as features are added. A common practice is to hold back a margin at the start of a project and release it in steps as estimates turn into measurements. A budget with no margin left early in a project is a warning sign: the first surprise will break it. A budget with a large margin left at the end means the chip could have been smaller, cheaper or faster, so margins are reviewed at each milestone.
Budgets also make trade-offs visible. If the processor needs more cycles per reading than its share allows, the architect can see exactly which other share must shrink, or which requirement must change, instead of discovering the problem when the product is tested.
When Requirements Conflict
Requirements pull against each other. A faster UART meets the burst deadline but draws more power while sending; a larger buffer reduces processor load but costs area; a higher clock meets a performance target but breaks the power budget. Architects resolve such conflicts with the numbers: they model each option against all the affected requirements, and when no option meets everything, they go back to the product team with the trade-off quantified. Priorities, such as "must have" and "should have", decide which requirement gives way. Conflicts found this way, on paper, are cheap; the same conflict found after tape-out can sink a product.
Common Mistakes
Mistake #1: Writing requirements that cannot be tested
"Fast", "low power" and "enough" cannot pass or fail. Every requirement needs a number, a unit and the conditions it holds under, or it will be argued about until tape-out.
Mistake #2: Sizing a block from one use case
Use cases run at the same time: a video call needs the camera, the encoder, the display and the modem together. Requirements must cover the combinations the product allows, not each use case alone.
Mistake #3: Trusting the model without measuring
Simple models leave things out. Check every derived limit against a simulation or a prototype, and keep a margin for what the model misses.
Practice Exercise
Challenge: A Tighter Requirement
(a) The product team now asks for each 256-byte burst to leave within 100 µs. Derive the largest divider that meets it with the model, then use the measured DIV = 4 result to decide whether DIV = 4 is good enough. (b) In the power budget above, the team wants three years instead of two, with everything else unchanged. What is the new cycle budget per 10 ms reading?
Hint
(a) Solve 256 x 10 x DIV x 10 ns <= 100 µs for DIV. (b) Three years is 26,280 hours.
Solution
(a) 256 x 10 x DIV x 10 ns <= 100 µs gives DIV <= 3.9, so the largest whole divider is 3. DIV = 4 fails twice over: the model gives 102.4 µs, and the measurement 105.6 µs (10,560 cycles at 100 MHz). The requirement needs DIV = 3 or smaller, and its margin should be checked by measurement too. (b) 225 mAh / 26,280 h = 8.56 µA average. Awake budget 8.56 - 2 = 6.56 µA, f = 6.56 / 2,998 = 0.219 percent, which is 21.9 µs per 10 ms, about 2,190 cycles at 100 MHz: 40 percent less than for two years.
Summary
- Use cases describe what the product does; requirements turn them into testable numbers with a source, owner and verification method.
- Requirements are functional or non-functional (performance, power, area, reliability, security, compliance) and trace from use case to design choice to test.
- A simple model turns a requirement into a design limit: a 200 µs burst of 256 bytes needs a UART divider of 7.8 or less, and measurement confirms the model within a few percent.
- A battery-life requirement becomes a cycle budget: two years on 225 mAh, with the stated currents, allows about 3,600 cycles per 10 ms.
- Measurements reveal requirements nobody wrote down, and conflicts are resolved with numbers and priorities.
