Preface¶

In DSH, using agents to perform RTL tasks, the common issue is not “whether the model can write Verilog,” but the absence of a workflow: unclear phase boundaries between architecture and RTL, verification, synthesis, and physical implementation; not knowing which check results to reuse after changes; and the confusion between delivery and technical acceptance, making recovery difficult after failure. Hand-crafted prompts can cover a few steps, but it is hard to consistently span the entire chain of “contract — implementation — evidence — resources — delivery.”

dsh-rtl-flow (maintainer wanghao815, category: Workflow) incorporates the above capabilities into a plugin: the main process is written in docs/core-workflow.md, and the model tool rtl_guide(workflow) and the CLI read the same source. It also includes evidence auditing, device resource pre-checks, and the separation of technical and delivery records. The following sections introduce “What is it → Capabilities → Installation → Usage → Notes,” with facts based on the repository README and package.json.

What is it¶

dsh-rtl-flow is a general-purpose RTL engineering plugin on DeepSeek Harness, covering architecture, RTL, verification, synthesis, physical implementation, delivery, and recovery. It does not replace the EDA tools themselves but provides work entry points, stage guidance based on design characteristics, auditing of real files and reports, and resource verification before controlled execution.

• Plugin package name: dsh-rtl-flow, current version 0.3.0
• License: MIT
• Source & docs: GitHub wanghao815/dsh-rtl-flow
• Community directory: SkillHub plugin page

Runtime requirements: Node.js ≥24.9, and the host API compatibility baseline is DeepSeek Harness 0.2.2-rc.1. DSH is a preview version; re-verification is required after upgrading. Plugin versions and DSH versions are independent of each other.

Five Work Entry Points¶

For existing projects, it is not necessary to run the entire stage chain from scratch. work provides a reuse/invalidate/execute plan based on disk auditing and explicit impact; execution still requires satisfying technical dependencies and authorization.

init is specifically for new projects. adopt only previews missing files and does not overwrite existing files; existing contract paths can use the contracts mapping in project options and do not force migration of the original directory.

Main Process & Feature Topics¶

The main process works together with the various topics. stage is responsible for the main process; there are also seven topics: arithmetic, stream, protocol, multiclock, memory, macros, and formal. Each topic explains entry conditions, inputs, processing, outputs, criteria, and failure diagnostics. For example, arithmetic modules with backpressure and cross-clock requirements require enabling arithmetic/stream/multiclock simultaneously; module names cannot replace the full feature list.

Module names only provide editable initial suggestions; topology, number system, pipeline, capacity, frequency, and process are determined by current project requirements. Backend guidance refers to open-source ASIC flows; FPGA and commercial tools require separate adaptation within the project. See docs/core-workflow.md and docs/output_human_final.md in the repository for detailed stage decisions and output strategies.

Model Tools & CLI Division of Labor¶

The plugin injects five tool schemas into the host; detailed content is loaded on demand. It does not include API keys and relies on the host model, file/terminal permissions, and cancellation mechanisms.

RTL, testbench, and the workflow are generated by the host model in conjunction with the project contract. JSON declaration checks on the tool side cannot replace the CLI audit for verifying real reads, native metrics, and file summaries.

Installation & Configuration¶

In the plugin repository root directory (including package.json), you can first self-check:

npm ci --ignore-scripts
npm run check
npm test

Install to a test profile from that directory:

dsh plugin --profile rtl add .
dsh --profile rtl --dump-config
dsh --profile rtl

When dsh is not globally installed, you can use npx --yes @deepseek-ai/dsh@0.2.2-rc.1 to replace dsh in commands. To get the absolute entry path for the development overlay, run node bin/rtl-flow.js overlay; choose either the bundle or overlay method for loading.

You can also install dsh-rtl-flow@0.3.0 from npm (actual public version depends on the registry). See docs/release-checklist.md for release steps.

Configuration fields include: enabled, promptOrder, maxInputBytes, and the optional workspaceRoot. To perform native resource detection on a project, set workspaceRoot to the absolute path of the currently authorized project; if not configured, use the CLI resources via the host terminal. You must synchronize updates to this field when switching projects.

