Hacker News new | ask | show | jobs
by tverbeure 30 days ago
Human nature?

In the early nineties, it was common for experienced electrical engineers to keep on using schematic entry digital design and look down on RTL and synthesis tools, despite that fact the latter was already way more productive. At some point, management had to put their foot down and force everyone to switch to using synthesis.

It's not unreasonable to assume that many people are set in their ways and unwilling to change their behavior without a bit of a push.

4 comments

It is completely unreasonable to assume that. Tech people are so hungry for productivity gains that they regularly will defy management forbidding them from using a tool, because the tool is so good they feel they have to have it.

If LLMs truly are as good as their proponents say, engineers will use them even if management outright forbade it. The fact that people aren't using them, and have to be forced, is extremely strong evidence that they are not in fact that useful.

> extremely strong evidence that they are not in fact that useful.

Surely you can't argue in good faith today that LLMs aren't useful? It was a valid argument a year ago, but the latest models are absolutely useful at solving whole classes of problems.

They're not perfect, need to be carefully monitored, can cause weird gambling like dopamine rushes and can cause lazy development habits to creep in. But none of those things negate the fact that, in many situations, they are useful.

Useful = net benefit.

Short-term, sure in some contexts. Long-term? Nobody knows yet.

You can't just redefine useful to mean something it doesn't.

Useful = able to be used for practical purposes.

As an extreme example, most effective weapons are useful to the person using them, but aren't necessarily a net benefit.

Is AI going to make life meaningfully better for most people? That's uncertain. Is it useful for the tasks in front of me today? Yes, definitely.

> extremely strong evidence that they are not in fact that useful

See my other reply in this subthread. For my line of work, they are in fact ridiculously useful.

Alpha 21064, 1992, was using domino logic [1].

[1] https://en.wikipedia.org/wiki/Domino_logic

There was no synthesis algorithms that would map VHDL or Verilog designs into domino logic elements at the time. I believe that the most work in the synthesis-to-domino-logic area was done at the beginning of current century.

So, DEC's engineers and, I think, Intel's engineers were doing work using schematics well into 21-st century.

In the early nineties, standard cell design was already used by everyone except those who needed clock speed at all cost.
I guess the only difference between this and your example is the concrete efficiency gain from RTL and synthesis tools versus dubious applications of AI. I do agree with the second point about pushing people to explore new ways of doing things though.
> dubious applications of AI

Leaving aside the ethical aspects of using AI (not because they're not valid, because they're off topic for this discussion), in my line of work, the capabilities and productivity improvement of AI are staggering. Most of it is not writing the new code, which is but a small part of chip design, but everything else.

I can't give a concrete work example, but here is an experiment that I ran a month ago. https://tomverbeure.github.io/2026/04/12/AMIQ-License-Key-Ge.... If it can do that, it's not hard to imaging similar use cases related to root causing complex simulation failures. It is frighteningly good at that.

> use cases related to root causing complex simulation failures.

That's a pretty interesting use case. I assume this is for RTL simulation given the thread, but how do you connect the output of the simulator to the AI?

For a small case, a colleague took a screenshot of waves in the waveform viewer and pasted it into the AI tool. It worked.

But for large cases, use tools to extract all interfaces from the waveform file and save it as a text file, or add $display statements in the Verilog itself to dump the transactions. A SOTA LLM will eat it up. You point it to the RTL, a log file with hundreds of thousands of lines, and give it a few lines to explain how it is supposed to behave. Just tell it "My simulation is hanging. Figure why." Wait 15 minutes and it will tell you why it hangs and which line to change in your code to fix it.

I've done the experiment after the fact: I had spent ~3 days to fix complicated 3 bugs. I then rolled back the code and told it "Here is the spec. Find all the bugs in this code". It found all 3 bugs in around 30 min. That's when I realized that things won't be the same anymore. (And don't get me wrong: I love debugging simulations.)

This is why I asked:

>And why not take the alternative approach of identifying the subset of people who have indeed found solid uses and spread their best practices around?

A bottom-up approach has a far better chance of finding those particularly good use cases, and if you lean on the people how found those fits, they're more persuasive than top-down edicts. They actually know what they're talking about. If the point is to leverage AI for better work outcomes, someone with your experience is far more valuable than "here's a dashboard, make the number go up," which seems to be what's going on at Amazon.

How do you know up front who will find the best use cases? Both approaches can work.
Have you tried to change your HDL to something more modern like Bluespec System Verilog or, god forbid, anything embedded into Haskell or Scala?

I read that BSV source code is about three times shorter than similar design in Verilog and also has three times smaller defect density (defects per significant line of code). So just by changing the HDL from Verilog to BSV one can have nine (9) times less defects in the design.

BSV won't help for cases you didn't think about a corner case. (I use SpinalHDL/Scala for all my hobby projects, BTW, and yes, I tend to make less mistakes.)
SOTA = State of the Art? Like say Claude Opus 4.5? I actually want to try this out.
I think I used Opus 4.6 1M.
Fair points! Thanks for sharing the write-up as well - great read.
> It's not unreasonable to assume that many people are set in their ways and unwilling to change their behavior without a bit of a push.

You include those only in second round along with guidelines and recommendations on how to use it effectively.

What if those people are some of the most experienced ones, who can see use cases, and flaws, that more junior people won't?
People who have to be forced to try it are unsuitable for the exploratory "find what it is useful for" task regardless of seniority.

Also, we are talking about large companies here. There will be plenty of more suitable seniors.