Maestro
Live demo — data resets daily at 03:00 UTC. Nothing you enter is saved.

MicroHAPS HT3x2-HT4x2 Adapter

ETT00000014 · Rev R0

in_progresstestelectronics

MicroHAPS HT3x2-HT4x2 Adapter (SH100008643) — the Synopsys-provided "Generic HT3x2-HT4x2" adapter board that mounts on the microHAPS (KU5p tester) and bridges it to the DUT's HT4 connectors. Part of the HT3 test stack alongside microHAPS (ETT00000008) and Snowball (ETT00000010), used to test the B12-N HT3 Panel Board (ETT00000009).

  • E-Sharp does test-development with this board; the board design is Synopsys (SNPS) — E-Sharp does not own/design it.
  • Primary domain: test; secondary: electronics.
  • Why it matters: the adapter defines the microHAPS ↔ DUT-HT4 pin/signal mapping (which FPGA IO drives each CONx_IO / CLK / I²C, and where the HT4-side 12 V and I²C originate) — the missing link needed to complete the B12-N production-test pin map (see B12-N test spec Open Items O-10/O-11).
  • ⚠️ Schematic/ODB for SH100008643 not yet on hand — to be provided by Synopsys (HAPS hardware per the Phase-A SOW), then ingested into Probe.
  • Naming: "x2" = 2 channels per adapter → ~3 adapters for the B12-N's 5 channels.
  • Repository: https://github.com/esharpab/testdevelopment-snps-microhaps
Reports Audit Log

Everything here lives inside a Project (a code + revision, e.g. ESH10000540 R3). The backbone is the V-model, read top-to-bottom: define what the product must do, plan how to prove it, execute the proof on real units, then learn from the field — and the Loop closes back up to the top.
This map is live: a block is green with a count when this project actually has that entity, and dashed/dim when it’s empty. Click any block to open its tab; hover for details. Arrows are the meaningful links; the implicit “belongs to this Project” edge is left out for legibility.

What each thing means

Requirement
One thing the product must do or satisfy — the “what”.
Test Case
A defined check that proves one or more requirements — the “how we prove it”. A verified_by trace link ties a test case to the requirement(s) it covers; that link is exactly what Coverage % counts. (So: a test case refers to the requirements it verifies.)
Verification Plan
A named grouping of test cases, approved before a test campaign and optionally gated by a milestone.
Verification Record
The result of running one test case against one unit: pass / fail / error / na. This is the evidence a requirement is actually met.
DUT
Device Under Test — an individual physical unit (by serial number) that records and test data attach to.
Deviation
A documented waiver against a verification record (e.g. accept a known non-conformance, with justification).
Entry
A knowledge note: a decision (settled choice), notice (assumption / risk / open question), issue (tracked problem), or concept (idea under exploration). It can attach to any other entity.
Design Rule
A reusable, checkable engineering constraint. Running the checks turns each violation into a Conflict.
Conflict
An open flag raised by a failed design-rule check (or an end-of-life / component-library issue) that needs resolving.
Milestone
A dated gate; verification plans can be tied to it.
Field Issue (RMA)
A failure reported from the field on a returned unit; Root-Cause Analysis explains why it happened.
The Loop (S-16)
loop_trace reconciles a field issue against that unit’s own verification record (did it pass at the edge of the band?). closes_loop records the corrective decision or design rule so the lesson is captured — and clears the project’s open-loop count.
Interface / Port
A contract between projects; each port can be driven by a requirement (and cascade one into the connected project).
BOM Component
A part on this project’s bill of materials, optionally linked to the shared Component Library.
GRR Study
A Gauge R&R study measuring how repeatable a test case’s measurement is.
Test Data
Production / Maestro run results recorded against DUTs — the population behind a single verification record.
0% Coverage
0% Done
0 Requirements

Timeline

Color = derived gate state · hover a tile for its note.
not started
🏁 Release
· 3/6

Status & gates

Chronological — Release is the final gate. Derived & read-only; edit via trace_milestone_* tools.
Release / Readiness not started 3/6 met
pending Requirements approved
  • No requirements in scope
pending Coverage ≥ 100%
  • No requirements in scope
pending All test cases pass
  • No test cases in scope
met No blocking issues open
met Deviations resolved
met Interfaces frozen

Coverage — 0.0% · Done — 0.0%

0 Done 0 Partial 0 Not Started 0 Missing0 Obsolete
Requirements
0 of 0
CodeTitleCategoryCoverageStatus