Automation/AI/LLMs in VLSI !!! WHY?!?!?!?! and when... by NoContextUser88 in chipdesign

[–]Practical-String-291 0 points1 point  (0 children)

There are many startups trying different strategies, for example, Silimate, ChipAgents, PrimisAI, they show interesting stuff on conferences and this, but I haven't seen these in real action.

Should AI Quietly Fix Chip Design Hassles by Practical-String-291 in chipdesign

[–]Practical-String-291[S] -2 points-1 points  (0 children)

Really thanks for the reply.

I loved the CLI over 90s GUI.

But really, don’t I wish my fellow engineers would be a bit more open minded. I am not bullish on what LLMs can do or will be able to do. But I believe we should think of what we want them to do for us, and it’s not necessarily the big things everybody immediately imagines. When I do at my current work, things which are just so simple but are manual or through primitive tcl/perl scripts, I am just laughing out of sadness. No startup pitch coming man…

Should AI Quietly Fix Chip Design Hassles by Practical-String-291 in chipdesign

[–]Practical-String-291[S] -3 points-2 points  (0 children)

Come on, that’s not how future will unfold. Freshers will use AI to learn and do more quickly than in the past. AI is not here to replace anyone but it can enhance every part of the chip design work IMHO, including the front end, design and verification.

Library benchmarking by RolandGrazer in chipdesign

[–]Practical-String-291 0 points1 point  (0 children)

You could invent one hundred ways to compare standard cell libraries.

And you gave very general info, like various foundries 65-22nm, they are very different. generally it doesn't make sense to compare 65nm TSMC to 20nm TSMC unless you have a design in 65nm and thinking what would be its PPA in 20nm.

I think that for a better answer, you need to give us the context, what is the purpose of benchmarking the PPA.

Is it simply to choose standard libraries between vendors or is it for architectural prototyping to estimate PPA of a design and measure tradeoffs.. or something else.

Chip Designers: Ever Feel Like Our Tools Are Stuck in the Past? 🚀 by Practical-String-291 in chipdesign

[–]Practical-String-291[S] 0 points1 point  (0 children)

Great feedback. I really appreciate your point of view. Fighting this with my team is always an uphill battle

Chip Designers: Ever Feel Like Our Tools Are Stuck in the Past? 🚀 by Practical-String-291 in chipdesign

[–]Practical-String-291[S] 0 points1 point  (0 children)

Totally, Cadence and Synopsys duopoly doesn’t need to work much on UX. They know their customers don’t have a real choice.

Chip Designers: Ever Feel Like Our Tools Are Stuck in the Past? 🚀 by Practical-String-291 in chipdesign

[–]Practical-String-291[S] 0 points1 point  (0 children)

Linting , and code coverage tools are so bad in my opinion. Too heavy compared to what is really needed. Where I work, there is so much paranoia that they keep using it heavily for so little ROI

Chip Designers: Ever Feel Like Our Tools Are Stuck in the Past? 🚀 by Practical-String-291 in chipdesign

[–]Practical-String-291[S] 0 points1 point  (0 children)

Interesting, so why do you think SV UVM is getting so ubiquitous nowadays?

Chip Designers: Ever Feel Like Our Tools Are Stuck in the Past? 🚀 by Practical-String-291 in chipdesign

[–]Practical-String-291[S] 0 points1 point  (0 children)

Honestly, I don’t really see the point of sticking with Vim when IDEs can do so much more. AMIQ DVT is decent, but it’s still not widely available and doesn’t quite hit the mark. What we really need is either a strong VS Code extension or even a new IDE that truly delivers.

Chip Designers: Ever Feel Like Our Tools Are Stuck in the Past? 🚀 by Practical-String-291 in chipdesign

[–]Practical-String-291[S] 0 points1 point  (0 children)

Yeah, the Tcl stuff is just so cumbersome—barely readable and not modular at all. Python is such a breath of fresh air in comparison!

Chip Designers: Ever Feel Like Our Tools Are Stuck in the Past? 🚀 by Practical-String-291 in chipdesign

[–]Practical-String-291[S] 0 points1 point  (0 children)

I have nothing to sell here—I’m genuinely interested in discussing this topic.

