5 ms·

I used to work in ASIC design and verification. I have to agree with you. I can't take any of this stuff seriously. They are all toys aimed at newbies. They ad

I used to work in ASIC design and verification. I have to agree with you. I can't take any of this stuff seriously. They are all toys aimed at newbies. They address problems that are no problem at all to a qualified engineer in the profession. Combinatorial logic is not hard. I would argue sequential stuff isn't that hard either. It's all undergrad engineering stuff studied in the first year or two. The design size of a modern ASIC is at a massive scale that makes the problems of whichever description language trivial. Even the cheapest stuff has quite a few modules: memory controllers, CPU, caches, power stuff, bus controllers, various io modules, debugging modules. Nowadays it's multiple cores. Even the sub modules are just wrappers around other cores sometimes. The teams are large, usually in the dozens because the problems are non-trivial. This clash stuff is like building a mailbox. Engineers in the profession are designing and verifying the equivalent of an apartment complex.

FullyFunctional 11y ago
Reduceron, which I try to maintain, is written in York Lava. It has a module for writing sequential logic (called Recipe) and while it makes sequential logic way easier, I have been working on an alternative for a while. I completely agree that the sequential parts of a design is the challenging (= bug prone) part and IMO this is the area where an EDSL like Lava can really shine. If you have worked in ASIC designs that you are almost certainly used to not work with Verilog directly, but with an ad-hoc macro language. I've seen them all, but most commonly Perl is used. It is especially for circuits that we desperately need better tools and abstractions. When designing with Lava you aren't describing a circuit, but a the method to create that circuit. That makes it relatively trivial to completely parametrize it or statically check properties of the circuit. As an example, if done right (Recipe isn't), adding a pipeline stage can be a matter of adding a single line. Compare that to what it takes in say Verilog. This style of ASIC development is simply incomparable to the primitive Verilog-style, but there's not enough experience in the industry to understand it [yet]. Now, Clash isn't (IIUC) an EDSL like Lava so without knowing more about it, I fear it looses much of the point. EDIT: formatting
- gluggymug 11y ago
  Working in industry it IS straight Verilog directly. No macro language in Perl or anything else. Maybe people use emacs to help make stuff neat but that's it. Qualcomm has their own tool that created register files for sub modules from a MSWord table and it sucked big time. Parametrizing is just via `defines. On the verification side, it is System Verilog or something similar. On top of that is a pile of crap called UVM. For an engineer it does not matter about the language that describes the circuit. It does not matter how many lines it takes to add a pipeline stage. The effort is in creating the design itself, not how it is represented in text files. Typical engineers write hundreds of lines every day when they feel like it. Think of the complexity of an SoC in a mobile device. There are millions of lines of Verilog for the design and the same or more lines of System Verilog to do the verification. Typing it in is the easiest part. The real work is simulation of the design under test running millions of cycles. Say we are verifying the wifi, we have to simulate traffic of transactions to and from the device. Millions of transactions while the design is running at various clock speeds with other modules also creating traffic on the buses etc. Waveforms and log files is the majority of the work. These languages from academia don't fix anything I care about.
  - MootWoop 11y ago
    > 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 ;-)
