WIOWIZ builds semiconductor design infrastructure in India. We are developing EDA tools across the RTL to GDSII flow, together with the IP, the verification knowledge and the automation needed to use them. Our current focus is frontend design and verification. The longer direction is the complete silicon flow.
The rest of this page is how we got here, because the direction only makes sense once you know where it came from.
We started by trying to build a chip
WIOWIZ began in March 2025 as a fabless team working on an edge AI design, a small, low power chip meant to run several small models on device, for applications in agriculture, defence and industrial settings. We wanted to see whether a small team could reach a chip on an accessible, lower cost path rather than starting from the traditional cost structure.
Why we chose the open route
Open PDKs and open source EDA had made a lot of the chip design path reachable. Choosing them was not a statement about commercial tools. It was a way to find out how far the design could go on a modest budget, and to learn the flow ourselves rather than treat it as something we rented.
The tapeout we postponed
The open flow carried the design a long way. Where it stopped was not one missing script or one routing problem. The class of chip we were building exposed the difference between an accessible design flow and a production closure ecosystem. Those are not yet the same thing. We had three choices: simplify the chip until it fit what was available, move into a commercial ecosystem and take on its cost and dependency, or postpone the tapeout. We postponed it. We did not treat that as open source failing us. It had taken us further than we expected. The lesson was narrower and more useful. Being able to run a design flow and having the full ecosystem to close the design you actually want to manufacture are different problems.
Why we decided to build the tools ourselves
The tapeout also changed how we saw the tools we had been writing. Until then, open source EDA was the foundation of the chip flow, and our own work filled the gaps around it. That was the right shape while the goal was to get one chip through.
Once we decided to continue with EDA as a direction for the company, the requirement changed. Filling gaps around an existing flow is not the same as building EDA infrastructure we can develop, validate and control ourselves. We still use open source software where it makes sense in our own engineering, and we still value what the open ecosystem made possible for us. But the engines we are taking forward as WIOWIZ are being built as our own technology, not as wrappers around an open source flow.
That decision made the work much larger. A simulator has to implement the language and its execution semantics itself. Clock and reset domain analysis needs its own structural reasoning. Formal needs mathematical engines whose results can be checked. Physical design brings another set of algorithms and a much longer validation cycle. We knew that would take longer than assembling existing tools. We chose it because the chip experience had changed the question. We were no longer asking how to gather enough infrastructure to finish one design. We were asking what infrastructure we wanted WIOWIZ to own and keep developing.
We were not starting from zero
Deciding to build our own engines did not mean opening an empty repository. Simulation, waveform debug, coverage, clock and reset domain analysis, formal and other frontend work had already been developing alongside the chip. Some came from immediate design needs. Some came from engineering interest and experience that predated the tapeout decision. Some matured much later.
What changed after the tapeout was not that we suddenly began writing EDA tools. It was what we intended to do with them. They were no longer only internal infrastructure around our own chip work. We decided to develop them as products that other engineers could eventually use and challenge.
What we are doing now
Our current work is the frontend of the flow: simulation, lint, clock and reset domain checking, formal verification, coverage, low power verification, waveform debug, gate level verification and equivalence checking. These are the parts that can be put in front of engineers and tested today, without waiting on a foundry. A simulator can be run against a design now. A formal result can be compared now. A coverage report can be inspected now. That is why the frontend is where we are putting tools into people's hands first.
What is not ready yet
The physical side is a longer track, and we do not present it as equally mature. Synthesis, floorplanning, placement, clock tree synthesis, routing, timing, extraction, physical verification and signoff depend on the PDK, on foundry rules, and eventually on silicon evidence. That work continues, but it hardens on a different timeline than the frontend, and we say so plainly rather than claim a complete flow we have not yet proven.
The kind of tools we are building
We are not attaching AI to a conventional tool and calling it new. The direction is tools that carry more design context: knowledge of the IP being checked, the history of what has failed before, the relationships between stages, and deterministic evidence that a result can be trusted. That context is what lets automation and agents do useful work instead of guessing. It is also why we build IP and VIP alongside the tools, not as a catalog, but as the engineering knowledge the tools and the automation can use.
Why vertical
The engineering problem does not stop at product boundaries. Design affects verification. Verification affects design decisions. Those affect synthesis, which affects implementation, which creates another verification problem. Tools, IP, verification, software and silicon keep influencing each other. Building them separately means rebuilding the same knowledge in each place. AI makes connecting those layers practical for a small team in a way it was not before, which is the reason a company this size can attempt a vertical approach at all.
Why India first
Government programs such as the Design Linked Incentive scheme improve access to the existing ecosystem, and that access matters. What we are attempting is complementary: to build more of the underlying infrastructure here, rather than only reach the imported version of it. EDA is earned through use and accumulated trust, not announced. So the first serious hardening loop should happen with the engineers, startups, universities and students we are trying to support. If the tools cannot earn trust here, there is no reason to ask the rest of the world for it.
Where we are now
The frontend flow is in beta: simulation, clock and reset domain checking, formal, coverage, low power and lint, with waveform debug and coverage already released. More complex designs are going into regression. Physical design development continues on its longer track. The edge AI chip that started all of this remains part of the longer direction. Short term, we are hardening the frontend by putting it in front of more people and learning from what breaks. Long term, we continue toward the broader RTL to GDSII infrastructure, harden the physical side, return to silicon, and reduce dependence on externally licensed infrastructure where our own becomes good enough to earn it.
We know why we started, what we ran into, what we became, and which parts are not ready. That is the company, stated plainly.