Your SoC needs one data-moving block for three clients. The fabric is 64 bits wide at 800 MHz, so it can move 8 bytes × 800 MHz = 6.4 GB/s. The clients ask for different things:
Client | Traffic | What it cannot tolerate |
|---|---|---|
Camera | Bursty: 1.6 GB/s peak, 0.4 GB/s average, 256-byte bursts | Dropped lines when a burst waits too long |
Audio | Tiny: a few KB/s, one 64-byte transfer at a time | An underrun: each transfer must start within 2 µs of its request |
Crypto | Steady 0.8 GB/s of 128-bit blocks | Key or plaintext buffers reachable by the other clients |
Two facts are still open. The camera vendor may double the resolution in this tape-out. The security team has not decided whether crypto needs a physically separate path or whether address-range protection on a shared one is enough. Area, power, verification time and firmware effort are each owned by a different lead.
A: one shared engine | B: three dedicated engines | C: shared engine plus one secure channel | |
|---|---|---|---|
Structure | Descriptor rings per client, round-robin arbitration, one datapath | One small engine per client, each with its own fabric port | A and B mixed: camera and audio share an engine with QoS; crypto has its own channel and port |
Area (relative) | 1.0 | about 2.4 | about 1.5 |
Verification effort | High: sharing corner cases (fairness, starvation, back-pressure between clients) | Medium: one engine design reused three times, plus three ports to integrate | Medium to high: the shared part plus one simple channel |
Firmware | One driver, three rings | Three instances of one simple driver | Two drivers |
Security | Isolation only by address checks in shared logic | Physical isolation | Physical isolation for crypto |
The area and effort figures are planning estimates you would get from the leads, not measurements. The reasoning below depends on their order, not their exact values.
Peak demand is 1.6 + 0.8 + (audio, negligible) = 2.4 GB/s, 38% of the 6.4 GB/s fabric. Even if the camera doubles, 3.2 + 0.8 = 4.0 GB/s is 63%. Bandwidth does not separate the candidates.
A 256-byte burst on a 64-bit fabric is 32 beats, 32 cycles at 800 MHz = 40 ns. Under round-robin, an audio request waits at most for the bursts already granted to the other two clients: 2 × 40 ns = 80 ns, against a 2 µs limit. Option A meets the latency requirement, as long as burst length stays capped; that cap is now a requirement of its own and goes into the specification.
Only one requirement separates the candidates: crypto isolation. If the security team rules that address checks in shared logic are acceptable, A is cheapest and passes every number above. If they require a separate path, A is out. That question is the one to escalate, with a deadline, because every week without an answer is a week of design work on the wrong candidate.
Choose C, and record why. It meets bandwidth and latency with margin, gives crypto the physical isolation that the strictest security answer would demand, and costs about half of B's area. If security later accepts address checks, C degrades gracefully into A (the secure channel becomes a fourth ring) without a new architecture. Choosing A now would be cheaper only if security answers in its favour; choosing B pays for isolation the audio and camera paths do not need.
Decision record | |
|---|---|
Decision | C: shared camera/audio engine with QoS; separate crypto channel and fabric port |
Deciding constraint | Crypto isolation, still open; C satisfies its strictest answer |
Assumptions (owner) | Camera burst capped at 256 bytes (camera lead); fabric stays 64-bit at 800 MHz (SoC architect); audio limit 2 µs (audio lead) |
Reversible | QoS weights, ring sizes, burst cap: register settings |
Irreversible after floorplan | Number of fabric ports, physical isolation of crypto |
Review triggers | Security answer; camera resolution decision; any change to fabric width or clock |
Signal | Senior answer | Principal answer |
|---|---|---|
Framing | Compares the three options | Finds the one constraint that decides between them |
Numbers | Checks bandwidth | Checks bandwidth and latency, and turns the burst cap it relied on into a requirement |
Uncertainty | Picks an option | Picks the option that survives the strictest answer to the open question, and escalates that question with a date |
Ownership | Lists risks | Names an owner for each assumption |
Future | Stops at the decision | Says which facts would reopen it and which choices become irreversible when |
Yes, if the burst cap stays at 256 bytes: each burst is still 40 ns and audio still waits at most 80 ns. Doubling raises bandwidth to 4.0 GB/s (63% of the fabric), not burst length. If the camera team asks for longer bursts to reach the new rate, the latency check must be redone.
Revisit it, as the record says. A becomes the cheapest option that meets every requirement, so either fold the crypto channel into the shared engine as a fourth ring, if the floorplan still allows it, or keep C and record why the extra area is still worth it. Either way the decision changes because a recorded trigger fired, not because someone reopened the argument.
Because the audio latency guarantee depends on it. A larger burst lengthens the worst wait in proportion: 512 bytes would give 80 ns per burst and 160 ns worst case. Anything the decision relies on has to be written down as a requirement with an owner, or it will change without anyone checking the consequence.
Next: Round 2: When the Constraints Change moves four of these assumptions at once.
Arithmetic only: bandwidth (8 bytes x 800 MHz = 6.4 GB/s), burst time (32 beats at 800 MHz = 40 ns) and the 80 ns worst audio wait are calculations from the stated assumptions. Area and effort figures are planning estimates, not measurements. Nothing on this page was simulated.