Configure project inputs

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

Before this task: Open a known two-file project →

The same RTL can describe different hardware under different tops, defines and parameters. Establish those inputs before trusting a diagram or comparing checks.

Start from the real project root#

You need the native HDL files, any required include files and the project's existing build description. Open the root containing those inputs, not a copied simulator work directory. Native files are authoritative; graphs and generated build copies are derived. SiliconForge can index source without a build profile, but that is not evidence that the original build configuration was reproduced.

Inspect the discovered build profile#

1. Open the project and check Settings → Projects & files → Current project.
2. For a FuseSoC/Edalize project, first generate its EDAM using the project's own reviewed build instructions. SiliconForge discovers existing build/**/*.eda.yml files; opening the project does not run FuseSoC for you.
3. When several EDAM files exist, discovery chooses the newest modification time, then pathname as a tie-breaker. Avoid relying on that choice for two different targets: isolate the intended build or inspect the explicit EDAM through project.profile.inspect.
4. Check top_modules, compilation_units, include_dirs, defines and parameters in the returned profile. The local RPC reference explains how to inspect it without AI.

Expected result: a hash-bound sf/project-build-profile-v1 identifying the actual inputs, or an explicit unavailable/error result. An unavailable profile must not be reinterpreted as a default passing configuration.

Inspect a minimal build description#

This exercise shows what the importer reads; it is not a complete FuseSoC core or a new native project-configuration editor. Start with an unchanged copy of the first project's two files. Create build/inspect/stream.eda.yml with this exact content. Paths in an EDAM file are relative to that file, not your shell:

name: stream-demo
toplevel: stream_register
files:
- name: ../../stream_register.sv
  file_type: systemVerilogSource

Use the inspect_project.py example with the project root and optional EDAM path:

python inspect_project.py /path/to/stream-demo build/inspect/stream.eda.yml

Expected result: top_modules contains stream_register; exactly one compilation unit has parse_path and native_path of stream_register.sv, source_authority is native_exact, and its recorded SHA-256 matches that file. Empty includes, defines and parameters are intentional here. The testbench is not the synthesis top. A validation profile may still be unavailable: input discovery does not invent verification checks.

Change a source comment in this disposable copy and inspect again: both the file and profile hashes must change. An earlier profile is no longer a description of those exact inputs. As a negative check, change ../../stream_register.sv to ../../missing.sv; expect an input error, not a profile with a silently omitted source. Restore the file reference before proceeding.

Choose the diagram’s build top in the GUI#

1. Open Design. In the diagram toolbar, choose Build top. In a narrower window, open the toolbar overflow menu and choose Select build top….
2. Select the intended indexed module and wait for the design graph to rebuild. Confirm the displayed hierarchy is the design you meant to inspect, not its testbench.
3. Configure the simulation top and checks separately under Verify → Configure checks. Selecting a diagram top does not run a simulation or change the verification profile.

A multiple-root message asks you to make this choice explicitly; it is not permission to infer a passing design. If no module declarations are available, inspect indexing diagnostics and source/build inputs first. The diagram selector is not a general source-list, parameter or include-directory editor.

Tops, includes and parameters#

The current EDAM importer supports a deliberately limited subset, not arbitrary YAML or every simulator configuration. It imports Verilog/SystemVerilog compilation units, the declared toplevel and include directories derived from rows marked is_include_file. It reads -DNAME defines and -GPARAM=value overrides from Verilator options. Nonempty EDAM parameters: mappings are rejected rather than silently ignored.

For example, if a project's Verilator options contain -GWIDTH=16, confirm the inspected profile reports WIDTH as 16 before interpreting a bus width or simulation. Change the original project configuration and regenerate its build inputs; do not hand-edit a generated profile hash or assume the diagram toolbar is a general project-parameter editor.

Check copied and generated inputs#

Each compilation unit records its parse path and, where established, native source path. native_exact means a matching native file was found by content. native_drifted means the build copy differs from its identified native source. generated means there is no mapped native source. Read those states before changing a file.

1. If native sources changed after build generation, regenerate with the reviewed project build command.
2. Inspect the profile again and compare drift counts and hashes.
3. Re-index and rerun affected checks; a successful run using old copied RTL does not verify the edited native file.

Recover from configuration failures#

A missing module can mean a missing source, wrong top, include path, define or unsupported HDL construct. Read the first useful elaboration diagnostic before chasing downstream errors. An outside-workspace or symlink rejection is a source-boundary check, not permission to disable path validation. Keep required inputs inside a reviewed workspace or supported dependency flow. Unsupported EDAM shapes require a supported project configuration, not deleting meaningful parameters.

Next: dependencies, hierarchy and source, tool authority, revision-bound verification.

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