4 ms·

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 w

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 ;-)
  - pron 11y ago
    > 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.

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 ;-)
- pron 11y ago
  > 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.