The NanoSoC link table is a promise: 361.4 MB/s per stream, 125 ns per fast register read, 750 ns per 64-word job. This topic turns the promise into a method: recompute the table as a runnable model, recheck every latency link by link, then confirm both in simulation with traffic generators and performance counters. The method is chip-level performance verification against bandwidth budgets: a predicted number first, then a measured one, then a walk from any miss down to its link.
Lesson | After it you can... |
|---|---|
Reproduce every row of the NanoSoC link table from width, clock and burst efficiency, and see the model fail when a clock changes. | |
Recompute every NanoSoC latency, the DMA job formula and the boot sum, and see which boot steps depend on which latency. | |
Size counters, drive traffic, and read a miss down to its link. |
Suggested order: top to bottom. The model first, because simulation without a predicted number is just activity; latency second, because the job formula depends on it; counters third, where the two meet the lab. The full verification flow this method plugs into lives in the verification and bring-up section.
Neither yet: the budget assumes 16-beat bursts with one bubble per burst, so first check the burst lengths the generator actually issued. A miss with short bursts is a test artefact, not a design failure.