A NanoSoC boot is 1.2 million cycles and simulates in minutes; a million DMA jobs is 216 million cycles and simulates in half a day. At some workload size the simulator stops being the right tool, and the chip has to run on faster hardware before silicon exists. This topic is the integrator's view of that move: when it pays, what in NanoSoC must be replaced or rewritten to fit the platform, and what the platform can no longer show you. It is conceptual and vendor-neutral, and every speed and build time in it is an illustrative teaching value. The planted bugs it refers to are listed in the NanoSoC tour. For the platforms themselves see the verification-first-principles pages linked from each lesson; for debugging on them see the Hardware Debug lesson.
Lesson | After it you can... |
|---|---|
Compute the break-even workload for a faster platform and decide which NanoSoC tests move. | |
List what NanoSoC must replace or rewrite to run on a prototype, and what each change hides. | |
Size a trace window, connect the pins to host models, and say which planted bugs each platform can find. |
Suggested order: top to bottom. The break-even first, because it decides whether to move at all; then the design changes, which are the price of moving; then visibility, which is what the price buys back and what it does not.
They are tiny, they need full visibility to name the failing register, and a rebuild to change a probe costs hours on a prototype against seconds in simulation. Speed only pays when the workload is long.