[MootWoop]

> For an engineer it does not matter about the language that describes the circuit. [...] Typing it in is the easiest part.

Well... once upon a time, people were writing software with assembly, and they probably didn't care about the number of lines either. After all, typing was easy, in fact the only problem was just porting your program to a different architecture :-)

You talk about the complexity of a SoC, and you are right it is complex. But software is complex, too: an application relies on hundreds of millions of lines of code, counting everything between the hardware and the application (OS, network stack, HTTP server, all libraries, database, etc). So how do software engineers manage all that? They use better languages than assembly. Because what matters is the performance/expressiveness ratio (which is why C is still relatively popular) and how hard it is to shoot yourself in the foot (which is why C is not as popular as it once was :D).

> They are all toys aimed at newbies. They address problems that are no problem at all to a qualified engineer in the profession.

I think this kind of attitude is one of the main problems of the hardware design industry (the other one is the conservative mindset). Today's beginners could be tomorrow's hardware designers, instead they switch to software because the culture is much more open and friendly. Besides, you know what they say about asking users what they want: if Henry Ford has asked his customers what they wanted, they'd have asked for a faster horse ;-)

[pron]

> So how do software engineers manage all that? They use better languages than assembly.

Well, better languages than assembly, yes, but the situation is not so simple. In the past 40 years or so in the software industry, there were two, and exactly two, language-related major productivity leaps in the production of "serious" software: C and Java. Java didn't add too much in expressivity over C (in fact, it added less than C++ had), and neither did C add a lot of expressivity over assembly (more convenient syntax but not too many new abstractions) -- but both added a lot in terms of safety, modularity, portability and the like.

The problem is that we haven't been able to make yet another significant jump. Much of current PL research focuses on expressivity and proof of correctness -- two things that aren't the really painful problems for the software industry these days, and aren't what made C and Java such productivity boosters, either. In both cases, productivity was enhanced not through some clever language syntax design, but through the ecosystem the language supported (i.e. extra-linguistic features).

Yes, some other languages like Ruby added some productivity benefits, but mostly in the "toy" application department -- the same kind of applications people used to use MS Access or VB for, or other "application generators" prior to those -- and you see Ruby shops transitioning to Java as they become "serious". The thing is that with modern hardware, even toy software projects are quite usable, but this isn't the case with hardware design.

[MootWoop]

Good point about the reasons of productivity leaps. Funnily enough, I recall that one of the main selling points of Java was portability (the famous "Write Once Run Everywhere"), even though C was already supposed to be portable; but the environment wasn't, and you still had to develop OS-specific code.

Anyway, yes I agree the ecosystem is key. This is why a lot of new languages are either running on the JVM (like Clojure and Scala) or are interoperable with C (like Rust and Nim). In other cases, languages have managed to create an entire ecosystem very rapidly (Node.js and Javascript in general, Ruby and others).

> The thing is that with modern hardware, even toy software projects are quite usable

You're right. I must admit I'm not a big fan of this "throw more at the problem" approach, and I wonder for how long this approach will work. After all, Moore's law is slowing down, as the unit cost per transistor has stopped decreasing after 28nm.

> but this isn't the case with hardware design.

Yes, for one because if you design hardware that is sub-optimal, in other words that requires more transistors, that translates into higher costs, and lower margins. That's some powerful incentive IMO. Not to mention that if the hardware is not powerful enough, the toy software projects that you mention will have trouble running ^^

Therefore I think a central question is the loss of performance compared to the gain in productivity. A naive translation of C to assembly leads to disastrous performance. For years (decades?) people had to resort to assembly for speed-critical routines, and you can still find assembly in video decoders for instance. But the productivity is so much higher than the loss of performance is acceptable.

[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.

[MootWoop]

To whomever downvoted this: would you mind telling me why? Have I offended you in some way? Is it because of the criticism of the hardware industry? Or the sarcasm?