/hsb-ip-packetizer

name: hsb-ip-packetizer
author: "Holoscan Team <holoscan-team@nvidia.com>"
description: Choose or explain HSB Sensor RX packetizer fields for HOLOLINK_def.svh. Do not use for full defs, validation, or runtime APB programming.
version: "0.1.0"
tags:
  - holoscan
  - hsb
  - packetizer
  - systemverilog
  - fpga
license: Apache-2.0
compatibility: Targets HSB IP rev 16'h2604; backward-compatible with 16'h2603. Prefer live HSB IP packetizer 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
    - packetizer
    - systemverilog
  languages:
    - systemverilog
  artifact: HOLOLINK_def.svh
  hsb_ip_version: "16'h2604"

HSB IP Packetizer Skill

Purpose

Choose packetizer-related `HOLOLINK_def.svh` fields for the NVIDIA Holoscan Sensor Bridge Sensor RX path.

This skill owns only the packetizer slice of `HOLOLINK_def.svh`:

• `SIF_RX_PACKETIZER_EN[]`
• `SIF_RX_VP_COUNT[]`
• `SIF_RX_SORT_RESOLUTION[]`
• `SIF_RX_VP_SIZE[]`
• `SIF_RX_NUM_CYCLES[]`

Use `hsb-ip-def` for whole-file generation, validation, comparison, and non-packetizer macros.

Prerequisites

• `SENSOR_RX_IF_INST` must be defined and nonzero before packetizer fields are relevant.
• Per-RX-interface `SIF_RX_WIDTH[]` values and the user's data manipulation intent are required before deriving enabled packetizer values.
• Live packetizer RTL is preferred for source-sensitive claims; bundled references cover known rev `16'h2604` and compatible rev `16'h2603`.
• Whole-file generation and validation remain the responsibility of `hsb-ip-def`.

Instructions

• Only configure packetizer fields when `SENSOR_RX_IF_INST` is defined. If Sensor RX is disabled, say no packetizer fields are needed.
• First classify the request as Standalone SVH, Def-Skill Handoff, Explain, or runtime APB pattern-RAM. For Def-Skill Handoff, load `references/handoff-contract.md` and make `packetizer_profile_overlay` the first non-empty output after any required clarification.
• Ask one question per turn only while collecting the data-description facts needed to derive a grounded profile. Prefer deriving macro values from those facts instead of requesting per-macro confirmation.
• Use sensor-agnostic language. Say "sensor data", "data word", "stream", "bandwidth", and "packetization"; use camera-specific language only after the user says the sensor data is image/camera data.
• Never silently default enabled packetizer fields. Derive them from the user's stated data layout and manipulation intent, print the complete field set in one block, and then explain what the selected settings enable and what assumptions they encode.
• Avoid ungrounded "typical", "common", "most designs", or corpus-frequency claims. Anchor statements to HSB docs, RTL behavior, or the user's stated requirements.
• Keep runtime APB pattern-RAM programming out of v1 generation. `HOLOLINK_def.svh` enables/sizes hardware; runtime software still controls pattern RAM, virtual-port selection, sort controls, bypass, padding, duplication, and latency.
• In a handoff from `hsb-ip-def`, use facts already known by that def flow. If the prompt gives RX count, enabled/pass-through intent, lane or stream width, virtual stream count, and cycle window, emit the overlay without re-asking for macro names or whole-file details. Leave final merge and full validation to `hsb-ip-def`.

Live HSB IP source policy

Prefer live HSB IP source over bundled packetizer 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 `HOLOLINK_top.sv` plus the packetizer RTL files:

• `<hsb-ip-root>/top/HOLOLINK_top.sv`
• `<hsb-ip-root>/packetizer/packetizer_top.sv`
• `<hsb-ip-root>/packetizer/packetizer.sv`
• `<hsb-ip-root>/packetizer/virtual_port.sv`
• `<hsb-ip-root>/packetizer/odd_even_gen.sv`

2. Read `HOLOLINK_REV` and `HOLOLINK_BACKWARD_COMPAT_REV` from `HOLOLINK_top.sv` when present. 3. Verify that `HOLOLINK_top` still maps the five def fields into `packetizer_top` as documented before making source-sensitive claims. 4. If the rev is newer, unknown, or live RTL disagrees with this skill's references, state the mismatch. Trust the live RTL for explanation, avoid unsupported assumptions, and do not emit an enabled packetizer overlay unless the field mapping and RTL constraints can be verified from the live source.

When no source is available, use the bundled references as known-revision guidance and say that the answer is based on the skill's supported HSB IP rev.

Reference Loading

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

| File | When to load | |---|---| | `references/packetizer-def-fields.md` | Choosing or explaining `HOLOLINK_def.svh` packetizer fields, array length rules, bypass placeholders, RTL-derived constraints, or standalone SVH output formatting | | `references/packetizer-architecture.md` | Explaining packetizer blocks, data flow, clocks, APB registers, runtime-vs-def split, or why a field exists | | `references/handoff-contract.md` | Producing `packetizer_profile_overlay` YAML for `hsb-ip-def` or enforcing output-mode separation |

Workflow Decision

1. If the user is working inside a `HOLOLINK_def.svh` generation flow, use **Def-Skill Handoff**. 2. If the user asks for lines to add to an existing/new `HOLOLINK_def.svh`, use **Standalone SVH**. 3. If the user asks what a field does, why a value matters, or whether a combination is safe, use **Explain**. 4. If the user asks for APB pattern RAM programming, explain that it is runtime configuration and outside v1 generated output; load `references/packetizer-architecture.md` for the register context.

Requirement Discovery

Col