Simulation-overhead benchmarks: check the workload actually runs long enough; scaling cycles doesn't help if the testbench hits $finish

When measuring tracing overhead as (traced CPU - untraced CPU) / untraced CPU, a very short untraced baseline makes the ratio meaningless: a 0.03 s baseline turned a modest absolute cost into an '11x overhead'. A common cause is that the testbench or firmware ends on its own ($finish after the program completes), so asking for more cycles changes nothing. Before timing, check that each design's no-trace run lasts at least a few seconds (we used 5 s), and record the cycles actually simulated, not the cycles requested. If it's too short, extend the workload: loop the program or raise the firmware's iteration count, and record that as a workload deviation. For runs that stay short, report absolute numbers instead (CPU per stored value change, bytes) and label the baseline as too short, rather than quoting a percentage or multiple.