/hsb-ip-create-top

name: hsb-ip-create-top
author: "Holoscan Team <holoscan-team@nvidia.com>"
description: Create or explain fixed-format HSB FPGA_top.sv wrappers from validated HOLOLINK_def.svh files. Do not use for def generation or validation.
version: "0.1.0"
tags:
  - holoscan
  - hsb
  - fpga
  - systemverilog
  - top-level
license: Apache-2.0
compatibility: Targets HSB IP rev 16'h2604; backward-compatible with 16'h2603. Prefer live HSB IP source when available; warn on unknown revisions. Designed to work standalone or as a companion to hsb-ip-def.
metadata:
  author: "Holoscan Team <holoscan-team@nvidia.com>"
  team: holoscan
  domain: fpga
  vendor: nvidia
  tags:
    - holoscan
    - hsb
    - fpga
    - top-level
    - systemverilog
  languages:
    - systemverilog
  artifact: FPGA_top.sv
  source_artifact: HOLOLINK_def.svh
  hsb_ip_version: "16'h2604"

HSB IP Create Top Skill

Purpose

Create a fixed-format SystemVerilog top-level scaffold that instantiates `HOLOLINK_top` and declares the HSB-facing signals required by a validated `HOLOLINK_def.svh`.

This skill owns only the top-level scaffold around the HSB IP:

• SPDX/Apache license header
• `HOLOLINK_def.svh` include
• `FPGA_top` module shell
• HSB-facing signal declarations
• `HOLOLINK_top` instantiation
• comments/TODOs for top-level integration

Use `hsb-ip-def` for `HOLOLINK_def.svh` generation and validation. Do not create or validate the defs file here.

Prerequisites

• A validated `HOLOLINK_def.svh` path or pasted file content is required before generating `FPGA_top.sv`.
• Live `HOLOLINK_top.sv` source is preferred when source-sensitive port extraction is needed; bundled references cover known rev `16'h2604` and compatible rev `16'h2603`.
• The user must provide or accept the output path when writing a scaffold file.

Instructions

• Require a validated `HOLOLINK_def.svh` before creating `FPGA_top.sv`. If the user does not have one, invoke or direct them to `hsb-ip-def` first.
• Treat live `HOLOLINK_top.sv` as the source of truth for ports, directions, macro gates, and IP revision whenever it is available.
• First classify the request as Standalone Create Top, Def-Skill Handoff, or Explain. Load only the references required for that workflow and do not re-read the same reference just to reconfirm formatting.
• Use `references/fixed-format.md` as the baked formatting and naming style. Do not inspect example top-level files just to confirm formatting during normal generation.
• Emit a fixed-format scaffold, not a complete project top. Because the surrounding design is unknown, the generated `FPGA_top` module normally has no top-level ports.
• Derive active signal groups from the validated defs file. Do not connect ports that are absent from `HOLOLINK_top` under the active macro set.
• Preserve `HOLOLINK_top` port shapes exactly: keep packed vector widths before the signal name and unpacked interface-array dimensions after the signal name.
• When using bundled known-rev references, still preserve the signal shapes in `references/fixed-format.md`, including unpacked arrays for multi-interface `*_tdata`, `*_tkeep`, and `*_tuser` buses and the APB shape documented there.
• Use sensor-agnostic language. Say "sensor data", "sensor interface", and "stream"; use camera-specific language only after the user says the design is camera-specific.
• Ask one plain-language question per turn when information is missing. Keep source-selection questions as plain-language prompts rather than radio buttons, structured choices, or multi-question prompts.
• Do not invent project-specific integration details. Leave concise TODO comments where the surrounding design must connect to HSB.
• For packetizer comments in `FPGA_top.sv`, use generic wording such as "data manipulation behavior".
• In final summaries, include the defs validation/source status, the port-map source used, and the emitted HSB signal groups. Do not enumerate what is outside the scaffold's scope. Use only this generic note: "This file is a reference/template for hooking up top-level signals and companion IP to the HSB IP."

Live HSB IP Source Policy

Prefer live HSB IP source over bundled references whenever the user's workspace provides it. The bundled references describe known rev `16'h2604` and backward-compatible rev `16'h2603`; live source is the authority for the checked-out IP.

When source is available:

1. Locate `<hsb-ip-root>/top/HOLOLINK_top.sv`. Known roots include `hw/nvcpu_dgx_fpga/vrtl/hololink/` and public-release `fpga/nv_hsb_ip/`. 2. Read `HOLOLINK_REV` and `HOLOLINK_BACKWARD_COMPAT_REV` from `HOLOLINK_top.sv`. 3. Read the `HOLOLINK_top` module declaration to confirm port names, directions, widths, ordering, and `ifdef`/`ifndef` gates. 4. If the rev is newer, unknown, or the live source disagrees with this skill's references, state the mismatch. Trust the live source for IO extraction and warn that bundled references may need an update.

When no source is available, use the bundled references as known-revision guidance and say the scaffold is based on the skill's supported HSB IP rev. If the user already authorized using the bundled known-rev port reference when no checkout is obvious, do a brief search of obvious roots and then proceed with bundled references instead of asking the live-source question.

If the source root is not obvious, ask conversationally in one turn:

Do you have a current HSB IP `HOLOLINK_top.sv` source checkout you want me to use for port extraction, or should I use the skill's bundled known-rev port reference?

Accept either a path or a "use bundled reference" answer.

Reference Loading

Load only the reference needed for the user's task:

| File | When to load | |---|---| | `references/source-policy.md` | Finding live HSB IP source, handling unknown revisions, or deciding source/reference precedence | | `references/fixed-format.md` | Generating or explaining the fixed `FPGA_top.sv` scaffold format | | `referenc