When Priya and I left our previous roles to build Photoniq, we made a deliberate choice to bootstrap as long as possible. That choice wasn't ideology — it was engineering discipline. We wanted to validate that the coverage prediction approach actually worked before asking anyone to fund it. Raising money before you know if the core technology generalizes across design domains is a bad tradeoff; you end up accountable to a timeline before the science is settled.
We're now announcing that Photoniq has closed initial angel funding. This post explains what we're doing with it and why the timing felt right.
What We Validated Before Raising
The first eight months were entirely self-funded and focused on one question: does the RTL-level graph model generalize beyond the design families it was trained on? The answer needed to be yes before we talked to anyone about money.
By mid-2025 we had the answer: top-10 precision above 85% on held-out design classes that weren't represented in training. That's the number that mattered. It meant the model was learning structural features of coverage gaps, not memorizing patterns in our training corpus. We wrote about the model architecture journey in June — the short version is that three approaches failed before we landed on the RTL-level graph with coverage bin context as node features.
We also had a small group of early access users running the tool on real designs. The feedback loop from those users shaped the ingestion layer, the simulator normalization pass (the VCS/Questa/Xcelium differences turned out to be a bigger problem than we anticipated), and the output format. Having users before raising was intentional — investor conviction built on running software beats investor conviction built on a demo deck.
What the Funding Enables
Three concrete things that the angel funding unlocks:
RTL corpus expansion. The coverage prediction model's quality ceiling is determined by training data diversity. Our current corpus covers processor pipelines, memory controllers, network-on-chip IP, and early custom accelerator designs reasonably well. The gaps are in highly parameterized protocol IP (PCIe, DDR5 PHY-level blocks), custom accelerator datapaths with non-standard FSM structures, and assertion-heavy IP where SVA property coverage is the primary sign-off metric. Building labeled RTL/UCDB pairs for these categories requires sustained engineering time — it's the work that doesn't fit in a nights-and-weekends model.
Simulator support breadth. We support VCS, Questa, and Xcelium today. Riviera-PRO is on the near-term list, and there's clear demand from teams using open-source simulators (Verilator, Icarus) for coverage analysis, even though those simulators don't natively produce UCDB-format output. That requires building a separate coverage database adapter layer. The architecture exists; building and testing it is engineering time we now have.
Team. We're two technical co-founders plus two engineers. The product scope we're targeting — coverage prediction accurate enough to guide tape-out decisions — requires depth in ML, verification methodology, and EDA tool integration simultaneously. Adding a fifth engineer with EDA tool integration experience will unblock several items that have been waiting on Devlin's time for months.
What Hasn't Changed
The scope stays narrow. We solve the coverage plateau problem for RTL verification teams. We're not building a general-purpose AI for EDA, we're not adding a schematic editor, and we're not expanding into ATPG or DFT — those are adjacent problems with different requirements and different customer conversations. The coverage prediction accuracy bar is high enough that staying focused is the only way to keep raising it.
The pricing model stays SaaS. The EDA industry's incumbent pricing model — perpetual licenses at $50K-$500K per seat, 18-month sales cycles — is what it is, and there's a real market for a tool that engineering teams can evaluate and adopt without a procurement process. We're not trying to replace the incumbents; we're trying to be useful to teams those incumbents don't serve efficiently.
We're also staying in Santa Clara. The chip design ecosystem density in Silicon Valley is a genuine advantage for a tool built by and for DV engineers. The conversations that happen at conferences and in coffee shops are part of the corpus-building process — hearing directly about the verification problems teams are actually hitting in 2025 shapes what we build in 2026.
A Note on the Path Ahead
Coverage closure isn't a solved problem for the industry, and we're not claiming we've solved it. What we've built is a tool that handles the tractable majority — the functional coverage bins where structural analysis of RTL + current coverage state produces a reliable, actionable prediction. The hard remainder — deep assertional coverage, exotic parametric IP, cross-hierarchy stimulus sequences — is still largely a human DV expertise problem.
The corpus expansion and model work funded by this round is aimed at shrinking that hard remainder. Not eliminating it — we're not claiming that trajectory — but moving the boundary enough that a DV lead working under real tape-out pressure has more of the low-hanging coverage closure handled automatically and can focus their energy on the genuinely hard cases.
If you're a DV engineer or DV lead who wants early access, the request form is on our site. We're still selective about who we onboard — not because of capacity limits, but because we want to actually talk to users before adding them rather than opening the floodgates and losing signal in the noise.
— Hiroshi Watanabe, Co-Founder & CEO, Photoniq
