Design

Channel Map Designer

The DIB definition as a first-class artefact. Assign DUT pins, across sites, to tester channels — against a parsed tester configuration, not a spreadsheet convention — and save one plan that the schematic, the generated program and the DIB checker all read. One source; nothing to keep in sync by hand.

01

Overview

Every load board project answers the same question: which DUT pin lands on which tester channel, for each site? Traditionally that answer lives in an Excel sheet, checked after the fact by a vendor command-line tool. ATE·IQ makes it a native editor: pins down the rows, sites across, channels assigned against the instruments the tester configuration actually contains.

Channel Map Designer with the TMP126 pin-to-channel plan
Fig. 1 — The TMP126 channel plan: SPI pins on UltraPin800 digital channels, VDD force/sense on the DC-07 DCVI, per-site assignments in one grid.

Assignment is type-aware. A digital pin offers digital channels; a power pin offers DCVI channels with force and sense; the auto-assign fills a board's worth of pins with channels of the right type, which you then adjust rather than type from zero. Pin metadata survives round-trips — a ground pin recorded with no channel stays a ground pin with no channel after save and reload, instead of being silently dropped as incomplete.

02

One saved plan, three consumers

The saved plan is authoritative. Three surfaces read it, and none of them keeps a private copy:

SAVED CHANNEL PLAN pins × sites × channels + pinMeta SCHEMATIC CHANNEL FLAGS the drawing's tester annotations GENERATED PROGRAM — ChanMap emitted into the IG-XL project DIB CHECK — 166 rules verified against the same plan reads reads reads no surface keeps its own copy — a plan change propagates to all three, or the mismatch is a finding
Fig. 2 — Single-source fan-out. The drawing, the program and the checker cannot disagree about a channel, because none of them owns one.
ConsumerWhat it takes from the plan
Schematic engine Channel flags on every net. The drawing annotates SCLK with its planned UltraPin800 channel because the plan says so — a schematic label cannot drift from the program.
Program generation The ChanMap sheet of the generated IG-XL project is emitted from the plan. The program's channels match the board's by construction.
DIB check All 166 rules run against the same plan the other two consumed — channel-type mismatches, capability violations, site-consistency errors.
03

How it works

  1. Parse the tester configuration.

    The tester's installed instruments and their channel inventories load from the configuration file. Assignments are made against real slots and channels, not free text.

  2. Lay out pins × sites.

    DUT pins come from the device profile. Each pin gets a type — digital, power, ground, analog — and a row per site.

  3. Auto-assign, then adjust.

    Type-aware auto-assign proposes channels of the correct instrument family for every pin. Manual edits override any cell.

  4. Check natively.

    The 166-rule DIB checker runs offline, in-process — replacing the export-to-vendor-CLI round trip for day-to-day iteration. Findings appear in the editor and in the board's analysis hub.

  5. Save once, consumed everywhere.

    On save, the plan becomes the source for the schematic flags, the generated ChanMap and the DIB check. Pin metadata — including deliberate no-channel pins like grounds — round-trips intact.

04

On the TMP126 demo

The TMP126 plan maps the 3-wire SPI interface — SCLK, the bidirectional SIO, and CS — onto UltraPin800 digital channels, VDD onto the DC-07 DCVI with separate force and sense, and ALERT onto its own digital channel. GND is recorded as a ground pin with no channel, and stays that way across saves.

Downstream, the effect is visible on every other page of this guide: the 5-sheet schematic carries these channels as flags, the generated program's ChanMap matches them exactly, and the analysis hub's pin match reconciles board, plan and program without a manual crosswalk.

Honest boundary The native checker is an offline engine that replaces the vendor CLI loop for iteration speed. Its rule catalogue is our own articulation of the platform's documented constraints: the vendor tool has been run end-to-end against the integration, but the two have not been correlated finding-by-finding on a board carrying real violations, so the catalogue is not presented as calibrated to it. Final DIB sign-off with the vendor's own toolchain remains the closing step, and the platform does not present its offline pass as the vendor's.