Typical CLI Usage¶

In the plugin root directory containing package.json:

node bin/rtl-flow.js plan --config examples/fifo.json
node bin/rtl-flow.js init /tmp/my-fifo --config examples/fifo.json
node bin/rtl-flow.js adopt /path/to/existing --config examples/fifo.json
node bin/rtl-flow.js work /path/to/project --entry modify --impact rtl,control
node bin/rtl-flow.js topics /path/to/project
node bin/rtl-flow.js audit /path/to/project
node bin/rtl-flow.js resources /path/to/project
node bin/rtl-flow.js run /path/to/project --task smoke

The configuration for adopt must describe the real old project; the FIFO example in the README only demonstrates the command form. If the new draft has no execution evidence, audit will fail as expected; if budget and remaining tasks are not filled, resources will also block.

Subcommands such as capture, parse, and hash are used for evidence collection and summarization; specifications can be found in docs/evidence.md. Exit codes: 0 indicates that the specified scope of this operation is satisfied; 1 means checks or pre-checks were not satisfied or a native task failed; 2 indicates an input/execution error; 130 indicates an interrupt. When evaluating audit, you must check technical_ok, delivery_ok, and outcome, rather than just the exit code.

OpenROAD/ORFS Environment¶

The plugin does not carry the EDA/PDK core; npm installation will not automatically download the environment. The missing official environment will only be acquired after explicit env prepare and passing the full resource pre-check:

rtl-flow env /path/to/project --action init
rtl-flow env /path/to/project --action inspect
rtl-flow env /path/to/project --action plan
rtl-flow env /path/to/project --action prepare
rtl-flow env /path/to/project --action check

The plan should be saved as config/backend-plan.json. See docs/backend-setup.md for steps, image locking, and boundaries.

Resource Budget & Controlled Execution¶

config/resource-plan.json lists remaining tasks, dependencies, argv, re-task markers, and time/memory/disk estimates. Unknown values will block execution. run --task executes only one foreground task at a time, with native argv not passing through a shell; the runner holds the project lock and records exits and resource sampling, and the process group is terminated controlledly if limits are exceeded or monitoring is unavailable. This runner supports macOS/Linux; Agents should use pre-check/controlled entry before heavy tasks, and commands bypassed by the CLI are not monitored by the runner.

Delivery, Pause & Project Format¶

The project state is active/paused/archived; delivery.intent is full/scoped/closeout. Therefore, delivery_ok=true does not necessarily mean technical_ok=true. Pausing is not automatically cleared by the resume entry.

The project uses schema_version=2. Example configurations can be found in examples/fifo.json, examples/apb-registers.json, examples/dsp-mac.json, and examples/memory-subsystem.json.

Applicable Scenarios & Notes¶

Who is it for: Developers who are already performing RTL/ASIC flows in DSH and wish to have phase gating, evidence auditing, and resource pre-checks aligned with Agent collaboration.

Permissions & Security: The plugin runs with the permissions of the current DSH process. Before installation, you should read the source code and the MIT license to confirm that workspaceRoot and contract paths only point to paths you are willing to authorize to the host.

Verification Scope: Unit and host test results do not represent real model new designs, full-process PDK, or manufacturing sign-off. See docs/validation.md for the actual scope of compatibility. Native report parsing only covers formats listed in the documentation; the summary guarantees consistency but does not prove that logs are tamper-proof.

The DeepSeek Harness ecosystem philosophy is “Everything is a plugin”; community directories like SkillHub are independent sites and have no official affiliation with DeepSeek or Huasuan.

Closing¶

dsh-rtl-flow brings RTL engineering back from “single-shot code generation” to an auditable workflow that allows recovery via multiple entry points and distinguishes technical acceptance from delivery intent. If you need the full main process text, read docs/core-workflow.md first in the repository; after installing in DSH, you can start by aligning with the project contract via rtl_guide and the CLI plan/audit/resources.

• Directory page: https://www.skillhub.cn/plugins/wanghao815/dsh-rtl-flow
• GitHub: https://github.com/wanghao815/dsh-rtl-flow