I’ve been following Neil Johnson on Twitter and LinkedIn for several years now, as he has written and shared so much about the IC design and verification process, both as a consultant and working at EDA vendors. His recent white paper for Siemens EDA caught my eye, so I took the time to read through the 10 page document to learn more about the build flow choices now available to SoC teams.
Modern RTL languages most be compiled before they are ready to simulate, so turnaround time is always important. For engineering teams using functional simulation from Siemens EDA, they use the Questa simulator, and there are a few ways to approach build flows.
Lump Sum Build Flow
The simplest build flow has all of your input files (modules, packages, Testbench, DUT) compiled into a single library.
This approach works efficiently for design complexity up to the sub-system level, and teams with a handful of engineers can handle any dependency issues. Typical build times are on the order of seconds, so it’s a good method.
Partitioned Compile
If your SoC team uses much design IP integration and testbench layering, then consider using the partitioned compile, where libraries are compiled separately and then gathered into a single simulation input.
As your sub-systems grow larger in size, then compile times becomes faster by moving from the lump sum to a partitioned compile.
Parallel Compile
By partitioning your library and using more cores in parallel, then build times are further reduced, so it’s the classic tradeoff of number of EDA licenses versus time.
Pre-optimized Design Units (PDU)
Parts of an SoC hierarchy can be compiled independently into PDUs, then used as input to simulation. These PDUs are areas of the design that are rarely changing, so this avoids having to re-compile a stable design area. With this build approach you are only compiling the areas of code where changes have been made.
Elaboration Flow
Elaboration is where modules are bound to module instances, model hierarchy is built, parameter values are computed, hierarchical names get resolved, and nets are connected. With Questa you create an elaboration file on the first test run then just re-use that file in the following runs.
Command Line Front-end
Questa users have the Qrun tool to compile their designs, so here’s how it works for each of the build flow choices.
Lump Sum Build
Specify your testbench files and design files, then qrun will compile, optimize and simulate.
qrun -f testbench_files.f -f design_files.f
Partitioned Compile
To separate testbench and design files in the partitioned compile build flow, use qrun with this syntax:
qrun -makelib testbench_library -f testbench_files.f -end \
-makelib design_library -f design_files.f -end
Parallel Compile
Compiling in parallel across multiple cores with Qrun looks just like the partitioned compile with one extra option:
qrun -makelib testbench_library -f testbench_files.f -end \
-makelib design_library -f design_files.f -end \
-parallel
Pre-optimized Design Units (PDUs)
Using Qrun for the PDU build flow adds the makepdu option:
qrun -makelib testbench_library -f testbench_files.f -end \
-makelib design_library -f design_files.f -end \
-makepdu design_top design_library.top -L design_library -end \
-parallel
Elaboration Flow
The first time through the elaboration flow creates an elaboration file, then subsequent runs reuse the elaboration file:
qrun -makelib testbench_library -f testbench_files.f -end \
-makelib design_library -f design_files.f -end \
-makepdu design_top design_library.top -L design_library -end \
-parallel \
-elab elaboration.output -do “quit”
qrun -load_elab elaboration.output -do “run -all; quit”
Summary
Build flows are an important part of what SoC teams do in getting a design completed and verified in the shortest time possible. With Questa there are multiple build flows to choose from, depending on the complexity and composition of your project. The Qrun command line tool supports each build flow choice with a simple syntax, and it’s even smart enough to incrementally compile only the files that have changed or when dependencies change.
Read the complete 10 page White Paper online here.
