Cognichip reveals how its new AI-assisted program can slash chip design times from months to days — automating labor-intensive tasks cuts design time down, Chief Product Officer explains

Cognichip reveals how its new AI-assisted program can slash chip design times from months to days — automating labor-intensive tasks cuts design time down, Chief Product Officer explains

We speak to Cognichip's Chief Product Officer, Stelios Diamantidis, about its new AI products

Amid the AI gold rush, one particularly fruitful vein of research is the emergence of AI-assisted workflows in electronic design automation (EDA) tools like Cadence Maestro. One such company developing such foundational models is Cognichip, which in September launched Artificial Chip Intelligence (ACI), proprietary AI models developed specifically for semiconductor engineering. ACI deploys the 'industry’s largest training dataset' across semiconductor physics and chip design principles.

ACI Enterprise is Cognichip's deployable platform, which combines these specialized models with agentic workflows, project memory, and computing infrastructure for AI inference. The company describes ACI's approach as a self-learning flywheel, a continuously evolving design environment that brings together specifications, register-transfer level (RTL), and verification results to build a design that meets power, performance, and area (PPA) targets to Pareto limits. We sat down with Cognichip to learn more.

"We have surpassed, I think, over ten million training samples in our datasets that are either things that we designed ourselves directly or things that have been generated through our synthetic technology," says Stelios Diamantidis, Chief Product Officer at Cognichip, in an interview with Tom's Hardware Premium. "We have invented new ways of creating synthetic training samples for semiconductor design. And very importantly, now that we have all these data samples, characterized data samples, we also had to invent new models so that we can capture the data, and we also had to invent new pipelines for training so that we can map the training data to the models themselves."

A self-learning flywheel

Cognichip says ACI can analyze specifications, explore microarchitectural options, generate RTL, verify designs, identify and fix functional problems, and optimize designs to meet PPA targets. The system can also integrate existing IP modules and even produce FPGA implementations. In principle, ACI enables engineers to focus on product requirements and architectural decisions while ACI handles much of the logic implementation and verification work.

"Build the spec, build the RTL, estimate PPA, perform optimizations, run verification, everything," Diamantidis told us while explaining how ACI can develop and evaluate multiple architectural alternatives before engineers select the preferred design. "We do not try to turn the designer into a verification engine; our system is self-verified, so we want the designer to design, and we want our system not only to do the tasks but also verify them."

Because ACI operates as a self-learning flywheel, Cognichip claims engineers can revisit earlier architectural decisions and modify their designs without restarting the entire development process from scratch.

"Architecture, microarchitecture, RTL, all abstractions in the cognitive system are aligned, so the change in microarchitecture is essentially automatically reflected in RTL, and vice versa," Diamantidis explained. "Changes in RTL are automatically reflected in microarchitecture."

Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.

Cognichip says it has participated in more than 40 customer engagements, including projects at Renesas and SiTime. According to the company, these engagements span a wide range of chip designs, from microcontrollers and encryption engines to networking processors, RISC-V CPUs, and AI accelerators.

To illustrate ACI's capabilities, Cognichip points to an evaluation conducted with an unnamed leading fabless semiconductor company. The customer provided an existing 55-page microarchitecture specification, which ACI used to explore architecture options, develop RTL from scratch, and integrate middleware and other components. The system also generated SystemVerilog testbenches, ran simulations, identified and corrected errors, and achieved functional verification closure with over 90% UVM coverage, the company claims. According to Cognichip, the entire process took just 10 days and required only one engineer. By contrast, doing the same job using conventional methods would require a full front-end design team and approximately 20 weeks, Cognichip says.

However, there are several important caveats. First up, the customer had already provided a detailed 55-page microarchitecture specification, so the platform did not begin with a blank sheet. Secondly, Cognichip has not disclosed the complexity of the design, which makes it difficult to assess how much work has been done (or rather, processed). Finally, the reported acceleration applies to front-end engineering rather than the entire chip development process, which also includes physical implementation, tape-out, manufacturing, and silicon validation.

Making very educated guesses/predictions

There is a substantial difference between developing functionally, conducting verified RTL, and prepping a chip design for manufacturing. Although Cognichip's ACI can develop microarchitectures, generate RTL, and optimize designs for PPA, the platform does not perform physical implementation. Tasks such as floorplanning, placement and routing, clock-tree synthesis, physical verification, and signoff still require conventional electronic design automation (EDA) tools from companies like Cadence, Synopsys, and Siemens EDA.

