Last week at the EETimes Chiplet Conference, I showed the audience Seascape, a fully procedural sea surface computing application.
Seascape doesn't use textures. Each pixel is computed in real time as part of a highly optimized mathematical representation. It renders realistic infinite ocean waves by calculating light and camera rays. It is compute-intensive, requiring modern, mid to high-end GPU availability to render.
More importantly, this incredible application only took 200 lines of Python to create and was built with technology stacks, easily accessible to the subject domain expert. It's a visually stunning example of human ingenuity and a fantastic demonstration of design velocity.
Then came a reveal: The above video I shared was actually running on a piece of custom-designed hardware, not a standard chip, but one built from the ground up specifically for Seascape. Over 80,000 lines of dense math. 2,000-cycle pipelines. 256 parallel physical instances. An engineering problem that would typically take 3 months and several experts to get right.
That's been Cognichip's mission from the outset: months of engineering compressed into a single day. Soon enough – even less.
If you map out a typical mid-complexity chip design effort, it takes 18 to 24 months. This allocation of time tells you everything you need to know about why the industry is stuck.
Architecture gets a fraction of the timeline, and the rest goes to front-end design, verification, and back-end closure. Verification continues to be one of the longest sticks in this taxonomy. The back-end carries most of the risk, because it happens closest to tapeout, when there's no time left to absorb surprises. There's no floor to build from. Every design reconstructs the same integration scaffolding: libraries, interfaces, handoff points between teams – all rebuilt, every time.
The result is that 95% of the time and investment goes to executing tasks. Almost nothing is left for architectural innovation – for iteration, for questioning whether the original approach was right, for improvement.
The structure of how chips get built actively limits the time available for the decisions that matter most.
In software terms, we're writing and validating the equivalent of a modern AI application in assembly, from scratch, every single time.
When the task-heavy phases are compressed, they’re faster, more automated, and more predictable; the engineering envelope shifts dramatically. The time recovered speeds up the current design and entirely changes what’s possible.
The obvious question is: why not just use the AI tools that already exist? Afterall, AI seems to be working well for software engineering.
I've watched this play out. You start with a foundation model built for coding and trained with open-source software samples; fine-tune it with some hardware examples. Very quickly you realize that the model hallucinates heavily due to lack of sufficient training. What to do?
You wrap it with an agent. The agent can run EDA tools and fact-check your model. You get further than before, but an agent only knows what it knows. It’s designed to complete a task, not achieve an outcome. What to do?
You add more agents. Things start working again. The moment the design gets genuinely complex, you start hitting ping-pong effects across agents, tools, and models that are fundamentally not aligned. AI scientists have a name for this effect: “paying models to think.” Instead of the model doing the reasoning, you are, in prompts, in orchestration logic, and in the engineering time you spend guiding it and debugging it.
The deeper issue is physics. Chip design isn't just general reasoning; there are timing, area, power, and fabrication constraints. These aren't things a model trained on software code generation can reliably navigate. The moment a design requires real physical grounding, a general-purpose LLM has nothing to fall back on. What to do?
At Cognichip, we started from a different premise. If you want AI that genuinely understands chip design, you have to build it that way from the ground up.
That means curating datasets that go well beyond what's publicly available because the open-source hardware corpus is thin, and the designs it contains don't cover the dimensions that matter for real production work. It means models that are purpose-built for hardware — RTL, netlist, circuit layout, every abstraction baked in. It means building agentic frameworks where the agents actually understand their domain of expertise and perform task decomposition to the appropriate model.
The benefits compound. Better accuracy, because logic is baked into the model instead of patched in through orchestration. Lower latency, because you're not running multi-trillion-parameter general-purpose models through long reasoning chains. Better cost-efficiency, for the same reason. And better inbound IP leakage protection, because models are trained on governed, curated data.
We recently worked with a tier-one global semiconductor company on an evaluation. They had a 55-page micro-architecture specification, already written. Using ACI, Cognichip's Artificial Chip Intelligence, they ran architectural exploration, completed RTL design from scratch, integrated middleware and components, built SystemVerilog test benches, ran simulations, debugged results, and achieved full functional closure (>90%coverage) with UVM.
That result is what a full-stack, physics-informed approach makes possible when the model actually understands what it's designing. 20 weeks down to 10 days. Full front-end design team down to a single engineer. Not tasks but complete end-to-end outcomes.
The Seascape example is really about one thing: what becomes possible when design velocity is no longer the bottleneck.
One day to build 80,000 lines of custom hardware RTL means the constraint has moved. Hardware innovation at the pace of software innovation, but with groundbreaking speed, cost-efficiency, and accessibility to all. And when the constraint moves, the whole economics of chip design move with it.
That shift is already underway. The teams and companies that build for it now will define what the next generation of chips looks like, and how fast it arrives.
