Frequently Asked Questions#

Questions people actually ask, drawn from the issue tracker and the Help (Q&A) discussions.

If you are looking for “which method call does X”, that is the companion page: How do I…?.

Getting started#

Do I need to install EDA tools, or can I just try it?#

You can try it with nothing but pip install siliconcompiler, by running in the cloud:

project.option.set_remote(True)

A local run needs four tools – Yosys, OpenROAD, OpenSTA and KLayout – or the Docker image, which needs none of them installed. Where the compilation runs compares the options.

Is my design confidential if I use the public server?#

Your design is uploaded to a server operated by SiliconCompiler, under these terms. The client prints this before every remote run, and it is worth taking literally:

This public service, provided by SiliconCompiler, is not intended to process proprietary IP.

For anything you cannot publish, run locally or stand up a private server. You are also responsible for having the right to distribute any IP contained in what you upload.

What if the public server is down or busy?#

Please report it. The server is not self-monitoring from your side of the connection, and a bug report is how an outage gets noticed and fixed. Include the error and roughly when it happened.

Meanwhile, the fastest way to keep working is the Docker image, which runs the flow locally without installing any EDA tools:

python -m siliconcompiler.demos.asic_demo -scheduler docker

Installing the tools natively is the better answer if you expect to keep building, but it is not a five-minute detour, so it is not the one to start on while you are blocked. Either way the script is unchanged apart from how the run is dispatched.

A remote run depends on the server staying healthy for its whole duration, which is worth knowing before you rely on it for something time-critical.

Can I use SiliconCompiler on Windows?#

The package installs and runs on Windows, and is tested there on every commit, but that testing does not cover running EDA tools. There are no tool install scripts for Windows and local flows are not supported on it.

From Windows, use a remote run, the Docker image, or WSL. KLayout is worth installing natively so sc-show can display results. See External Tools.

Which PDK should I start with?#

Sky130. It is what the ASIC demo and the Quickstart use, so it is the best-trodden path and the one most likely to work first time.

Every open PDK SiliconCompiler supports is packaged in lambdapdk and listed under pre-defined PDKs. Maturity varies, and the catalogue does not yet say by how much; if a target does not behave, searching the discussions for its name is usually faster than debugging it.

Understanding the tool#

What is the difference between a target, a flow and a PDK?#

A PDK is foundry data. A flow is the sequence of steps to run. A target is a single function that selects both – PDK, standard cell libraries, flows and physical defaults – so one call configures a project for a technology:

from siliconcompiler.targets import skywater130_demo

skywater130_demo(project)     # picks the PDK, libraries and flows in one call

The glossary defines these and the rest of the vocabulary.

I have a new PDK, library or tool. Where does it go?#

Three answers depending on what it is: open PDKs go to lambdapdk, closed or proprietary data goes in a package of your own and never into this repository, and tool drivers, flows and targets go in-tree.

Where your module belongs has the decision table, and Packaging an External Library covers the proprietary case, including how to reference foundry decks out-of-band so they never enter a published package.

What is the difference between the package version and the schema version?#

They are versioned independently. The package is currently 0.38.4; the schema has its own version (0.57.0 at the time of writing) recorded in every manifest.

That is what lets SiliconCompiler tell you a manifest was written by an incompatible schema. When one does not load, the Schema Changes appendix records what was added, renamed or removed at each schema version.

Should I write `set()`/`get()` or the typed accessors?#

Prefer the typed accessor whenever one exists; use a keypath when there is no accessor, which mostly means reading metrics and records. Neither is deprecated – see Working with the Schema.

Where does SiliconCompiler put things?#

Build artifacts go under build/<design>/<jobname>/; downloaded data, settings and credentials live in ~/.sc. Directory structures maps both.

When things go wrong#

My run failed. Where are the logs?#

In the node directory of the step that failed, build/<design>/<jobname>/<step>/<index>/. There are two logs and they answer different questions:

<step>.log – what the tool printed. Start here when the tool failed.
sc_<step>_<index>.log – what SiliconCompiler did around it: which files it resolved, which parameters it passed.

<step>.errors and <step>.warnings hold the lines matched as errors and warnings, and are what the [metric,errors] and [metric,warnings] metrics count. See Inside a node directory.

How do I file a useful bug report?#

Use sc-issue, which packages a single failing node and its inputs into a standalone, runnable test case:

sc-issue -cfg build/<design>/<jobname>/<step>/<index>/inputs/<design>.pkg.json

A failing run prints this command with the paths filled in. Attaching its output saves a round trip of questions.

What is the difference between the `drvs` and `drcs` metrics?#

They count different kinds of violation, not the same violations at different stages.

[metric,drvs] – electrical and connectivity rule violations. OpenROAD sums max slew, max capacitance and max fanout violations, floating and overdriven nets, and antenna violations; OpenSTA counts its own design rule violators; a LEC task records equivalence mismatches here. No geometry is involved.

[metric,drcs] – geometric design rule violations, from a tool that checks geometry against the PDK rules. Detailed routing reports these as it routes, and a dedicated checker – Magic or KLayout DRC – reports them in signoff. Netgen also records LVS errors under this metric.

So drcs is not exclusively a signoff number: asicflow reports it from detailed routing. A clean drcs there means the router believes the layout is legal, which is a weaker statement than a signoff DRC run in signoffflow using the foundry deck.

See Working with Metrics for how metrics are recorded and compared, and the metric schema for the full list.

How do I run only part of the flow, or re-run one step?#

Use [option,from], [option,to] and [option,prune]. A re-run resumes by default, reusing nodes that already completed, so restarting from a step is enough to re-run it and everything after it:

project.option.add_from('synthesis')     # start here, reusing earlier results
project.option.add_to('route.detailed')  # and stop here

from and to take step names only, not indices – deliberately, to keep them simple. To drop individual nodes, use prune. To discard previous results entirely, see [option,clean] in Directory structures.

Is vector-based power estimation supported?#

Yes. If a VCD is available, OpenSTA annotates switching activity from it, so power numbers reflect real toggle rates rather than default assumptions. Add the waveform to a fileset and the timing task picks it up:

with design.active_fileset("vcd"):
    design.add_file("sim.vcd")

A VCD produced by an earlier node in the same flow is picked up automatically. Where the VCD hierarchy does not start at the design top, set the power_activities variable on the OpenSTA timing task to map a scope to the fileset holding the waveform.

Doing more#

Can I run this in CI?#

Yes – a build is an ordinary Python script, so anything that runs Python runs it. Two things make it practical:

Point [option,cachedir] at a cached directory so PDKs and libraries are not re-downloaded on every job – see the data cache.
Use sc-install in the image build, or the Docker image, rather than installing tools per job.

SiliconCompiler’s own CI does both – it runs inside a prebuilt tools container and restores the data cache between jobs. The workflows under .github/workflows/ are a working reference.

Which commercial EDA tools are supported?#

SiliconCompiler supports a number of commercial tools, but those drivers cannot be published for NDA reasons, so they are not in this repository and are not in the tool catalogue. If you need commercial tool support, raise it on the discussions board.

Nothing stops you writing your own driver for a proprietary tool and keeping it in your own package – see Setting up a Tool and Packaging an External Library.

I have an old script that uses `Chip()`. How do I port it?#

Chip was removed in v0.35.0 and split into a design and a project. Migrating from the Chip API maps the old names onto the new ones, method by method, and shows the same build written both ways.

If a code assistant wrote the script you are porting, this is the most likely explanation: the Chip API is what most of the material written about SiliconCompiler still describes.

Still stuck?#

If your question is not here, the Help (Q&A) discussions are actively answered, and questions asked there are where this page comes from.