Hello Dear Readers, Today in this post, I will provide some deep insight about yaml langauge for CAD flow developments with detailed examples. YAML is not a programming language in the same sense as Python, Tcl, C++, or Verilog. It is primarily a human-readable data serialization/configuration language . In semiconductor EDA, that distinction is important because YAML generally describes what a flow should do , while Python/Tcl/Shell and the EDA tools execute the flow . The official YAML specification describes it as a data serialization language designed to be human-friendly and portable across programming languages. For the semiconductor angle, this becomes particularly interesting because YAML can act as a configuration layer between design methodology and EDA implementation . Frameworks such as Hammer explicitly use YAML/JSON configuration and an intermediate representation to standardize information exchanged between design, technology, and tool plugins. 1. Introduction M...
Hello Dear Readers,
Today in this post, I will provide some deep insight about yaml langauge for CAD flow developments with detailed examples.
YAML is not a programming language in the same sense as Python, Tcl, C++, or Verilog. It is primarily a human-readable data serialization/configuration language. In semiconductor EDA, that distinction is important because YAML generally describes what a flow should do, while Python/Tcl/Shell and the EDA tools execute the flow. The official YAML specification describes it as a data serialization language designed to be human-friendly and portable across programming languages.
For the semiconductor angle, this becomes particularly interesting because YAML can act as a configuration layer between design methodology and EDA implementation. Frameworks such as Hammer explicitly use YAML/JSON configuration and an intermediate representation to standardize information exchanged between design, technology, and tool plugins.
1. Introduction
Modern semiconductor design is no longer just about writing RTL and running an EDA tool. A contemporary ASIC/SoC design flow involves hundreds of configuration parameters, technology files, libraries, constraints, tool options, execution environments, compute resources, analysis modes, and signoff requirements.
A typical ASIC flow may involve:
RTL → Simulation → Synthesis → Floorplanning → Placement → CTS → Routing → Extraction → STA → Power → IR/EM → DRC/LVS → Signoff
Each stage may use different tools, different file formats, different databases, and hundreds or thousands of configuration parameters.
Traditionally, engineers have controlled these flows using:
Tcl
Python
Shell scripting
Makefiles
JSON
proprietary configuration formats
command-line arguments
YAML provides another layer that is particularly useful for separating configuration/data from execution logic.
Instead of writing:
run synthesis with these libraries
run placement with these dimensions
use this clock frequency
use these power supplies
use this technology
use these CPU resources
use this tool version
inside executable scripts, the information can be represented declaratively:
design:
top_module: riscv_core
clock:
name: clk
period: 1.0 ns
power:
VDD: 0.8 V
VSS: 0.0 V
technology:
node: 5nm
resources:
cpus: 32
A Python/Tcl-based flow can then read this configuration and translate it into the appropriate commands for Genus, Innovus, PrimeTime, Voltus, Calibre, or other tools.
This makes YAML particularly interesting for EDA methodology development, flow automation, reproducibility, and multi-tool orchestration.
2. What Exactly Is YAML?
YAML originally stood for “YAML Ain't Markup Language.”
The current specification describes YAML as a human-friendly data serialization language. YAML is designed around fundamental data structures such as:
Mappings
Sequences
Scalars
The current published specification is YAML 1.2.2.
For example:
name: riscv_core
technology: 5nm
clock_period: 1.0
This represents a mapping:
key → value
Conceptually:
name → riscv_core
technology → 5nm
clock_period → 1.0
YAML can also represent lists:
libraries:
- stdcell.lib
- memory.lib
- io.lib
and hierarchical structures:
design:
name: riscv_core
clock:
name: clk
period: 1.0
power:
VDD: 0.8
VSS: 0.0
This hierarchical representation maps naturally to the hierarchical nature of an SoC and its EDA flow.
3. YAML Is Data, Not Execution
This is one of the most important concepts for an EDA engineer.
Consider:
clock:
period: 1.0
YAML itself does not execute a timing constraint.
It simply stores:
clock.period = 1.0
A program such as Python can read the YAML:
import yaml
with open("config.yml") as f:
config = yaml.safe_load(f)
period = config["clock"]["period"]
print(period)
The Python program can then generate an EDA command:
create_clock -period 1.0 [get_ports clk]
Therefore the architecture becomes:
YAML
|
v
Configuration Data
|
v
Python
|
v
Flow Methodology
|
v
Tcl / Commands
|
v
EDA Tool
This separation is extremely powerful.
4. Why YAML Is Interesting for Semiconductor EDA
EDA flows contain enormous amounts of configuration.
For example, a physical-design flow may need:
Technology node
PDK location
Library paths
LEF files
DEF files
Liberty files
RC corners
MMMC views
Power nets
Ground nets
Clock definitions
Core utilization
Die dimensions
Pin locations
Power-grid configuration
Routing layers
Via rules
DRC settings
Timing constraints
Power-analysis settings
IR-drop settings
EM limits
CPU requirements
Distributed computing settings
Tool versions
If these values are hard-coded directly into Tcl scripts, methodology reuse becomes difficult.
For example:
set init_lef_file "/project/pdk/5nm/lef/tech.lef"
set init_verilog "/project/design/riscv.v"
set_db design_process_node 5
set_db floorplan_core_utilization 0.70
Now imagine changing from:
5nm → 3nm
or:
Design A → Design B
or:
Cadence flow → OpenROAD flow
Hard-coded scripts quickly become difficult to maintain.
A configuration-driven methodology can instead use:
technology:
node: 3nm
design:
name: gpu_top
floorplan:
utilization: 0.70
The methodology engine decides how to translate these values into tool-specific commands.
5. Declarative vs Procedural Flow Development
This distinction is extremely important.
Procedural methodology:
A traditional Tcl script might look like:
read_hdl design.v
elaborate
set_clock_uncertainty 0.05 [get_clocks clk]
compile
write_netlist design_syn.v
This describes how to execute the flow.
It is procedural.
Declarative methodology:
A YAML file might instead describe:
synthesis:
top: riscv_core
constraints:
clock:
name: clk
period: 1.0
uncertainty: 0.05
This describes what configuration is desired.
A flow engine can decide how to implement that configuration.
Conceptually:
DECLARATIVE LAYER
|
YAML
|
v
FLOW ABSTRACTION
|
Python / Framework
|
v
TOOL-SPECIFIC ADAPTER
|
+----------+----------+
| |
Genus Yosys
| |
v v
Tcl/API Commands
This abstraction is one of the major reasons YAML becomes valuable in modern flow-development methodologies.
Key-value pairs
design_name: riscv_core
technology: sky130
clock_period: 2.0
Equivalent conceptual Python dictionary:
{
"design_name": "riscv_core",
"technology": "sky130",
"clock_period": 2.0
}
Lists
libraries:
- stdcell.lib
- sram.lib
- io.lib
Equivalent conceptually:
libraries = [
"stdcell.lib",
"sram.lib",
"io.lib"
]
Nested dictionaries
design:
name: riscv_core
top: chip_top
clock:
name: clk
period: 1.0
Multiple clocks
clocks:
- name: clk_core
period: 1.0
- name: clk_peripheral
period: 4.0
- name: clk_memory
period: 2.0
This becomes particularly useful in SoC flows.
Comments
YAML comments start with #.
# Core clock frequency
clock_period: 1.0
# Target technology
technology: 5nm
Comments make configuration files much easier for methodology teams to maintain.
6. YAML Indentation
Indentation is fundamental to YAML.
Correct:
design:
name: cpu
top: chip_top
Incorrect:
design:
name: cpu
top: chip_top
YAML generally uses spaces rather than tabs for indentation.
A common EDA methodology rule should therefore be:
Use consistent indentation.
Prefer 2 spaces.
Never mix tabs and spaces.
7. YAML Data Types
Typical YAML configurations can contain:
String
top_module: cpu_top
Integer
cpus: 32
Floating-point value
utilization: 0.70
Boolean
enable_ir_analysis: true
List
routing_layers:
- M2
- M3
- M4
- M5
Dictionary
power:
VDD: 0.8
VSS: 0.0
This combination maps extremely well to EDA configuration requirements.
8. A Semiconductor-Oriented YAML Example
Consider a simplified ASIC configuration:
project:
name: riscv_soc
top: soc_top
technology:
node: 5nm
pdk: /pdk/5nm
libraries:
lef:
- tech.lef
- stdcell.lef
- macro.lef
liberty:
- ss_0p72v_125c.lib
- ff_0p88v_m40c.lib
clock:
name: clk
period: 1.0
uncertainty: 0.05
power:
VDD: 0.80
VSS: 0.00
floorplan:
utilization: 0.70
aspect_ratio: 1.0
placement:
effort: high
routing:
top_layer: M10
bottom_layer: M2
signoff:
sta: true
ir_drop: true
electromigration: true
drc: true
lvs: true
compute:
cpus: 32
This file contains no actual Innovus, Genus, PrimeTime, or Voltus commands.
It contains intent and configuration.
That distinction is the key to scalable methodology development.
9. YAML + Python + Tcl in an EDA Flow
A practical architecture could be:
project.yml
|
v
YAML Parser
|
v
Python Engine
|
+--------+--------+
| | |
v v v
Genus Innovus Voltus
| | |
v v v
Tcl Tcl Tcl
| | |
+--------+--------+
|
v
Reports/Data
Python becomes the orchestration layer.
Tcl becomes the tool-control layer.
YAML becomes the configuration layer.
The EDA tools remain the execution engines.
Example: Generating Innovus Configuration,
Suppose YAML contains:
floorplan:
utilization: 0.68
aspect_ratio: 1.0
power:
nets:
- VDD
- VSS
Python can read it:
import yaml
with open("config.yml") as f:
cfg = yaml.safe_load(f)
util = cfg["floorplan"]["utilization"]
aspect = cfg["floorplan"]["aspect_ratio"]
print(f"create_floorplan -core_utilization {util} -aspect_ratio {aspect}")
The generated Tcl could become:
create_floorplan \
-core_utilization 0.68 \
-aspect_ratio 1.0
Now the methodology script does not need to be rewritten for every project.
Only the configuration changes.
10. YAML for Synthesis Methodology
A synthesis configuration could contain:
synthesis:
tool: genus
top: riscv_core
rtl:
- rtl/core.v
- rtl/cache.v
- rtl/bus.v
libraries:
target:
- stdcell.lib
link:
- stdcell.lib
- memory.lib
constraints:
clock:
name: clk
period: 1.0
optimization:
area: high
timing: high
A Python/Tcl methodology engine can convert this into the corresponding synthesis-tool commands.
The advantage is that engineers interact primarily with a consistent configuration interface instead of modifying hundreds of lines of Tcl.
11. YAML for Physical Design
Physical design has even more configuration.
For example:
floorplan:
utilization: 0.70
aspect_ratio: 1.0
core_margin:
left: 20
right: 20
top: 20
bottom: 20
placement:
density: 0.70
timing_driven: true
congestion_driven: true
clock_tree:
target_skew: 0.05
max_transition: 0.10
routing:
min_layer: M2
max_layer: M10
A methodology engine can translate this into the appropriate commands for the selected P&R tool.
Multi-mode multi-corner analysis is another excellent application.
For example:
corners:
setup:
library: ss_0p72v_125c
rc: rcworst
hold:
library: ff_0p88v_m40c
rc: rcbest
modes:
functional:
sdc: functional.sdc
scan:
sdc: scan.sdc
A flow engine can construct:
Library Sets
↓
RC Corners
↓
Delay Corners
↓
Constraint Modes
↓
Analysis Views
The YAML configuration therefore becomes a high-level description of the MMMC methodology.
This is particularly relevant to modern physical-signoff flows.
Consider a Voltus-style configuration:
power_analysis:
tool: voltus
mode: dynamic
power_nets:
- VDD
ground_nets:
- VSS
activity:
source: vcd
file: simulation.vcd
analysis:
static_ir: true
dynamic_ir: true
signal_em: true
power_em: true
limits:
voltage_drop: 0.075
current_density: 1.0
compute:
cpus: 256YAML
↓
Python flow engine
↓
Voltus Tcl generation
↓
Voltus
↓
IR/EM results
↓
Python report processing
↓
Dashboard / reports
This is a very realistic methodology architecture.
A larger signoff configuration could be:
signoff:
ir:
enabled: true
analysis:
static: true
dynamic: true
voltage_drop:
limit: 0.075
ground_bounce:
limit: 0.075
em:
power_em: true
signal_em: true
reports:
summary: true
violation_database: true
compute:
hosts: 32
workers_per_host: 8
Now the same methodology can potentially be mapped to different signoff tools.
For example:
YAML
|
v
Signoff Methodology
|
+-------+-------+
| |
v v
Voltus RedHawk
| |
v v
Tool-specific Tool-specific
commands commands
This is one of the most interesting applications of configuration-driven EDA methodology.
12. YAML and Tool Abstraction
EDA vendors have different command languages.
For example:
Cadence
Tcl / db APIs
Synopsys
Tcl / tool APIs
OpenROAD
Tcl
Custom analysis
Python
Shell
Linux commands
A methodology framework can hide these differences.
The engineer specifies:
analysis:
type: dynamic_ir
enabled: true
The framework determines how that intent is implemented.
Conceptually:
DESIGN INTENT
|
YAML
|
v
METHODOLOGY ENGINE
|
+----------+----------+
| | |
v v v
Cadence Synopsys Open-source
| | |
v v v
Tcl Tcl Tcl/Python
This is effectively a flow abstraction layer.
One of the strongest real-world examples of YAML being used in an ASIC methodology is Hammer.
Hammer is a physical-design flow framework designed to improve reuse by separating three major concerns:
Design
CAD tool
Process technology
Hammer uses YAML/JSON configuration files as part of its intermediate representation, commonly called Hammer IR.
For example, Hammer configurations can describe:
vlsi.core.technology: "hammer.technology.asap7"
vlsi.inputs.supplies:
VDD: "0.7 V"
GND: "0 V"
Hammer then uses its tool and technology plugins to translate these abstractions into the appropriate tool-specific flow.
This demonstrates an important principle:
YAML does not replace the EDA tool. YAML provides a structured interface through which a methodology framework can control the tool.
13. YAML Configuration Layering
Large semiconductor projects should generally avoid putting everything into one gigantic YAML file.
Instead:
configs/
│
├── common.yml
├── design.yml
├── technology.yml
├── synthesis.yml
├── place_route.yml
├── timing.yml
├── power.yml
├── signoff.yml
└── project_override.yml
Then configuration can be composed.
For example:
common.yml
+
technology.yml
+
design.yml
+
signoff.yml
+
project_override.yml
↓
Final Configuration
This makes project management much cleaner.
Hammer, for example, supports configuration precedence where defaults can be overridden by tool, technology, and user-provided configuration layers.
Suppose the default configuration contains:
floorplan:
utilization: 0.65
A project-specific file contains:
floorplan:
utilization: 0.72
The project value should override the default.
This gives us:
Global Defaults
↓
Tool Defaults
↓
Technology Defaults
↓
Project Configuration
↓
Experiment Override
This is extremely useful for physical-design experimentation.
For example:
Baseline:
utilization = 0.65
Experiment 1:
utilization = 0.68
Experiment 2:
utilization = 0.72
Experiment 3:
utilization = 0.75
The methodology code remains unchanged.
Only configuration changes
This becomes even more powerful when combined with automation.
Suppose we want to evaluate:
Utilization:
0.60
0.65
0.70
0.75
Core aspect ratio:
0.9
1.0
1.1
Placement effort:
medium
high
A Python program can automatically generate configurations:
experiment:
utilization: 0.70
aspect_ratio: 1.0
placement_effort: high
and launch:
Run 001
Run 002
Run 003
...
Run N
Results can then be collected:
Area
Timing
Power
Congestion
IR drop
EM violations
DRC
LVS
Runtime
Memory
This turns YAML into an important component of an EDA optimization framework.
The software industry commonly uses CI/CD pipelines.
The same concept can be applied to semiconductor methodology.
For example:
Git Commit
↓
YAML Validation
↓
Flow Initialization
↓
Lint
↓
Synthesis
↓
STA
↓
P&R
↓
Power
↓
IR/EM
↓
DRC/LVS
↓
QoR Database
YAML can define what should run:
pipeline:
lint: true
synthesis: true
sta: true
pnr: true
power: true
ir_em: true
drc: true
lvs: true
A pipeline engine can then execute the appropriate stages.
Modern EDA flows can require hundreds of CPUs and large amounts of memory.
A YAML configuration can describe execution resources:
compute:
scheduler: lsf
resources:
cpus: 256
memory: 512G
queue: normal
A methodology engine can translate that configuration into the appropriate scheduler commands.
For example:
YAML
↓
Python
↓
LSF command
↓
bsub
↓
EDA job
Or:
YAML
↓
Python
↓
Slurm command
↓
sbatch
↓
EDA job
This means the flow intent can remain independent of the underlying compute scheduler.
Hammer documentation provides an example of configuring LSF submission through YAML-based flow configuration.
Large SoCs are rarely handled as a single monolithic block.
Consider:
SOC
│
├── CPU
├── GPU
├── NPU
├── Cache
├── Memory Controller
├── PCIe
├── NoC
├── DSP
└── Peripheral subsystem
Each block can have its own configuration.
For example:
blocks:
cpu:
flow: physical_design
target_frequency: 2.5GHz
gpu:
flow: physical_design
target_frequency: 1.8GHz
npu:
flow: physical_design
target_frequency: 1.5GHz
memory_controller:
flow: physical_design
target_frequency: 1.2GHz
This allows a hierarchical flow engine to launch different implementation flows for different blocks.
Hammer also supports hierarchical physical-design flow concepts for large designs.
This comparison is particularly important for EDA engineers.
| Feature | YAML | Tcl |
|---|---|---|
| Primary purpose | Data/configuration | Programming/scripting |
| Executes commands | No | Yes |
| Human readability | High | Medium |
| EDA tool support | Framework-dependent | Extremely common |
| Flow logic | Poor | Excellent |
| Configuration | Excellent | Good |
| Loops/conditions | Not its primary purpose | Yes |
| Tool APIs | No | Yes |
| Best role | Configuration | Execution |
14. YAML in a Complete ASIC Flow
A complete methodology can conceptually be:
PROJECT YAML
|
v
Configuration Parser
|
v
Schema Validation
|
v
Flow Orchestrator
|
+---------------------+---------------------+
| | |
v v v
Synthesis P&R Signoff
| | |
Genus Innovus Tempus
| | |
+---------------------+---------------------+
|
v
Voltus
|
v
Calibre
|
v
QoR Database
The YAML configuration becomes the central source of flow intent.
Comments
Post a Comment