Automation has develop into the spine of recent SystemVerilog/UVM verification environments. As designs scale from block-level modules to full system-on-chips (SoCs), engineers rely closely on scripts to orchestrate compilation, simulation, and regression. The effectiveness of those automation flows instantly impacts verification high quality, turnaround time, and staff productiveness.
For a few years, the Makefile has been the instrument of selection for managing these duties. With its rule-based construction and large availability, Makefile provided an easy option to compile RTL, run simulations, and execute regressions. This strategy served nicely when testbenches have been comparatively small and configurations have been easy.
Nevertheless, as verification complexity exploded, the constraints of Makefile have develop into more and more obvious. Mixing execution guidelines with hardcoded take a look at configurations results in fragile scripts which are tough to scale or reuse throughout initiatives. Debugging syntax-heavy Makefiles usually takes extra effort than writing new checks, diverting consideration from protection and practical objectives.
These challenges level towards the necessity for a extra modular and human-readable different. YAML, a structured configuration language, addresses many of those shortcomings when paired with Python for execution. Earlier than diving into this answer, it’s essential to first look at how as we speak’s flows function and the place they battle.
Present situation and challenges
In most verification environments as we speak, Makefile stays the default selection for controlling compilation, simulation, and regression. A single Makefile usually governs your entire move—compiling RTL and testbench sources, invoking the simulator with tool-specific choices, and managing regressions throughout a number of testcases. Whereas this strategy has been serviceable for smaller initiatives, it reveals clear limitations as complexity will increase.
Under is a top level view of key challenges.
- Configuration administration: Check lists are generally hardcoded in textual content or CSV recordsdata, with seeds, defines, and gear flags scattered throughout a number of scripts. Updating or reusing these settings throughout initiatives is cumbersome.
- Readability and debugging: Makefile syntax is compact however cryptic, which makes debugging errors non-trivial. Even small adjustments can cascade into construct failures, demanding vital engineer time.
- Scalability: As testbenches develop, including new testcases or regression suites shortly bloats the Makefile. Managing lots of of checks or regression campaigns turns into unwieldy.
- Software dependence: Every Makefile is often tied to a particular simulator, as an illustration, VCS, Questa, and Xcelium. Porting the move to a unique instrument requires main rewrites.
- Restricted reusability: Groups usually reinvent comparable flows for various initiatives, with little alternative to share or reuse scripts.
These challenges shift the engineer’s focus away from verification high quality and protection objectives towards the mechanics of scripting and gear debugging. Subsequently, the business wants a cleaner, modular, and extra moveable option to handle verification flows.
Makefile-based move
A standard Makefile-based verification move facilities round a single file containing a number of targets that deal with compilation, simulation, and regression duties. See the consultant construction beneath.
This strategy gives clear strengths: rapid familiarity with software program engineers, no further instrument necessities, and easy dependency administration. For small groups with secure instrument chains, this simplicity stays compelling.
Nevertheless, vital challenges emerge with scale. Cryptic syntax turns into problematic; escaped backslashes, shell expansions, and dependencies create arcane scripting somewhat than readable configuration. Debug cycles lengthen with cryptic error messages, and modifications require deep Maker experience.
Software coupling is clear within the above construction—compilation flags, executable names, and runtime arguments are VCS-specific. Supporting Questa requires duplicating guidelines with totally different syntax, creating synchronization challenges.
So, upkeep of overhead grows exponentially. Including checks requires a number of modifications, parameter adjustments demand cautious shell escaping, and regression administration shortly outgrows Maker’s capabilities, forcing hybrid scripting options.
These drawbacks encourage the seek for a extra human-readable, reusable configuration strategy, which is the place YAML’s structured, declarative format gives compelling benefits for contemporary verification flows.
YAML-based move
YAML (YAML Ain’t Markup Language) supplies a human-readable information serialization format that transforms verification move administration via structured configuration recordsdata. Not like Makefile’s crucial instructions, YAML makes use of declarative key-value pairs with intuitive indentation-based hierarchy.
See beneath this YAML configuration construction that replaces advanced Makefile logic:
The modular construction turns into instantly obvious via organized listing hierarchies. As proven in Determine 1, a well-structured YAML-based verification surroundings separates configurations by operate and scope, enabling totally different staff members to change their respective domains with out conflicts.
Determine 1 The block diagram highlights the YAML-based verification listing construction. Supply: ASICraft Applied sciences
Block-level engineers handle component-specific take a look at configurations, IP1 andIP2, whereas integration groups concentrate on pipeline and regression administration. As a substitute of monolithic Makefiles, groups can set up configurations throughout targeted recordsdata: construct.yml for compilation settings, sim.yml for simulation parameters, and numerous test-specific YAML recordsdata grouped by performance.
Superior YAML options like anchors and aliases eradicate configuration duplication utilizing the DRY (Don’t Repeat Your self) precept.
Software independence emerges naturally since YAML accommodates solely configuration information, not tool-specific instructions. The identical YAML recordsdata can drive VCS, Questa, or XSIM simulations via applicable Python parsing scripts, eliminating the necessity for a number of Makefiles per instrument.
After all, YAML alone doesn’t execute simulations; it wants a bridge to EDA instruments. That is achieved by pairing YAML with light-weight Python scripts that parse configurations and generate applicable instrument instructions.
Implementation of YAML-based move
The transition from YAML configuration to precise EDA instrument execution follows a scientific four-stage course of, as illustrated in Determine 2. This implementation addresses the standard verification problem the place engineers spend extreme time writing advanced Makefiles and managing instrument instructions as an alternative of specializing in verification high quality.
Determine 2 The YAML-to-EDA part bridges the YAML configuration. Supply: ASICraft Applied sciences
YAML recordsdata function complete configuration containers supporting numerous verification wants.
- Venture metadata: Venture title, descriptions, and model management
- Software configuration: EDA instrument choice, licenses, and model specs
- Compilation settings: Supply recordsdata, embody directories, definitions, timescale, and tool-specific flags
- Simulation parameters: Software flags, snapshot paths, and log listing buildings
- Check specs: Check names, seeds, plusargs, and protection choices
- Regression administration: Check lists, reporting codecs, and parallel execution settings
Determine 3 Here’s a view of Python YAML parsing workflow phases. Supply: ASICraft Applied sciences
The Python implementation demonstrates the entire move pipeline. Beginning with a easy YAML configuration:
The Python script hundreds and processes the configuration beneath:
When executed, the Python script produces clear output, exhibiting the command translation, as illustrated beneath:
The whole processing workflow operates in 4 systematic phases, as detailed in Determine 3.
- Load/parse: The PyYAML library converts YAML file content material into native Python dictionaries and lists, making configuration information accessible via normal Python operations.
- Extract: The script accesses configuration values utilizing dictionary keys, retrieving instrument names, file lists, compilation flags, and simulation parameters from the structured information.
- Construct instructions: The parser intelligently constructs tool-specific shell instructions by combining extracted values with applicable syntax for the goal simulator (VCS or Xcelium).
- Show/execute: Generated instructions are proven for verification or instantly executed via subprocess calls, launching the precise EDA instrument operations.
This implementation creates true tool-agnostic operation. The identical YAML configuration generates VCS, Questa, or XSIM instructions by merely updating the instrument specification. The Python translation layer handles all syntax variations, making flows moveable throughout EDA environments with out configuration adjustments.
The whole pipeline—from human-readable YAML to executable simulation instructions—demonstrates how trendy verification flows can prioritize engineering productiveness over infrastructure complexity, enabling groups to concentrate on take a look at high quality somewhat than instrument mechanics.
Comparability: Makefile vs. YAML
Each approaches have clear strengths and weaknesses that groups ought to consider primarily based on their particular wants and constraints. Desk 1 supplies a scientific comparability throughout key analysis standards.
Desk 1 See the move comparability between Makefile and YAML. Supply: ASICraft Applied sciences
The place Makefiles work higher
- Easy initiatives with secure, unchanging necessities
- Small groups already conversant in Make syntax
- Legacy environments the place altering infrastructure is dangerous
- Direct execution wants required for fast debugging with out intermediate layers
- Incremental builds the place dependency monitoring is essential
The place YAML excels
- Rising complexity with a number of take a look at configurations
- Multi-tool environments supporting totally different simulators
- Workforce collaboration the place readability issues
- Frequent modifications to check parameters and configurations
- Lengthy-term upkeep throughout a number of initiatives
The truth is that the majority groups begin with Makefiles for simplicity however ultimately hit scalability partitions. YAML approaches require extra expansive preliminary setup however pay dividends as initiatives develop. The choice usually comes down as to if you’re optimizing for rapid simplicity or long-term scalability.
For established groups managing advanced verification environments, YAML-based flows sometimes present higher return on funding (ROI). Nevertheless, groups ought to think about sensible elements like migration effort and present instrument integration earlier than making the transition.
Selecting between Makefile and YAML
The challenges with conventional Makefile flows are clear: cryptic syntax that’s onerous to learn and modify, tool-specific configurations that don’t port between initiatives, and upkeep overhead that grows with complexity. As verification environments develop into extra subtle, these limitations eat useful engineering time that ought to concentrate on precise take a look at growth and protection objectives.
The YAML-based flows handle these basic points via human-readable configurations, tool-independent designs, and modular buildings that scale naturally. Groups can merely describe verification intent—run 100 iterations with protection—whereas the move engine handles all instrument complexity mechanically. The identical strategy works from block-level testing to full-chip regression suites.
Key advantages realized with YAML
- Sooner onboarding: New staff members perceive YAML configurations instantly.
- Lowered upkeep: Configuration adjustments require easy textual content edits, not scripting.
- Higher collaboration: Clear syntax eliminates the “Makefile knowledgeable” bottleneck.
- Software flexibility: Swap between VCS, Questa, or XSIM with out rewriting flows.
- Venture portability: YAML configurations transfer cleanly between totally different initiatives.
The selection between Makefile and YAML approaches in the end is determined by mission complexity and staff objectives. Easy, secure initiatives could proceed benefiting from Makefile simplicity. Nevertheless, groups managing rising take a look at suites, a number of instruments, or frequent configuration adjustments will discover YAML-based flows offering higher long-term returns on their infrastructure funding.
Meet Sangani is ASIC verification engineer at ASICraft Applied sciences.
Hitesh Manani is senior ASIC verification engineer at ASICraft Applied sciences.
Shailesh Kavar is ASIC verification technical supervisor at ASICraft Applied sciences.
Associated Content material
- Addressing the Verification Bottleneck
- Making Verification Methodology and Software Choices
- Gate degree simulations: verification move and challenges
- Specs: The hidden cut price for formal verification
- Shift-Left Verification: Why Early Reliability Checks Matter
The put up Makefile vs. YAML: Modernizing verification simulation flows appeared first on EDN.
