[gluggymug]

Today's beginners don't make the tools.

I must be too old. The new guys can come and bring their new tools. I am retired now.

Back when I started, we used to care how the older engineers did stuff. The academics who trained us at uni had never worked in industry and had no real clue. Hence we had to learn the real stuff from the older guys. These days we are the old guys but just treated like yesterday's newspaper.

[MootWoop]

> Today's beginners don't make the tools.

Not necessarily, I am a beginner in hardware design, and I am creating a new programming language and IDE for hardware design.

> The academics who trained us at uni had never worked in industry and had no real clue. Hence we had to learn the real stuff from the older guys.

I can relate, this is by talking to older designers that my co-founder and myself learned that CDC is a big thing to address for instance. But a lot of times we were just dismissed as too young and inexperienced. Anyway, I'm curious, in your opinion what would be the biggest pain points in digital hardware design today?

[gluggymug]

Verification and synthesis are the pain points. Projects revolve around them not the design. In HW, the design of each module itself is usually pretty conservative. We are a conservative bunch remember! But it's feature creep that crams in more and more modules to handle the variety of ways a single SoC can be applied to multiple markets.

The end result is multiple clock domains and buses going everywhere, multiple RAM modules, lots of different clock gating options to shut down parts of the system not in use. Etc.

When I look at a large design, I don't worry about the design effort. The first thing that comes to mind is the verification effort. You spend about four times or more the amount of effort verifying the design because you cannot afford any mistakes. That effort is building everything around the ports of a design that makes it thoroughly verifiable. The stimulus is constrained randomly generated transactions on every input to the design and checkers of every output. Coverage determines whether the random transactions have covered every case. And it not just every combination of inputs. Every module has state internally: you have to cover every possible state transition.

One of the older guys at my old company joked that: These days the design is done by the verification team.

The behavior of the design is modeled by the verification engineer so they can detect when the design has a bug. Often the verification team is working with an empty stub because they get ahead of the design team. It gets to the extreme case of the verification team telling the design team how to write everything.