The current ECC configuration stack has three layers:
- ecc.toml — project config
- fp_default_config.json / params.json / etc. — tool-level JSON templates
- CLI --set flags — runtime overrides
This is functional but creates friction for two likely user groups:
-
Former OpenLane / LibreLane users. OpenLane uses a single config.tcl (overriding defaults from config_in.tcl) where all
parameters are TCL variables passed directly to the underlying EDA tools. Many expected ECC users will come from OpenLane. The
current multi-format stack (TOML → JSON → tool invocation) is harder to learn and debug.
-
AI agent workflows. TCL is the lingua franca of EDA scripting (SDC constraints, Innovus/ICC2 scripts, OpenROAD flow). AI agents
already know how to read, write, and reason about TCL-based EDA configurations. TOML and JSON require extra translation layers.
Suggestion: Consider a TCL-based config path, either as an alternative to ecc.toml or as a unified config that maps 1:1 to the
existing TOML/JSON schemas. This would also align ECC more closely with commercial EDA scripting conventions.
The current ECC configuration stack has three layers:
This is functional but creates friction for two likely user groups:
Former OpenLane / LibreLane users. OpenLane uses a single config.tcl (overriding defaults from config_in.tcl) where all
parameters are TCL variables passed directly to the underlying EDA tools. Many expected ECC users will come from OpenLane. The
current multi-format stack (TOML → JSON → tool invocation) is harder to learn and debug.
AI agent workflows. TCL is the lingua franca of EDA scripting (SDC constraints, Innovus/ICC2 scripts, OpenROAD flow). AI agents
already know how to read, write, and reason about TCL-based EDA configurations. TOML and JSON require extra translation layers.
Suggestion: Consider a TCL-based config path, either as an alternative to ecc.toml or as a unified config that maps 1:1 to the
existing TOML/JSON schemas. This would also align ECC more closely with commercial EDA scripting conventions.