"Today we do not do physical implementation," Diamantidis said. "So, place and route […] is done outside of our system."

This distinction matters because an architecture that meets its estimated PPA targets may fail to achieve them after physical implementation. For example, a design expected to operate at 1 GHz while consuming 15 W could achieve only 800 MHz at 20 W once engineers account for interconnect delays, clock distribution, buffering requirements, congestion, and other physical effects. Such discrepancies can require changes to RTL or even fundamental architectural elements, followed by another round of verification and physical implementation. In some cases, these iterations can consume weeks or months of engineering time.

"That cycle is very expensive in terms of time," Diamantidis said. "Because you are crossing design boundaries, and you are running very long runtimes and all that."

Cognichip claims that ACI can reduce these costly iterations by predicting the physical consequences of architectural decisions before implementation begins. According to Diamantidis, the company has trained its models on internally developed and characterized semiconductor designs, which enables ACI to estimate PPA characteristics and identify potential architectural trade-offs during front-end development.

"We have trained models with full physical stack visibility understanding so that the models can predict the PPA during the front-end design phase." "We can identify those trade-offs before going to physical implementation."

For example, ACI could recommend replacing two independent FIFOs with a single time-multiplexed FIFO to reduce power consumption at the expense of performance. Diamantidis used this hypothetical scenario to illustrate how the platform can evaluate architectural alternatives before engineers commit to a particular implementation.

"If you want to save power here at the cost of 10% of frequency, take these two FIFOs that you have for two different tasks, merge them, make one FIFO, and then time multiplex the two functions over one FIFO," Diamantidis explained.

Cognichip claims that ACI can estimate not only the immediate PPA consequences of such changes but also their potential impact on physical implementation.

"These trade-offs become visible now because we can tell the designer essentially in real time what some of these impacts are going to be to downstream parasitics and downstream congestion and all those kinds of effects."

The general idea behind ACI is to resolve potential architectural problems before RTL reaches physical design engineers rather than wait for implementation results and revise the architecture afterward.

"Our expectation is that there will be no loopbacks to the designer in terms of 'let us do this again because we did not meet this goal or because we ran into congestion issues,'" said Diamantidis.

However, the accuracy of these predictions is critical. Cognichip claims its models can predict certain PPA characteristics with errors of approximately 10% relative to results obtained from conventional EDA tools at the pre-route stage of physical implementation.

Cognichip evaluated its technology using 1,200 open-source designs and compared its predictions with those produced by general-purpose AI models, including Anthropic's Claude Opus and Google's Gemini. According to him, general-purpose models produced errors of approximately 50% – 100%, depending on the metric, whereas Cognichip's models reduced prediction errors to around 10%.

"[General purpose models] do not do well when it comes to predicting delays," Diamantidis said. "So, we take that down to within 10%. Again, 10% because think about it, we are running it at RTL. We do not have much physical information at all, right?"

There is an important distinction, though. Cognichip's reported accuracy refers to pre-route physical implementation results, not final post-route characteristics. Actual routing introduces interconnect and power delivery parasitics as well as other physical effects that can alter timing and power consumption. Consequently, the reported 10% prediction error does not necessarily mean that ACI-generated designs will achieve their estimated PPA targets after physical implementation and signoff.

Another question concerns the range of architectures and manufacturing technologies for which ACI can deliver such accuracy. Although Cognichip says its models incorporate semiconductor physics and account for process-dependent characteristics, it has not disclosed which foundry nodes it supports or how prediction accuracy varies across them.

Diamantidis explained that some architectural decisions are largely independent of manufacturing technology, whereas others become increasingly dependent on the target process node as development progresses.

"[Think about chip development as a tree], at the top of the tree, there are decisions that are not really foundry-specific; they are closer to microarchitecture," he explained. "Then, of course, as you start working your way down the tree, at some point you branch off because the decision may be targeted towards the TSMC node A versus TSMC node B, which will result in different prediction things. But there is a big trunk of decisions that are not really related to the node and are more related to the architecture and the way that the architecture is implemented. What we try to do is we try to think of this whole tree and provide a lot of feedback to designers, especially in a node-agnostic mode, and then, of course, at some point we have to become more node-aware."

