Ixana · Silicon
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 productionValidation 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.
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.
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.
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 did | Where it stalled | Evidence |
|---|---|---|
| Powered the board and looked for a link | Electrode trim differed board to board | 19 of 24 needed a manual trim pass |
| Reached for a scope on the electrode node | Probe capacitance loaded the node and hid the signal | 11 of 24; 3 concluded the part was dead |
| Compared against the reference board | Reference had a trim nobody had documented | 8 of 24; the single longest stall |
| Filed it as a silicon bug | Most were board or setup issues, not the die | 26 of 41 escapes closed without a die change |
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.
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.
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.
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.
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.

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.

| Tension | What I chose | What it cost |
|---|---|---|
| Schedule vs a clean part | Ship with documented errata, workarounds in the driver | Six firmware weeks, and a permanent obligation to keep driver and errata in step |
| Feature breadth vs validation capacity | One characterised ladder; encryption and second mode out | Two evaluations paused waiting for silicon-level crypto |
| Design freedom vs design-in speed | Pin-out frozen before first silicon returned | No room to fix a pin-out mistake without a respin we had refused |
| Local autonomy vs one schedule | Single gate calendar across both sites | Real meeting-hour cost on two teams, permanently and unevenly |
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.
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
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.