Configuration and automation reference

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

Before this task: Know the inputs and configuration →

The native application talks to a local typed JSON-RPC core. Discover capabilities from the version you are running; do not assume an internal method is a stable hosted API.

Choose the right interface#

Normal installed-app use begins with the native GUI. The commands below are advanced source-checkout interfaces for operators who already have authorized access to a compatible SiliconForge checkout, its locked dependencies and its Python environment. The commercial application download does not promise public source-repository access. On Linux, run from that checkout with PYTHONPATH=core:.. A bare system Python or an arbitrary directory may not have the required packages. No public HTTP execution endpoint is implied.

Configuration surfaces#

Settings → Appearance

Theme, interface scale, default Design layer and architecture interaction preferences.

Settings → Assistant & models

Access route, model defaults, composer behavior and pinned-file limit. Credentials use the separate credential dialog.

Settings → Context & privacy

Whether the current engineering selection is included automatically; review disclosure before sending.

Settings → Validation & tools

Tool doctor and application verification runtime paths. Environment overrides take precedence; saved settings affect new runs.

Settings → Projects & files

Current project and native-source authority. This is not a general arbitrary EDAM/parameter editor.

Settings → Usage & cost

Desktop subscription activation, refresh and paid-through state; current provider/usage state, subscription management and local warning/cap preferences.

Use Save settings to retain intended edits; use Discard to close without that save. Preferences use QSettings under SiliconForge. Local project state lives in .siliconforge, including index.sqlite3; do not edit the database directly to repair project semantics.

Diagnostic and launch commands#

python -m gui --workspace /path/to/project
python -m sf_core project-doctor
python -m sf_core --workspace /path/to/project

The first opens the native app. The second prints task/tool readiness; inspect its JSON status rather than treating process exit alone as a passing qualification. The third starts the line-oriented local RPC process and creates/uses project-local state. It is not a shell prompt. See packaging commands for the separate offline Git-tree export interface.

Discover capabilities and inspect a profile#

Requests are one JSON object per line using JSON-RPC 2.0. Start with initialize, request sf-core/2 (the compatibility protocol sf-core/1 also exists), and include the returned session_nonce on each subsequent request. IDs correlate responses. Inspect error as well as result.

This small source-checkout script opens the local core, discovers methods and inspects an existing project profile. Save it outside the project as inspect_project.py, then run python inspect_project.py /path/to/project [relative/path.eda.yml] with the checkout on PYTHONPATH. It does not request AI or execute an HDL tool, but initialization can create local project state; use a disposable project when learning.

import json
from pathlib import Path
import subprocess
import sys

workspace = Path(sys.argv[1]).resolve()
p = subprocess.Popen(
    [sys.executable, "-m", "sf_core", "--workspace", str(workspace)],
    stdin=subprocess.PIPE, stdout=subprocess.PIPE, text=True,
)

def request(number, method, params):
    p.stdin.write(json.dumps({"jsonrpc": "2.0", "id": number,
                              "method": method, "params": params}) + "\n")
    p.stdin.flush()
    reply = json.loads(p.stdout.readline())
    if "error" in reply:
        raise RuntimeError(reply["error"])
    return reply["result"]

try:
    opened = request(1, "initialize", {"protocol": "sf-core/2"})
    params = {"session_nonce": opened["session_nonce"]}
    capabilities = request(2, "capabilities", params)
    if "project.profile.inspect" not in capabilities["methods"]:
        raise RuntimeError("This core does not offer profile inspection")
    if len(sys.argv) > 2:
        params["edam_path"] = sys.argv[2]
    profile = request(3, "project.profile.inspect", params)
    print(json.dumps(profile, indent=2))
finally:
    p.stdin.close()
    p.wait(timeout=10)

Expected result: a profile with current input hashes, or an explicit unavailable state if no supported EDAM exists. An error is diagnostic information, not permission to send unchecked execution controls.

Automation boundaries#

Capability discovery exposes the methods supported by this core. Read the matching schema/version and required arguments before using a mutating method. The server owns executable, tool-root, tool-lock, environment and build-profile authority; client requests attempting to override those controls are rejected. Candidate approval and stale-state checks still apply in automation.

Useful method families include workspace.*, graph.*, project.profile.inspect, toolchain.project_doctor, evidence.* and project.package.*. Do not assume every capability is available when the runtime reports degraded services.

If the example fails#

For an import error, check Python and PYTHONPATH against the source checkout. For a nonce error, initialize a fresh session and use its returned nonce; do not reuse a different process's state. If profile inspection is unavailable, inspect the actual build files rather than fabricating a profile. Preserve error codes without publishing confidential paths or payloads.

Related: profile behavior, keyboard controls, tool diagnostics, terminology.

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