This distinction is exceedingly important for complex CPUs, GPUs, and AI accelerators, where physical constraints tend to have substantial impact on architectural decisions. Meanwhile, Cognichip does not claim that ACI must develop such processors as monolithic designs. Instead, the company says its technology can work with individual IP blocks and subsystems, which engineers can subsequently integrate into larger chips. Of course, integration of these individually optimized IP blocks into larger chips is a challenge.

Big chip? Not a problem, but there is a caveat

Although Cognichip says ACI can handle subsystems containing millions of logic gates (i.e., circuits that implement Boolean functions), combining multiple such designs into a complex SoC introduces additional constraints related to interconnect delays, clock distribution, shared memory bandwidth, power delivery, and floorplanning. Consequently, an architecture that achieves Pareto-optimal PPA characteristics as a standalone subsystem may no longer be optimal once integrated into a larger chip. According to Cognichip, ACI can account for these system-level interactions by aligning and optimizing individual blocks against global SoC and subsystem constraints.

“Yes, ACI can align and optimize individual blocks to global SoC and subsystem constraints. It can be applied to both flat and hierarchical optimization problems,” Diamanditis said.

Cognichip is not proposing a fundamentally new SoC development methodology, but rather automating substantial portions of conventional front-end workflows. Its ACI platform supports both flat and hierarchical optimization and can drive the partitioning and propagation of design constraints from the top level to individual blocks. According to Cognichip, ACI can decompose system-level constraints into requirements for individual components and then re-aggregate them as the blocks are integrated.

“ACI does not require a flat design methodology; it can drive hierarchical design from the top or subsystem-top down, ensuring that constraints are decomposed going into components but then re-aggregated when blocks are integrated,” Diamanditis explained.

According to Cognichip, ACI can handle individual IP blocks and subsystems containing millions of logic gates, which can subsequently be combined hierarchically into larger SoCs. The company emphasizes that the complexity of individual partitions, rather than their size, determines how effectively ACI can handle them. However, it remains to be seen how effectively ACI can coordinate architectural decisions and optimize PPA across an entire complex SoC in practice. After all, a Pareto-optimal CPU core, memory controller, and interconnect do not necessarily form a Pareto-optimal SoC, as their interactions introduce additional timing, bandwidth, power, and physical constraints.

Then again, developers of complex SoCs already address these challenges with hierarchical design methodologies, system-level optimization, and integration, so ACI’s focus on individual subsystems does not necessarily represent a significant limitation.

Feedback loops? No need for them!

One of the questions that normally occurs when we talk about a tool that is only aimed at the front end of chip development is how it can handle feedback loops from physical implementation (more on this later). Such feedback loops occur when placement and routing reveal problems with timing, power consumption, die area, or routing congestion that cannot be resolved through physical design optimizations alone. In more serious cases, engineers must revise RTL, pipelines, memory hierarchies, or other architectural elements, which requires another round of functional verification, synthesis, and physical implementation. These iterations can take plenty of time and involve multiple engineering teams, which makes them particularly expensive.

Cognichip says ACI can use physical implementation results to revise RTL and microarchitecture if necessary, although this is not the company's primary focus. Instead, it aims to prevent costly iterations between front-end and back-end design teams by predicting potential problems before physical implementation begins.

"We are still focused very much on what we can do in the front end to prevent these situations rather than fix them."

If physical implementation reveals problems that require changes to RTL or microarchitecture, engineers can return to ACI with the relevant feedback (Cognichip does not specify with which file format that feedback must be submitted) and use the platform to revise their designs. Yet, ACI cannot resolve issues that require changes to the physical implementation itself, such as clock-tree synthesis or placement and routing.

"They can come back to our environments to provide additional guidance, additional prompting, additional information," Diamantidis said. "Then based on that information, we can of course perform an adaptation of the design […] if the issue can be addressed in the design itself, then of course we can do that."

Since feedback loops are expensive, yet necessary parts of semiconductor chip development flow, I had to ask that question explicitly, and the answer was that there would be no need for feedback loops with ACI. As the question and response require a lot of minutiae, we've added them in full below.

Anton Shilov: Can ACI ingest physical implementation reports from Cadence, Synopsys, or Siemens EDA tools, identify architectural bottlenecks, revise the microarchitecture, and RTL, and repeat the process until the design meets its PPA targets?

