What does this skill do, and when should you use it?
hsb-flash guides FPGA firmware upgrades and downgrades for HSB hardware connected to an NVIDIA devkit. It supports standalone HSB Lattice boards and Leopard Imaging VB1940 all-in-one cameras, using board-specific commands. The workflow covers connectivity checks, version detection, target selection, YAML manifest preparation, flashing, verification, reporting, and cleanup. Because flashing permanently changes firmware, it requires explicit invocation and user confirmation at critical stages.
Reads SSH_TARGET, REMOTE_ROOT, and related environment variables; checks devkit and board connectivity over SSH; uses hololink to read the FPGA version and identify the board type; selects the HSB release repository, YAML manifest, and flashing command based on board type and version transition; runs flashing commands with --force and --accept-eula inside the demo container; handles required power cycles; verifies the target FPGA version; produces a summary and removes interim repositories and flash artifacts.
- A developer upgrading an HSB Lattice board from FPGA 2407 to 2412, 2507, or 2510.
- A hardware engineer downgrading an HSB Lattice FPGA between supported versions.
- A user flashing FPGA 2507 or 2510 on a Leopard Imaging VB1940 all-in-one camera.
- A team maintaining HSB firmware remotely through an NVIDIA devkit and retaining an operation summary.
How do you install this skill?
- Do not flash when board type or current version cannot be reliably confirmed; in particular, do not rely on the ‘assume 2407’ fallback.
- --force and --y weaken critical confirmation gates; use only with explicit recorded authorization, target version, and recovery planning.
- Verify remote dependencies, containers, repository documentation, manifest provenance, and network reachability first, and prepare hardware-level recovery measures.
- Shell / CLI
- Network access
- Local filesystem
SSHhololink CLIGitdemo container
Install it with the repository README command: npx skills add nvidia/skills --skill hsb-flash --yes. To target a client explicitly, use for example: npx skills add nvidia/skills --skill hsb-flash --agent codex --yes. The repository is a multi-skill collection, so manually copying the skill directory is not required.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/hsb-flash" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Invoke it only for an explicit flashing task: /hsb-flash [OPTIONS]. Before use, provide SSH_TARGET and REMOTE_ROOT. The skill displays remote settings, performs a token-budget preflight, and presents a phase plan before requesting confirmation. Before any flash command, the user must explicitly confirm whether the board is Lattice or VB1940. The complete --help output and referenced file contents are not included in the supplied material.
What are this skill's strengths and limitations?
- Supports both Lattice and VB1940 hardware with an explicit rule preventing command mixing.
- Covers version detection, single-step and two-step transitions, power-cycle verification, and post-flash version checks.
- Documents remote SSH execution, release-repository selection, YAML manifests, and interim-resource cleanup.
- Only documented FPGA versions are supported: Lattice 2407, 2412, 2507, and 2510; VB1940 2507 and 2510.
- Flashing permanently changes FPGA firmware and requires a remote devkit, SSH, hololink, and a demo container.
- The supplied material provides no automated test suite, hardware compatibility results, or complete reference-file contents.
- The frontmatter includes a Claude Code-style disable-model-invocation setting, so other clients may require adaptation.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| HSB FPGA Flash Assistant this page ✓ NVIDIA · Official | 43 · Not recommended | ★ 3.6k | 13d ago | Apache-2.0 |
| Holoscan Sensor Bridge Demo Bring-Up ✓ NVIDIA · Official | 38 · Blocked | ★ 3.6k | 13d ago | Apache-2.0 |
| TAO on SLURM ✓ NVIDIA · Official | 55 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| Home Assistant Manager Skill | 52 · Use with care | ★ 971 | 3mo ago | MIT |
| Claude Status Bar Control Skill | 62 · Recommended | ★ 377 | 18d ago | MIT |
How did FollowSkills review this skill?
The evidence shows explicit confirmation gates, board-type confirmation, phased approval, containerized execution, and warnings that the wrong tool can permanently damage hardware. However, --force can bypass version mismatches, --y can skip phase confirmations, failed detection may assume 2407 and continue, and the workflow uses SSH, remote checkouts, privileged Docker, and permanent firmware changes without a complete recovery path. Manifest downloads also rely mainly on external URLs. Deducted for these risks.
The evidence provides version mappings, single-step/two-step transition rules, a 2407 fallback, logging, and failure-summary requirements. However, key commands depend on remote repository documentation and unavailable environment state; dynamic self-modification is required for undocumented versions; the register-read example is incomplete; and assuming 2407 after detection failure can cause unsafe behavior. Static review cannot exceed 10, so the score is conservative.
The audience, board types, supported versions, transition boundaries, and invocation method are reasonably clear, with Codex and Claude Code listed. Chinese-language support is not documented, and the core workflow depends on SSH, Docker, GitHub, NGC, and external downloads without evidence of reachability from mainland-China networks. Non-fit scenarios are also incompletely specified.
The evidence includes metadata, an authoring team, version 1.0.0, tags, phased documentation, help text, and a benchmark report. However, recommended Purpose/Examples sections are missing, prerequisites and limitations are incomplete, changelog and maintenance/update ownership are unclear, and repository license metadata is NOASSERTION even though the skill declares Apache-2.0.
The evidence covers board detection, version selection, manifest preparation, flashing, verification, reporting, and cleanup, and BENCHMARK.md records limited execution-evaluation results. However, success still depends on live hardware, remote setup, omitted reference files, and external artifacts; the benchmark’s overall verdict is FAIL; and static review cannot confirm directly usable representative outputs. The score is therefore moderate.
The evidence includes version mappings, command examples, manifest hashes, benchmark metrics, and defined evaluation tasks, giving limited auditability. It lacks raw execution logs, independent reproduction, a complete test suite, or CI covering key paths, and several critical details are in files not supplied here. Static review caps this at 5, so full marks are not justified.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →