Ixana · Silicon

Wi-R BAN — YR23

The first Wi-R body-area part a partner could design in rather than admire — 0.12 nJ/bit at 5 Mbit/s, the silicon under the shipping dev kit and both published reference designs.

In production
Role
Program manager, silicon delivery (RTL/AMS/PS India · HW/FW US) — first-silicon scope and launch gates
Team
5 functions across 2 sites — RTL, analog/mixed-signal and physical design in India; hardware and firmware in the US
Stage
In production — the part under the BAN dev kit and every on-body reference design since

Validation capacity set the tapeout date.

Problem. Wi-R was a published result and a compelling demo, and no OEM puts a demo on a bill of materials. Turning it into a part meant committing to numbers across a whole data-rate ladder, on a date, against a specification an engineer could draw a schematic from before silicon existed.

What I did. I ran delivery of first silicon across five functions and two sites. The founder owned the product bets; I owned the system that turned them into a shippable part on a date — first silicon’s scope, what shipped as errata against what forced a respin, and the launch gates.

Result. YR23 is in production holding 0.12 nJ/bit at 5 Mbit/s across a 16-device on-body network — the public specification — and it is the part under the shipping dev kit and both published reference designs. How first silicon was scoped, gated and released, escape by escape, is the worked example this page walks through.

01Why this, and why now

The commercial stake was specific: a hearables OEM and an AR-wearables maker had both seen Wi-R work on a bench and asked the same question — what do we put in the schematic. Neither would staff a program against a research result, and if the answer stayed “a demo and a paper” we lost the first design-ins.

What those teams were weighing was an energy budget. A wearable running for days off a small cell spends most of it on the radio, and every alternative on their shortlist sits an order of magnitude or more above Wi-R on energy per bit.

Energy per bit relative to Wi-R BAN: Wi-Fi and Bluetooth LE 83 times higher, ultra-wideband 8 times higherWi-Fi / Bluetooth LE83× — about 10 nJ/bitUltra-wideband8× — about 1 nJ/bitWi-R BAN (YR23)1× — 0.12 nJ/bit at 5 Mbit/s090 × Wi-R BAN
Energy per bit across the links these segments were choosing between, expressed as a multiple of YR23. Alternative figures are Ixana's published comparison; the YR23 figure is from the public specification. Plotted as a ratio because on an absolute axis the Wi-R bar is invisible — which is the argument, but not a readable chart.

That gap is why a part was worth building rather than a paper worth citing, and why first silicon had to be honest about the whole ladder: an energy claim at one operating point is a headline; a design-in needs the number at the rate the product will run.

02The problem as people experienced it

Rather than ask engineers how bring-up went, I audited the bench logs from the first 24 evaluation boards on first silicon and coded every stall by cause. The logs were kept for debugging, not for me — which is what makes them worth reading.

What they didWhere it stalledEvidence
Powered the board and looked for a linkElectrode trim differed board to board19 of 24 needed a manual trim pass
Reached for a scope on the electrode nodeProbe capacitance loaded the node and hid the signal11 of 24; 3 concluded the part was dead
Compared against the reference boardReference had a trim nobody had documented8 of 24; the single longest stall
Filed it as a silicon bugMost were board or setup issues, not the die26 of 41 escapes closed without a die change
Days from board build to first stable on-body link across 24 evaluation boards, clustered between 7 and 14 days against a 14-day gate01033–677–10811–14415–20220+14-day gatedays to first stable on-body link
Bring-up time across the first 24 evaluation boards, coded from bench logs. Median 11 days. The six boards past the gate are the finding: they were not worse silicon, they were boards whose trim drifted furthest from the reference — a characterisation gap, not a die defect.

The reframe: what looked like an unstable part was an uncharacterised one. The die behaved consistently; the electrode interface around it did not, and nothing in our documentation told an engineer what good looked like.

03My role and approach

I should be precise about what I owned, because a title on a silicon program is easy to inflate. The founder owned the product bets — that Wi-R should exist, which market, what the part is for. I owned the delivery system that turned bets into a shippable part on a date: five functions, two sites, one schedule, and the gates that decided what shipped.

That system is where delivery fed product. Validation capacity set the tapeout date; tolerable escapes set what first silicon could claim; whether a workaround fit in firmware decided whether a feature shipped at all.

Key decisions

  • Scope first silicon to what an OEM can commit to, not what demos best. Scope arguments were settled by asking what an engineer needs before drawing our part into a schematic.
  • One data-rate ladder fully characterised, not two modes half-characterised. A second mode would have doubled the validation matrix against fixed capacity, and produced two sets of figures with caveats on both.
  • Validation capacity set the tapeout date. Design was never the binding constraint; the bench hours to prove the part were. Scheduling backwards from validation is why the date held.
  • Run the program on instrumented data, not status meetings. Stage timing and delay causes came from the delivery tooling built for it — instrumented stage and capacity data. Across nine time zones a shared record beats a meeting half the room attends asleep.

04What I cut

Shipped in v1

  • 100 kbit/s – 5 Mbit/s ladder, fully characterised
  • Up to 16 devices per on-body network
  • Sub-1 ms link latency
  • Host interface with a reference driver
  • Characterised electrode interface and trim procedure

Deferred

  • Higher-rate mode (became YR31)
  • On-die per-unit trim storage
  • Multi-network coexistence

Cut

  • On-die link encryption
  • Second host interface option
  • Field-updatable PHY parameters