Stelios Diamantidis: Actually, this is where we depart from conventional approaches. We do not need to wait until physical implementation to identify these issues. We have trained models with full physical-stack visibility, which enables them to predict PPA during the front-end design phase.

For example, suppose you have one design that operates at a certain frequency and consumes a certain amount of power, and another that runs perhaps 20% slower but consumes significantly less power. We can identify these trade-offs before physical implementation.

Ultimately, the changes you want to make involve RTL and design constraints. Traditionally, engineers develop the RTL and constraints and hand them over to the physical implementation team. That team implements the design and reports the results. If the design fails to meet its targets, the front-end team must make changes, and the process starts again.

These iterations are very expensive in terms of time because they cross design boundaries and involve tools with long runtimes.

By training our models on the full physical stack, we can now provide immediate feedback to front-end designers. For example, we might tell an engineer: 'If you want to reduce power consumption at the cost of 10% of your frequency, take two FIFOs that serve different functions, combine them into one, and time-multiplex the two functions over that FIFO.'

That is just one example of a microarchitectural decision. We can make these trade-offs visible to designers in essentially real time because our models can predict their impact on downstream parasitics, routing congestion, and other physical characteristics.

As a result, engineers can make these decisions in a closed loop during front-end development. Once they have resolved the microarchitectural trade-offs and produced well-structured RTL, they can hand the design over to the physical implementation team. Of course, the design still has to go through physical implementation tools.

Our expectation is that there will be no need to return the design to the front-end team because it failed to meet its targets or encountered congestion problems. That is the fundamental change we aim to bring to the transition between front-end and back-end chip development.

Third Party IP? No problem

Modern SoCs typically combine proprietary logic with third-party IP, including processor cores, memory controllers, interface IP, and other reusable components. However, developers do not necessarily have access to the RTL of licensed IP blocks, and licensing agreements may restrict how such information can be used. This raises the question of how ACI can integrate third-party IP without access to its internal implementation.

According to Cognichip, this is not a problem. ACI does not need to examine proprietary RTL to integrate an existing IP block into a larger design. Such IPs provide relevant interface specifications, including pin connections, signals, and their characteristics. ACI can then proceed with necessary integration logic and connect the IP to other subsystems.

"Most people want to take […] third-party licensed IP and optimize the integration of the IP," claims Diamantidis. "We ourselves do not ingest the guts of the IPs, nor do we try to train on any kind of data related to the IPs."

The CPO of Cognichip stressed that ACI Enterprise protects customers' IP within the company's firewalled data centers and prevents it from entering third-party AI training pipelines. The platform provides customer-controlled access to sensitive information, multi-tenant isolation, and security controls validated through a SOC 2 Type II examination. However, these protections do not supersede the licensing restrictions imposed by third-party IP providers.

A new offering

Cognichip's ACI technology could substantially improve chip development productivity by automating labor-intensive tasks such as architectural exploration, RTL development, verification, and PPA optimization.

The company's benchmark with a major chip designer suggests that the potential gains could be considerable, although the complexity of the project remains undisclosed. Such capabilities could be particularly valuable for startups and newcomers to the semiconductor industry, which tend to lack engineering resources and extensive IP portfolios of established chipmakers. By reducing the time, costs, and expertise required to develop custom silicon, ACI could lower the barriers to entry and enable smaller companies to pursue a custom silicon strategy that would otherwise be prohibitively expensive.

However, Cognichip has yet to demonstrate autonomous development of a complete, physically validated chip, let alone a sophisticated CPU or GPU. The company does not perform physical implementation, and its expectations of eliminating costly feedback loops depend on the accuracy of its PPA predictions. It also remains to be seen how effectively ACI can optimize complex SoCs that combine numerous proprietary and third-party IP blocks under common power, performance, and area constraints.

Ultimately, the Cognichip technology's value for leading-edge chip developers will depend not only on how quickly it can produce verified RTL, but also on how closely its predictions match the results of physical implementation and how much engineering work it can eliminate across the entire development cycle.

Anton Shilov is a contributing writer at Tom’s Hardware. Over the past couple of decades, he has covered everything from CPUs and GPUs to supercomputers and from modern process technologies and latest fab tools to high-tech industry trends.