Hsb Ip Packetizer

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:

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

Collect these facts in order, skipping facts the user already supplied. Stop asking as soon as the data manipulation description is specific enough to derive the profile.

1. SENSOR_RX_IF_INST: number of Sensor RX interfaces. If undefined or zero, stop.
2. SIF_RX_WIDTH[]: per-RX-interface input width. This is DIN_WIDTH for each packetizer instance.
3. Packetizer intent per RX interface: pass-through, data rearrangement/manipulation, split into virtual ports, replicate/duplicate, or other manipulation.
4. The data layout for enabled interfaces: lane/chunk width, number of output virtual streams, whether the manipulation stays within one input cycle or spans multiple cycles, and any exact ordering/replication requirement.

Skip per-macro confirmation prompts such as "Confirm SIF_RX_VP_COUNT?", "Confirm SIF_RX_SORT_RESOLUTION?", "Confirm SIF_RX_VP_SIZE?", or "Confirm SIF_RX_NUM_CYCLES?" Ask for missing data-shape facts, such as "How many virtual streams should RX0 split into?" or "What bit granularity is being rearranged?"

Deriving Fields

After the required facts are known, derive all packetizer arrays together:

• SIF_RX_PACKETIZER_EN[i] = 1 for RX interfaces that need packetizer hardware for rearrangement, split, replication, or other runtime-controlled data manipulation; 0 for pass-through interfaces.
• SIF_RX_VP_COUNT[i] equals the number of virtual output streams/ports required by the user's manipulation for that RX interface.
• SIF_RX_VP_SIZE[i] is the per-virtual-port data size/width in bits. For an equal contiguous split of one SIF_RX_WIDTH[i] input word into N virtual ports, use SIF_RX_WIDTH[i] / N if it is a positive power-of-two divisor and matches the user's intent.
• SIF_RX_SORT_RESOLUTION[i] is the bit granularity of the data rearrangement operation. If the user describes fixed-size lanes, use that lane size when it passes the RTL-derived constraints. If no ordering manipulation is needed and the packetizer is used only for contiguous split/replication, use SIF_RX_WIDTH[i] to disable the sort network internally when legal.
• SIF_RX_NUM_CYCLES[i] is the number of input sensor-data cycles that participate in the manipulation. Use 1 for single-cycle rearrange/split/replication; use the stated cycle window when the manipulation spans multiple input cycles.

If several profiles remain plausible after reading the data description, ask one clarifying question about the behavior or data shape that distinguishes them. Do not fall back to "typical" packetizer values.

For disabled entries in a mixed enabled/disabled design, fill the peer arrays with ignored placeholder values matching the RTL bypass constants:

• SIF_RX_VP_COUNT[i] = 1
• SIF_RX_SORT_RESOLUTION[i] = 2
• SIF_RX_VP_SIZE[i] = 32
• SIF_RX_NUM_CYCLES[i] = 1