Chipress

During test case development, the trial and error process often causes re-compilation and re-elaboration of the entire database, including testbench (TB), DUT, C-model, and sometimes even UPF if it is for power-aware verification. When the database is large, rebuilding everything is time consuming. There are several ways to optimize re-build time during test case development.

Split Compilation on TB and DUT

Compile TB and DUT separately, and elaborate them together. When there is only TB change, there is no need to re-compile DUT.

Compilation “Prune” Filelist

Chances are, not everything in the database is required for a test to work. Engineers can define a “prune” list, instructing simulators to skip compiling certain files and libraries.

Incremental Build Flow

Incremental build flow provides a form of incremental elaboration that reduces time to re-elaborate a design.

A test case is partitioned into two parts: non-changing (e.g., DUT) and changing parts (e.g., TB). In the initial scratch build, both parts are compiled and elaborated. In the subsequent incremental builds, only changing parts are re-compiled, re-elaborated, and eventually stitched with non-changing parts.

In incremental build flow, TB, DUT, C-model and UPF should each be categorized as one partition.

Many commercial simulators in the market support incremental build flow. Engineers should refer to user manuals for the exact incremental build flow settings.