adwn 11y ago
Thank you for this perspective from the top. Sure, when verifying the final ASIC design, the problems of the implementation language don't matter much anymore. However, those IP cores have to be written by someone, and they actually get to suffer the deficiencies of the HDL. > I would argue sequential stuff isn't that hard either. It's all undergrad engineering stuff studied in the first year or two. So? That's like saying that "writing software isn't that hard either. It's all undergrad comp science studied in the first year or two", which is obviously false. If your tools and languages suck, they'll slow you down and you'll produce more bugs – in software as in hardware. I often get the impression, that many hardware engineers don't even realize how much their tools suck, because the lack the perspective on the outside world, specifically the software world, to see better ways of doing things.
- sigterm 11y ago
  I am a pretty junior ASIC engineer who has relatively more exposure to software world compared to many of my peers. In my last project I did some IP integration work and the lack of decent development tools led to significant chores. I did make use of Emacs verilog-mode like GP mentioned and even wrote some small macros in elisp but overall experience is far from satisfactory. Not to even mention the usability of propriety EDA tools and flows. The software world just looks like heaven with so many awesome development tools available (VS, PyCharm, intelliJ, to name a few I've used). And I can tell the difference because I once managed to convert a C# GUI software into a console application mainly with the help of an IDE (Visual Studio), without first learning C#. Sadly, I think ASIC (or maybe broader, hardware) industry has a pretty poor ecosystem in general. I'm not aware of good hardware focused community comparable to HN, no high quality active Q&A on sites like stackoverflow; even the HDL languages look inelegant and not well thought out. And you have a point, I'm not even sure how many of my colleagues realize that. I want to make some difference. But I'm not sure where to start...
  - adwn 11y ago
    > I want to make some difference. But I'm not sure where to start... 1. Take a promising language, improve it where necessary. 2. Add excellent support for translation to VHDL and Verilog. The generated HDL code has to be readable, editable, and it has to reflect the structure of the original code more or less 1:1. You also need to support "inline VHDL/Verilog" (like inline assembly in software). Otherwise, your language doesn't integrate into the ecosystem of synthesis software, simulators, vendor-dependent Map/P&R, and existing IP cores, which makes it useless in the real world. This is the main reason why all innovative VHDL/Verilog replacements have failed so far. Without this feature, there's just no way your language is going to gain any significant market share.

FullyFunctional 11y ago

Reduceron, which I try to maintain, is written in York Lava. It has a module for writing sequential logic (called Recipe) and while it makes sequential logic way easier, I have been working on an alternative for a while. I completely agree that the sequential parts of a design is the challenging (= bug prone) part and IMO this is the area where an EDSL like Lava can really shine. If you have worked in ASIC designs that you are almost certainly used to not work with Verilog directly, but with an ad-hoc macro language. I've seen them all, but most commonly Perl is used. It is especially for circuits that we desperately need better tools and abstractions. When designing with Lava you aren't describing a circuit, but a the method to create that circuit. That makes it relatively trivial to completely parametrize it or statically check properties of the circuit. As an example, if done right (Recipe isn't), adding a pipeline stage can be a matter of adding a single line. Compare that to what it takes in say Verilog. This style of ASIC development is simply incomparable to the primitive Verilog-style, but there's not enough experience in the industry to understand it [yet]. Now, Clash isn't (IIUC) an EDSL like Lava so without knowing more about it, I fear it looses much of the point. EDIT: formatting

gluggymug 11y ago
Working in industry it IS straight Verilog directly. No macro language in Perl or anything else. Maybe people use emacs to help make stuff neat but that's it. Qualcomm has their own tool that created register files for sub modules from a MSWord table and it sucked big time. Parametrizing is just via `defines. On the verification side, it is System Verilog or something similar. On top of that is a pile of crap called UVM. For an engineer it does not matter about the language that describes the circuit. It does not matter how many lines it takes to add a pipeline stage. The effort is in creating the design itself, not how it is represented in text files. Typical engineers write hundreds of lines every day when they feel like it. Think of the complexity of an SoC in a mobile device. There are millions of lines of Verilog for the design and the same or more lines of System Verilog to do the verification. Typing it in is the easiest part. The real work is simulation of the design under test running millions of cycles. Say we are verifying the wifi, we have to simulate traffic of transactions to and from the device. Millions of transactions while the design is running at various clock speeds with other modules also creating traffic on the buses etc. Waveforms and log files is the majority of the work. These languages from academia don't fix anything I care about.
- MootWoop 11y ago
  > 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 ;-)

adwn 11y ago

Thank you for this perspective from the top. Sure, when verifying the final ASIC design, the problems of the implementation language don't matter much anymore. However, those IP cores have to be written by someone, and they actually get to suffer the deficiencies of the HDL. > I would argue sequential stuff isn't that hard either. It's all undergrad engineering stuff studied in the first year or two. So? That's like saying that "writing software isn't that hard either. It's all undergrad comp science studied in the first year or two", which is obviously false. If your tools and languages suck, they'll slow you down and you'll produce more bugs – in software as in hardware. I often get the impression, that many hardware engineers don't even realize how much their tools suck, because the lack the perspective on the outside world, specifically the software world, to see better ways of doing things.

sigterm 11y ago
I am a pretty junior ASIC engineer who has relatively more exposure to software world compared to many of my peers. In my last project I did some IP integration work and the lack of decent development tools led to significant chores. I did make use of Emacs verilog-mode like GP mentioned and even wrote some small macros in elisp but overall experience is far from satisfactory. Not to even mention the usability of propriety EDA tools and flows. The software world just looks like heaven with so many awesome development tools available (VS, PyCharm, intelliJ, to name a few I've used). And I can tell the difference because I once managed to convert a C# GUI software into a console application mainly with the help of an IDE (Visual Studio), without first learning C#. Sadly, I think ASIC (or maybe broader, hardware) industry has a pretty poor ecosystem in general. I'm not aware of good hardware focused community comparable to HN, no high quality active Q&A on sites like stackoverflow; even the HDL languages look inelegant and not well thought out. And you have a point, I'm not even sure how many of my colleagues realize that. I want to make some difference. But I'm not sure where to start...
- adwn 11y ago
  > I want to make some difference. But I'm not sure where to start... 1. Take a promising language, improve it where necessary. 2. Add excellent support for translation to VHDL and Verilog. The generated HDL code has to be readable, editable, and it has to reflect the structure of the original code more or less 1:1. You also need to support "inline VHDL/Verilog" (like inline assembly in software). Otherwise, your language doesn't integrate into the ecosystem of synthesis software, simulators, vendor-dependent Map/P&R, and existing IP cores, which makes it useless in the real world. This is the main reason why all innovative VHDL/Verilog replacements have failed so far. Without this feature, there's just no way your language is going to gain any significant market share.