Erie HLS Generator

Use this skill for local AMD-Xilinx/Vitis HLS C/C++ kernel generation. The bundled runtime lives in runtime/hls_generator, and the stable local facade is integration/hls_adapter.py.

Workflow

1. On first trigger in a Codex session, run python -m runtime.hls_generator deps check --json from this skill directory. If it reports blocked_dependency, ask the user whether to install the listed dependencies before continuing; do not degrade or continue past missing required or recommended dependencies.
2. Start from a confirmed HLS JSON spec or create one with the scaffold command.
3. Use the facade for local integrations:
   • run_hls_workflow(...) for full staged execution or resume.
   • render_hls_prompt(...) when a caller owns the model call.
   • validate_hls_artifacts(...) before using generated files downstream.
4. Require a confirmed requirement contract before generation: pipeline_required, streamability, interface_family, interface_profile, confirmed_by_user, and confirmation_notes. When throughput targets, numeric strategy, task parallelism, or device portability are in scope, confirm those constraints before code generation.
5. Run the fixed HLS pipeline: requirements -> codegen_plan -> tests -> python -> hls -> report_review -> remote_acceptance.
6. Treat generated HLS C/C++ typed comment placement as a hard gate: file headers, function contracts, type contracts, includes, macros, HLS pragmas, loops, datapath steps, and testbench PASS/FAIL behavior must have comments at the required position with matching hardware intent; generic or misplaced comments block validation.
7. Keep final hardware-facing artifacts limited to HLS C/C++ headers, sources, C++ testbenches, .cfg files, and reports. Python models and vectors are validation intermediates.
8. Validate with AMD-Xilinx tooling. The validator prefers vitis-run and falls back to vitis_hls; missing local tools block with a remote-server request so the caller can ask the user to choose an erie-remote-ssh server with Vitis available.
9. For Vitis development, simulation, cosim, and debug guidance, follow runtime_config.json skill routing: prefer vitis-developer when installed, otherwise fall back to vitis-hls-synthesis.

Local Commands

For source-repository validation only, run the bundled smoke validator from the repository root:

python .\smoke\run_smoke.py

Use the runtime CLI from the skill directory or another workspace. Pick an explicit writable output directory when you need generated specs, prompts, or validation JSON:

python -m runtime.hls_generator config --path
python -m runtime.hls_generator deps check --json
python -m runtime.hls_generator deps request --out <output-dir>\skill_dependency_request.json
python -m runtime.hls_generator scaffold --target hls --name vector_scale --out <output-dir>\hls\spec.json
python -m runtime.hls_generator prompt --target hls --spec <output-dir>\hls\spec.json --out <output-dir>\hls\prompt.md
python -m runtime.hls_generator validate --target hls --spec <output-dir>\hls\spec.json --path <output-dir>\hls\generated --readiness static --no-external

When local vitis-run/vitis_hls is missing, inspect the workflow's remote_toolchain_request.json, ask the user to choose a configured erie-remote-ssh build server and, when needed, a separate validation server, then use the remote acceptance helper:

python .\scripts\python\remote\remote_vitis_acceptance.py --mode link --server <erie-server>
python .\scripts\python\remote\remote_vitis_acceptance.py --mode vitis --server <erie-server> --profile <configured-profile> --readiness <execute|implement|cosim>
python .\scripts\python\remote\remote_vitis_acceptance.py --mode vitis --build-server <erie-build-server> --validate-server <erie-validate-server> --vitis-version <shared-version> --readiness <execute|implement|cosim>
python .\scripts\python\remote\remote_vitis_acceptance.py --mode board --server <erie-server> --platform-name <platform-name> --remote-platform-root <remote-platform-root> --remote-xpfm <remote-xpfm> --example-spec <board-runnable-example> --comment-language <en|zh> --json
python .\scripts\python\validation\confidence_loop.py --server <erie-server> --vitis-version <shared-version> --readiness cosim --remote-parallelism 3 --json-out ..\..\reports\confidence-loop\latest-remote.json

confidence_loop.py defaults remote review to a single canonical smoke spec. Only use --remote-coverage tier1 when you intentionally want the broader representative/high-risk matrix; otherwise do not turn routine template validation into a full remote sweep.

Remote Vitis acceptance refreshes erie software scan data. If multiple Vitis versions are detected and no version has been saved for that server in ~/.hls-generator/config.json, ask the user to choose a version and rerun with --vitis-version <version>.

If no remote Vitis profile has been configured and no previously saved remote selection provides the required tool path, expected tool, and target part, stop and ask the user to configure those values before continuing. Do not guess or fall back to a package default path.

If the user chooses a split build/validate topology, keep the server choice in runtime arguments or user-local configuration only. Do not encode real server ids, hostnames, usernames, ports, or board-specific server defaults into the skill package.

Vitis remote acceptance keeps the remote validation directory by default and reports remote_dir relative to the selected erie server workdir. Pass --cleanup-remote only when the user explicitly wants that remote project deleted after a successful run.

Reference Loading

• Load references/hls-template-catalog.md before changing curated template-corpus coverage, assetization status, errata tracking, or source-gap handling.
• Load references/integration.md when wiring the local facade into another script.
• Load references/workflow-contracts.md when handling run directories, statuses, resume behavior, or traces.
• Load references/configuration.md before changing generated roots, protected paths, Vitis tool commands, or timeouts.
• Load references/vitis-hls-2024-2-script-guide.md before changing Vitis HLS .cfg parsing, Tcl rendering, pragma rules, report handling, or compatibility checks.
• Load references/hls-optimization-patterns.md before changing optimization examples, prompt pragma policy, report-driven tuning rules, or reusable HLS pattern guidance.
• Load references/hls-report-driven-optimization.md before changing performance-goal framing, synthesis-report interpretation, or optimization-step sequencing.
• Load references/hls-modeling-strategy.md before changing loop-bound handling, numeric-type guidance, pointer modeling, template/vector usage, or conditional pragma policy.
• Load references/hls-memory-burst-and-layout.md before changing AXI4 burst policy, local memory layout, lane packing, or reusable buffer guidance.
• Load references/hls-task-parallel-strategy.md before changing task-level parallelism guidance, channel semantics, restart behavior, or stream/dataflow positioning.
• Load references/hls-stencil-reduction-gemm-patterns.md before changing stencil/window, reduction-tree, or tiled-GEMM guidance and templates.
• Load references/hls-advanced-library-patterns.md before changing hls_task, hls_streamofblocks, hls_directio, or hls_fence guidance and validation.
• Load references/hls-fir-template-family.md before changing FIR pipeline, symmetric, AXIS, dataflow, or specialized FIR-family guidance and assets.
• Load references/hls-fft-cordic-template-family.md before changing FFT/DFT scaling, twiddle, power-spectrum, CORDIC, or transform-family guidance and assets.
• Load references/hls-stream-codec-template-family.md before changing RLE AXIS, stream-codec framing, TLAST policy, or reference-first compression guidance.