On-die link encryption was the hardest cut. It failed on two constraints at once: die area against a closed floorplan, and a validation matrix with no bench hours before the committed tapeout. Wi-R’s security position is physical — the field stays within about 0.1 m of the body, so there is no signal at 5 m to intercept — and the reference driver encrypts host-side where compliance needs it. The cost is that anyone needing crypto in silicon waits for a later part.

05How I got it agreed

The post-silicon validation lead wanted to hold first silicon for a respin rather than release with documented errata and firmware workarounds. His argument was not caution for its own sake: a part that needs a workaround gets designed in wrong by somebody who never opened the errata sheet, and the silicon gets the blame.

He was right about how errata sheets get read, so I stopped arguing schedule and split the 41 escapes into two kinds: those that change what the part can do, and those that change how you must drive it. Only three were the first kind, none in the launch segments’ paths. That turned risk appetite into a question about three specific defects.

He agreed on two conditions. Every workaround ships as code in the reference driver rather than a note in a PDF — a partner cannot design it in wrong by skipping the document; six firmware weeks, and the best thing on this page. And any later escape in a launch-segment path reopened the respin conversation, him holding the pen.

06What was built

A body-area transceiver in a package a wearable can carry, moving 100 kbit/s to 5 Mbit/s across up to 16 devices on one body at sub-millisecond latency, at 0.12 nJ/bit at full rate. Its range is deliberately asymmetric — 10 to 15 m along the body, about 0.1 m off it — which is the security model, not a limitation.

Wi-R BAN YR23 transceiver package
  1. 1The part number is on the package face. Support threads on first silicon stalled repeatedly on which revision a partner actually held. Marking it externally removed a round trip from most of them.
  2. 2One package, no variants at launch. A second package option was requested before we had shipped the first. Two packages means two qualification campaigns against the validation capacity that was already setting our date.
  3. 3Pin-out committed before first silicon returned. OEMs cannot start a board until the pin-out is frozen. Publishing it early cost us the option to change it and bought two design starts that would otherwise have waited a quarter.
  4. 4The electrode interface is specified, not left open. The 24-board audit showed the interface around the die was what varied. Specifying it turned the largest source of bring-up stalls into a documented procedure.

Ixana YR23 package, from Ixana's published product photography. The package, part marking and full specification are public; internal design detail is not shown. Happy to walk through the real program in a conversation.

07Tradeoffs

TensionWhat I choseWhat it cost
Schedule vs a clean partShip with documented errata, workarounds in the driverSix firmware weeks, and a permanent obligation to keep driver and errata in step
Feature breadth vs validation capacityOne characterised ladder; encryption and second mode outTwo evaluations paused waiting for silicon-level crypto
Design freedom vs design-in speedPin-out frozen before first silicon returnedNo room to fix a pin-out mistake without a respin we had refused
Local autonomy vs one scheduleSingle gate calendar across both sitesReal meeting-hour cost on two teams, permanently and unevenly

08Impact and outcomes

Before tapeout we agreed first silicon failed on one condition: if it could not hold a sustained on-body link at full rate on an ordinary person without a metal fixture, it went back for a respin before any customer saw it. Interop was the guardrail — the date could not be won by a part that only worked on our reference board.

0.12 nJ/bit @ 5 Mbit/s
Energy per bit delivered on first silicon
0 respins
Die revisions between first silicon and production
11 days
Median board build to first stable on-body link
41 3 blocking
Escapes found after tapeout
4
OEM programs designed in before the dev kit existed
94% of link attempts across 7 host platforms
Interop pass rate across host platforms (guardrail)
The 41 post-tapeout escapes by category: analogue front-end trim 15, link state machine 11, host interface timing 7, power sequencing 5, clock lock 2, other 1 — three categories carry 80 percent0160%100%80% of escapes15AFE trim11Link FSM7Host timing5Power seq.2Clock lock1Otherescapescumulative share
Escapes by category, from the bring-up defect log. Three categories carry 80%, and all three are addressable in firmware or documentation rather than in the die — which is the whole reason a respin was avoidable rather than merely avoided.

How we counted. An escape is an issue found after tapeout that a pre-tapeout check should have caught, logged whether or not it turned out to be the die. Blocking means it could not be closed in firmware or documented as a workaround at triage — the three that carried the label were exactly that when triaged, and later driver work closed all three, the reclassification the summary counts. Board and setup problems stay in deliberately: 26 of the 41 were never silicon, and excluding them would hide where bring-up time went. The four OEM programs counted here are pre-kit direct engagements, not the dev-kit page’s kit-mediated design-ins.

Part configuration — YR23 Wi-R BAN transceiver · 100 kbit/s – 5 Mbit/s · 0.12 nJ/bit at 5 Mbit/s · up to 16 devices per network · sub-1 ms link latency · 10–15 m along-body, ~0.1 m off-body containment · physical-layer security by E-field confinement · host interface with reference driver

09What I'd do differently

I scheduled the die and left the interface around it to look after itself. Every expensive surprise in section 02 came from the electrode interface, the one part of the system with no owner and no line on the schedule — not a design deliverable, not a validation deliverable, so it belonged to nobody.

I would also publish the errata differently. Shipping workarounds in the driver was right, and quietly created a second problem: partners who take the driver get the fix invisibly and never learn the constraint, so when they write their own integration they reintroduce it.