Manage sources and dependencies

Applies to SiliconForge 0.1.2 · Updated 2026-09-30. Check platform limits.

Before this task: Confirm top and source inputs →

A dependency is an external project with provenance and licensing. A block is an RTL instance. Linking a checkout does not automatically instantiate or validate its hardware.

Before changing project inputs#

Save or commit current work. Identify the exact upstream revision, source location and license for the dependency. Tool availability and supported component checks vary; a catalog listing does not mean the project is bundled, installed, qualified or suitable for your design.

Add or revise native source safely#

1. Work in the project root shown under Settings → Projects & files. Edit native .sv/.v and include files with your normal source workflow, or review an assistant candidate before applying it.
2. If the project uses a build description, add files and includes there too. A file visible in the navigator is not necessarily part of the build.
3. Regenerate stale build inputs, inspect the project profile, and allow the design index to refresh. Resolve errors before trusting a changed graph.
4. Inspect Changes → Working changes. Review additions, deletions and generated output separately; do not commit confidential artifacts just because they appeared in a folder.

Expected result: the intended file belongs to the intended compilation, and the working diff contains only the change you meant to make.

Link a reviewed project#

1. Open Dependencies and choose Browse reviewed projects.
2. Select a project. Read its support state, source/acquisition information, license, interface and qualification status. Use View project to inspect its upstream identity.
3. Choose Link checkout for a suitable local checkout. This is a provenance/qualification workflow, not an automatic promise to download arbitrary internet code.
4. Inspect checks and the returned qualification receipt. Where supported, use Run available checks to retry missing checks after fixing the tool or input problem.
5. Use Propose dependency only when the returned state allows it. Review the staged proposal before explicit application.

Expected result: a reviewed, source-bound dependency proposal or a concrete blocker. A receipt from another checkout or revision cannot qualify the current one. Attached dependencies and local linked checkouts are shown separately.

Example: reuse instead of rewriting#

Suppose a telemetry project needs a FIFO. First inspect its existing buffering module and contract: width, depth, clock/reset and ready/valid behavior. If a catalog project appears suitable, compare those interfaces and licensing before importing it. Linking an external FIFO does not wire it into the telemetry top; that requires a separately reviewed RTL change and tests for reset, full/empty boundaries and backpressure.

Do not substitute a large unrelated IP library for a small verified change simply because the library appears in the catalog. Preserve the chosen commit and dependency lock so another engineer can reproduce the result.

Failed checks, cancellation and removal#

If checkout validation or qualification fails, retain the error and inspect the stated revision, required tools and supported target. Do not alter a qualification receipt to make a button available. Cancel interrupts the current job; inspect its terminal state before starting another. A proposed import still requires review. To remove previously applied dependency material, review the resulting source and lock changes like any other project change, then rebuild and rerun affected checks. Removing an unused checkout alone does not update instantiated RTL.

Related: review proposals, tool setup, dependency licenses in packages, backups.

Need help? Report an issue. Include your application version; never include credentials.