We have a chip level design that DUT takes 90-95% of the runtime, but the testbench (TB) itself or TB to DUT interaction takes less than 10% of the runtime. Since this is at the late development cycle and is close to tape out, we don’t have resource or flexibility to use other verification options, such as emulation or re-partition the design to build multiple smaller TBs. What will be your suggestions to optimize the simulation environment to get a better runtime performance? The compile time takes very short, just the runtime is killing us.
Thank you!!
Richard
In reply to hctseng:
Please note your question is tool-related. You should talk to your tool provider.
In reply to chr_sue:
Thanks. But in general, other than talking to tool support guy, what will be your high level view and action take to deal with this kind of situation?
Richard
In reply to hctseng:
I don’t believe you can solve your issue by re-partitioning your design. In general there are certain reasons which are slowing doen your simulation.
The most important is the complexity of your design (gate count). Or if you have a FPGA and you are using UDPs. This slows down also your simulation.
Do you have SVA in your testbench?
In reply to chr_sue:
Ahh, just thought an ideas. Maybe we can black-box out some internal DUT’s blocks for simulation tests which are not targeting/exercising the blocks. Yeah, this could be one of the solutions. The idea is we can have multiple configurations for the same design, and we can still merge the coverage numbers from different configuration runs. We use this techniques in our lower level block-level sims, but I totally forgot that. SV provides the configuration construct. Yes this could solve my problem. Each configuration could have a set of tests and a set of assertions, covergroups, and cover properties. Since they are all under the same design hierarchy, coverage merge would not be a big issue.
Please let me know if you have other approaches/methods to solve this problem.
Thanks,
Richard
The most general way to think about this, is how can you reduce the number of events in your simulation?
You absolutely should insert log markers that help you track windows of time where the simulation is doing things you care about, versus where it’s just crunching away to setup for the next interesting thing. Then you need to find ways to accelerate or skip the windows of time that are not interesting.
If you have a block generating a lot of simulation events, but which ends up being don’t care for your test; then as you say, black boxing that block is one tool in the box. Or maybe just force the inputs of that block to a constant, which will remove the simulation activity.
You could try to use your tool’s checkpoint restore facility to save state after reset and start your tests from there.
You can use forces to load configuration values into registers, bypassing software based configuration.
You can use forces to setup for and skip past state machine sequences which you don’t care about, aka. you’ve already verified in some other test.
RTL can be ifdef’d to replace counters with shorter values. Programmable counters can be programmed to smaller values.
You can re-evaluate your test plan. Are you sending lots of huge transactions through the design, but 90% of that transaction time isn’t interesting? Can you use small transaction sizes instead? Can you ifdef the RTL to use smaller than actual sizes? Obviously don’t do all your testing that way.
There’s a lot of strategies, and no magic bullets. Use all approaches to the extent that they work and don’t hide real bugs.
In reply to warnerrs:
Thank you for your response. Yes there are some strategies I have not thought before. Maybe we really should partition the design to smaller ones from beginning. But I also thought to use the black box mode strategy, we can keep the top level sims and block level sims in the same sim environment, and probably most tests can be reused. If I can do another new testbench from scratch, do you recommend to use this black box strategy all the way thru?
Richard