Expediting Simulation Turn-around Time with Incremental Build Flows
Rapid simulation turn-around time is critical for high-functioning SoC teams because it enables a tight feedback cycle that teams use to constantly validate progress. Whether the result is a failed compile, passing simulation or anything in between, the sooner you get that result, the sooner you get to the next step and closer you get to your ultimate objective: passing silicon.
A big part of enabling that rapid turn-around time is a fast and effective build flow. Questasim has a few different options for optimizing build flows depending on your application. Let’s go through a few of those options, starting with a simple lump sum build and working our way through options that enable an optimal SoC build flow.
Lump Sum Build
A lump sum build is the simplest build approach. All the inputs into one bucket; that bucket of stuff compiled into one library; one compiled library produces the optimized simulator input.
At the sub-system level, a lump sum build approach may be all you ever need. From a file server point-of-view, design and testbench infrastructure tend to be well contained so gathering tool inputs like filelists and test or configuration control is straightforward. Team sizes are relatively small at 2-5 people so dependency questions are easy to answer. Most importantly, we’re usually using seconds to measure build times. Back in my verification days I was always hyper-sensitive to long build times. But even for me, lump sum build times were often perfectly acceptable.
Partitioned Compile
A lump sum build is handy but it does reach its limit; usually seen by teams that tend toward regular design IP integration and testbench layering. Instead of compiling a single library, smart design and testbench partitioning extends past the architecture to include compiled libraries. Libraries are compiled independently, then collected into one optimized simulation input.
The value of a partitioned compile usually becomes apparent in larger sub-systems. There’s the immediate and obvious impediment of total compile time for a flat list of inputs. Avoiding any part of that can add up to minutes saved on each build. There’s also the engineering effort that goes into building the tool input where a shallow, distributed compile hierarchy helps to localize the knowledge and maintenance effort required.
Parallel Compile
With a smart library partitioning strategy, the next natural step to address build turn-around time is parallel compile. The performance value here is pretty easy to quantify: more cores in parallel means shorter build time overall. No picture required!
Pre-optimized Design Units (PDU)
The SoC level presents the next significant opportunity for build flow optimization in the form of pre-optimized design units. PDUs extend the idea of individual compiled libraries a step further where large design hierarchies are compiled and optimized independently. Those PDUs are then plugged in as-is to become part of the optimized input to the simulator.
PDUs are ideal for large or mature design hierarchies that change infrequently. For example, sub-system teams may drop new RTL on a weekly basis; the SoC verification team then turns the code drop into one or more PDUs. Remaining build cycles are dedicated to the testbench.
Elaboration Flow
The final step in an optimized build flow comes via the Questasim elaboration flow. Users create an elaboration file on an initial test run, then specify that file to avoid re-elaboration in subsequent runs.
The elaboration flow is particularly valuable in regressions because elaboration time multiplies across an entire test suite. It’s ideal in cases where your primary test controls rely on run-time decision making; a notable example being the +UVM_TEST plusarg input for UVM test selection. UVM specifically breaks the dependency between test selection and test infrastructure to avoid per test build. As a result, Questasim’s elaboration flow nicely serves performance sensitive UVM test regressions.
Your Optimal Build Flow
To summarize, Questasim users have a lot of flexibility when it comes to finding the build flow that’s right for them. Whether you’re verifying a small sub-system as a one-person team or an entire SoC with a much larger team, the combination of compiled library partitioning, PDUs, parallelism and elaboration flow are the tools you need for an optimal build flow and reduced build times.
We’ll leave it there for now. But I’ll be back in a follow-up with more details on how Questasim users use these approaches. Specifically, we’ll see Questasim’s new command line interface – qrun – and how it integrates approaches for your optimal build flow.
-neil
