AUSTURUSA / INTRODUCING FIPE 001

KNOW
THE EDGE.

Your silicon works at nominal timing. How close is it to failure?

FIPE is a programmable timing and observation engine for digital interfaces—designed to turn controlled protocol violations into measurable operating margins, statistical evidence, and engineering decisions.

✳ FIRST-SILICON CHARACTERIZATION / FPGA PILOT IN DEVELOPMENT
CONCEPT CGI / TIMING IS A MEASURABLE PRIMITIVE ↓
01 / THE PROBLEM
FROM PASS / FAIL TO HOW MUCH

The bus works.
That tells you almost nothing.

A successful transaction confirms that a device worked once, under one set of conditions. It doesn't tell you how much setup time the part needs, where acknowledgments begin to fail, or whether the next silicon revision has shifted its margins.

FIPE is built for the questions hiding behind nominal functional pass/fail: timing tolerances, part-to-part variation, unexpected failure regions, and the evidence needed to investigate them.

02 / THE ENGINE

Timing, under control.

One programmable engine for controlled stimulus, synchronized capture, and repeatable timing experiments.

01 — CONTROL✳
SCLSDAΔt = +80 ns
EXPLICIT TIMESTAMPS / RUNTIME SKEW

Move the edge.
Keep the meaning.

Describe transactions as scheduled pin events. Perturb selected event classes at runtime without rewriting entire protocol sequences for each sweep.

02 — OBSERVE↗
CAPTURE / CLASSIFY / REPLAY

See what changed.

Capture responses against a common timebase and associate outcomes with the specific timing condition that produced them.

03 — QUANTIFY↗
SWEEPS / MARGINS / STATISTICS

Find the boundary.

Estimate timing thresholds, quantify uncertainty, and inspect where devices or populations diverge.

03 / THE OUTPUT

From bus traffic
to engineering evidence.

Not another folder of oscilloscope screenshots. A coherent characterization study: measured or simulated margins labeled by evidence type, per-device variation, transaction-level outcomes, and analysis with explicit uncertainty.

  • Per-device t50 / modeled t99 boundaries
  • Pass-rate sweeps and operating maps
  • Population and revision comparisons
  • Traceable failures and portable exports

The interactive preview shown here uses simulated EEPROM data. No physical FIPE-to-DUT measurement is claimed.

FIPELAB / CHARACTERIZATIONSIMULATION
STUDY / EEPROM TIMING

Sample population

Data setup — model-estimated t99

12 DUTs
WORST DEVICEA-05
ESTIMATED t99214 ns
REFERENCE250 ns
DEVICE-BY-DEVICE TIMING ESTIMATESMARGINAL / UNCERTAIN
BASED ON SIMULATED FIPE STUDY / NOT PHYSICAL DUT DATAREV I · FIPELAB
04 / THE EVIDENCE

Built to be challenged.

Different kinds of proof are not interchangeable. Here is what is implemented, what is simulated, and what the pilot must still establish.

PUBLIC / ENGINEERING
50MHz

Earlier ASIC physical-design baseline

Reported timing closure at 50 MHz on an IHP 130 nm routed implementation, with clean DRC/LVS/antenna checks and formal/gate-level evidence for the documented baseline.

Inspect the repository ↗NEWER RTL CHANGES REQUIRE A FRESH GDS RUN
PRIVATE / SIMULATION
45,760trials

Automated characterization study

A simulated two-supplier EEPROM study with timing sweeps, estimated boundaries, uncertainty intervals, shmoo plots and transaction-level inspection.

Request a technical walkthrough ↗12 SIMULATED DEVICES · NOT PHYSICAL SILICON
PRIVATE / METHOD STUDY
1,200cases

Statistical method qualification

Monte Carlo experiments test estimator bias, interval coverage and classification behavior under a specified single-threshold simulation model.

Discuss the methodology ↗MODEL-CONDITIONAL RESULTS · NOT A HARDWARE CERTIFICATION
✳

The honest frontier: Physical FPGA implementation, DUT-pin timing calibration, independent instrument correlation, and repeatable real-device characterization are the next commercial validation gates.

05 / THE ARCHITECTURE

Many protocols.
One timing machine.

FIPE expresses protocol behavior as timestamped events, programmable transformations, and observations. The timing engine can be reused; each new electrical interface still requires the appropriate physical layer, test definitions and validation.

PILOT FOCUS RTL / SIMULATION DEMO FRAME-LEVEL DEMO
I²CFIRST PILOT FOCUS
SPIFIRST PILOT FOCUS
UARTRTL / SIMULATION
1-WIRERTL / SIMULATION
JTAGRTL / SIMULATION
SWDRTL / SIMULATION
USB-LSPACKET-LEVEL DEMO
CAN 2.0AFRAME-LEVEL DEMO
06 / DESIGN-PARTNER PROGRAM EXPLORING FIRST PILOTS

FIRST SILICON.
REAL MARGINS.

We're looking for an initial engineering partner to help validate FIPE on physical I²C/SPI devices and shape a practical pre-ATE characterization workflow.

01 / DEFINE

Choose a meaningful device

One interface, a few critical timing questions, an agreed test fixture and acceptance criteria.

02 / MEASURE

Correlate and characterize

Controlled timing sweeps, repeatability checks, and independent measurement correlation at DUT pins.

03 / DELIVER

Get the evidence

Interactive HTML, machine-readable data, uncertainty analysis and engineering findings.

Discuss a pilot ENGINEER-TO-ENGINEER. NO SALES FUNNEL.
Jack Shaquer
FOUNDER / ENGINEERING
07 / THE PERSON BEHIND THE INSTRUMENT

Built by an
engineer.

Jack Shaquer

Electrical engineer with professional experience spanning embedded hardware, PCB development, power conversion, closed-loop mixed-signal electronics, hardware validation, and Python-based instrumentation. Current independent work includes FIPE digital ASIC design and a proposed formally checked power-controller safety kernel.