WP_Term Object
(
    [term_id] => 159
    [name] => Siemens EDA
    [slug] => siemens-eda
    [term_group] => 0
    [term_taxonomy_id] => 159
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 635
    [filter] => raw
    [cat_ID] => 159
    [category_count] => 635
    [category_description] => 
    [cat_name] => Siemens EDA
    [category_nicename] => siemens-eda
    [category_parent] => 157
)
            
SemiWiki Banner
WP_Term Object
(
    [term_id] => 159
    [name] => Siemens EDA
    [slug] => siemens-eda
    [term_group] => 0
    [term_taxonomy_id] => 159
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 635
    [filter] => raw
    [cat_ID] => 159
    [category_count] => 635
    [category_description] => 
    [cat_name] => Siemens EDA
    [category_nicename] => siemens-eda
    [category_parent] => 157
)

Faster Time to RTL Simulation Using Incremental Build Flows

Faster Time to RTL Simulation Using Incremental Build Flows
by Daniel Payne on 01-31-2022 at 10:00 am

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.

lump sum build min
Lump Sum Build

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.

partitioned compile min
Partitioned Compile

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.

PDU min
Pre-optimized Design Units (PDU)

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.

Elaboration Flow min
Elaboration Flow

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.

Related Blogs

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.