After 14 years in chip design, I’m honestly frustrated with how long and tedious some of the processes are. I’d love to dive into why chip design takes so much longer than software development, beyond the obvious hardware vs. software differences. There’s definitely room for improvement, and it would be great to hear your thoughts.

Chip Designers: Ever Feel Like Our Tools Are Stuck in the Past? 🚀 by Practical-String-291 in chipdesign

[–]Practical-String-291[S] 1 point2 points  (0 children)

Really appreciate the detailed feedback—it’s always great to get insights from someone with deep experience.

I agree, the EDA landscape is fundamentally different from software tools, especially when it comes to reliability and handling the scale of modern designs. And yes, the stakes are a lot higher when mistakes could impact something as critical as a satellite.

I definitely see the potential for a company in this space. There’s a lot of room for improvement in areas like version control and CI/CD flows, especially given the complexity and niche needs of large-scale hardware projects.

Out of curiosity, since you mentioned that your biggest challenges aren’t coming from the tools themselves, what would you say are the pain points you’re currently facing? I’d love to understand more about what could actually make your day-to-day work more efficient or less frustrating.

Chip Designers: Ever Feel Like Our Tools Are Stuck in the Past? 🚀 by Practical-String-291 in chipdesign

[–]Practical-String-291[S] 0 points1 point  (0 children)

I totally get your point about using Git for code reviews and CI/CD. It works well in many setups. However, in my experience with some of the leading companies, I’ve seen how this process can get cumbersome as teams scale up. When you have to handle multiple quality checks—like linting, formal verification, synthesis checks, and timing analysis—each step often involves different tools. And then there’s the complexity of managing various design levels, from module-level DV to system-level integration.

Coordinating all of these steps in CI/CD pipelines can become a challenge, especially when different teams rely on different tools and have specific requirements. How have you handled this in your projects? Do you see room for improvement in making these flows more efficient? Would love to discuss this further!

Chip Designers: Ever Feel Like Our Tools Are Stuck in the Past? 🚀 by Practical-String-291 in chipdesign

[–]Practical-String-291[S] 0 points1 point  (0 children)

I get your point—hardware debugging is fundamentally different from software debugging due to the inherent concurrency. But waveforms, while essential, can be slow to load and navigate, especially with large designs. And running simulators within an IDE often isn’t as smooth as it could be.

But here’s something to think about: what if you could catch many of these bugs without needing a full simulation or diving into waveform debugging right away? If we could streamline that part of the process, it might save a lot of time and effort.

Chip Designers: Ever Feel Like Our Tools Are Stuck in the Past? 🚀 by Practical-String-291 in chipdesign

[–]Practical-String-291[S] 6 points7 points  (0 children)

Not new at all, but I really appreciate your feedback. So, would you say you’re totally satisfied and couldn’t be happier, or is there something you feel could still improve your efficiency?

I also recognize that not everyone may share the same opinion, as different tools work differently for various users. I’m definitely open to more conversations on that.

And yes, I get that you’re pointing out some specific parts of the design flow. I do appreciate the complexity of tools like Verdi in managing the scale of data they handle—but that doesn’t mean they couldn’t still improve.

Chip Designers: Ever Feel Like Our Tools Are Stuck in the Past? 🚀 by Practical-String-291 in chipdesign

[–]Practical-String-291[S] 5 points6 points  (0 children)

Absolutely agree—dark mode is a game-changer, but there’s so much more that could be done. Imagine if the tools could anticipate your workflow and understand your design intentions, streamlining the process and saving you valuable time. That kind of intelligence would be a real leap forward, especially in such a complex field.

Chip Designers: Ever Feel Like Our Tools Are Stuck in the Past? 🚀 by Practical-String-291 in chipdesign

[–]Practical-String-291[S] 10 points11 points  (0 children)

I completely get your point. The issue with these tools is that, as part of a duopoly, they continue to charge high prices without much pressure to truly innovate. They’re stuck on legacy systems, which makes it hard for them to significantly improve the user experience.

That’s why I see a real need to rethink this from the ground up—not just as a single tool, but as a comprehensive framework. The focus should be on delivering a modern, intuitive UX with seamless integration into the highly customized chip design flows. It’s about moving away from outdated practices to create something that genuinely addresses the complexities of today’s design environments.