Virtual Meetup - Hardware Description Languages (HDL) as Domain Specific Languages

Events
1

Hi Community,

I am happy to announce that this Thursday (the 10th of June), Luca De Santis will hold a discussion about the Hardware Description Languages (HDL) as Domain Specific Languages.

Also, remember that in December, we changed the link to join the Meetup!

HDLs are used in the semiconductor industry to describe the structure and behaviour of digital systems, with the aim of stimulating and synthesizing complex hardware architectures.

There is a renewed interest today in HDLs due to the new challenges that hardware designers are facing: exponential increasing complexity, critical metrics balance, massive heterogeneous parallelism, emerging of non-Von-Neumann architectures and so on.

In this talk, we are going to present the state of the art of HDLs with a particular emphasis on language engineering topics, like syntax features needed to represent hardware and semantics associated with digital hardware simulation.

Luca De Santis has more than twenty years of experience in the semiconductor industry. He has been leading the logic design of sixteen successful memory projects with Micron. His main experience is in the development of embedded processors for non-volatile memories and he is the author of the language/compiler that is still used today to program control software inside Micron’s NAND memory devices.

Other than dealing with customized compilers for resource-constrained processors, his interest in DSLs includes the search for a new approach to hardware abstraction, to address the problem of increasing complexity of digital systems. He is graduated in Electronic Engineering at the University of L’Aquila, where he is a Lecturer in a course on “Integrated Electronic Systems Design”.

And if you are thinking of proposing a talk, it is time to come forward. Just let me know by replying to this message.

How to connect

To avoid other security issues is now necessary to register for the meeting. The registration should be necessary just once and be valid for all the next meetings you will participate in. I understand it is a little extra effort, but it would avoid problems like the ones we encountered:

Registration for the Virtual Meetup

After registering, you will receive a confirmation email containing information about joining the meeting. It will also permit you to add it to your calendar.

Time

It is hosted on Zoom at 6 PM GMT+1/CEST (you can use this link to figure out which time is in your timezone: The Time Zone Converter).

Cheers,
Elisa

P.S. We get a recurring question: “Are presentations recorded?”. The answer is not, and the reasons are explained here On recording Virtual Meetups - #7 by voelter

2

The article I mentioned in the meetup:

A graph placement methodology for fast chip design

https://www.nature.com/articles/s41586-021-03544-w

Abstract

Chip floorplanning is the engineering task of designing the physical layout of a computer chip. Despite five decades of research1, chip floorplanning has defied automation, requiring months of intense effort by physical design engineers to produce manufacturable layouts. Here we present a deep reinforcement learning approach to chip floorplanning. In under six hours, our method automatically generates chip floorplans that are superior or comparable to those produced by humans in all key metrics, including power consumption, performance and chip area. To achieve this, we pose chip floorplanning as a reinforcement learning problem, and develop an edge-based graph convolutional neural network architecture capable of learning rich and transferable representations of the chip. As a result, our method utilizes past experience to become better and faster at solving new instances of the problem, allowing chip design to be performed by artificial agents with more experience than any human designer. Our method was used to design the next generation of Google’s artificial intelligence (AI) accelerators, and has the potential to save thousands of hours of human effort for each new generation. Finally, we believe that more powerful AI-designed hardware will fuel advances in AI, creating a symbiotic relationship between the two fields.

2 Likes
3

Very interesting, thank you for sharing.

4

That’s very cool. While not a specialist by any means, I worked for awhile in the Embedded Design Tools area and appreciate the kind of impact this kind of technology could have.

1 Like
5

I really enjoyed and appreciated Luca’s HDL talk last night. It’s a big topic! Thanks Luca and Federico and others for organising it. It’s only my second virtual session, the first being the talk about Lisp which I enjoyed as well.

There’s a lot that could be followed up on from Luca’s talk. For example:

  • Luca mentioned several levels of abstraction from physical circuit design up to gate level, register transfer level (RTL), high level synthesis (HLS), to name a few. I suppose it’s reasonable to say that the bulk of the talk was about Verilog and RTL, interfacing issues, shortcomings of Verilog, and a possibly way ahead with alternative languages such as the one Luca is prototyping. The HLS level was mentioned but there’s a whole topic there. I’ve been learning about HLS in recent months and how to apply it in certain contexts. The HLS I have in mind involves C/C++ with #pragmas applied (via particular tools from Xilinx, Intel, …) to ultimately synthesise a circuit. One thing Luca did say is that HLS tends to be applied to DSP type applications. I’m wondering about that limitation though. It would be good to talk more about that and Luca’s language.

  • One reason that software engineers may care about HLS is because of the possibility of starting with C/C++ and optimising functions as hardware (vs parallelism approaches such as OpenMP) on a FPGA (field programmable gate array) without writing Verilog or VHDL code. This doesn’t mean you don’t need to understand anything about what’s happening at the hardware level. Another whole topic.

  • As with software, design and coding is just one aspect of the work. Testing (verification) is another. My understanding is that circuit/chip design has historically placed a huge emphasis upon verification on HDL based designs (including some attempts at formal verification), e.g. with Verilog test benches (which Luca mentioned). Similar C/C++ test benches exist as part of the HLS design flow. My question to Luca is: to what extent can language improvements help with verification of hardware designs as well as the designs themselves?

  • Luca mentioned that Verilog does not allow clock domains to be specified, allowing different parts of a circuit to run at different clock speeds. While not something I know much about, I notice that at least in some HLS frameworks, there are #pragmas that allow clock domains to be specified.

I’d appreciate comments from Luca and others on these kinds of topics.

Thanks.

David

1 Like
6

Hi Community,

if interested you can find the slides here:

HDLs as DSLs.pdf (1.3 MB)

Cheers,
Elisa

7

Hi David,
thanks for triggering the discussion.
Let me try to give an answer.

  1. FPGA is an overkilling, meaning that when you buy an FPGA device, you expect to buy a piece of working silicon. Vendor guarantees for that, he solved 99% of physical issues. You only have to configure the device according to an RTL design by a synthesis flow that the vendor gives you for free.
    The counterpart is that you use only a part of Silicon you bought at a very high price in euro/mm2. Try to stress FPGA device to its limits and you’ll get what I’m trying to say. FPGA methodology is justified by the price of final application.
    ASIC world is a different story; when you have to do “physical design”, you have to deal
    with process uncertainty, temperature, observability, glitches, metastability… here the quality of RTL/Physical design is a big deal.

  2. HLS for a long time has been successfully applied on mathematical/DSP applications. The emerging of customized processors with accelerators (in the AI/ML arena) triggered a new interest in the tool also because of the availability on the market of standard libraries for common problems, mainly I/O interfaces and complex algorithms.
    The problem of HLS is that despite the name, it is based on a very specific algorithm : resource binding plus task scheduling in the optimal way on a data-flow description. Not all digital systems fit in this scheme.

  3. On the verification side, language designers can do a lot. For instance in the direction of formal correctness, correct-by-design style.
    There has been a lot of effort (i.e. System Verilog, UVM) in the direction of randomized verification, assertion based verification, code coverage and so on, but a lot of work has still to be done on the direction of formal correctness. I’m strongly convinced that the road is working on the semantics of digital objects. Avoid wiring by abstraction or assigning “strong type” to wires so that the designer only has the freedom of doing correct things :slightly_smiling_face:.
    On this side there is a lot of room for language engineering, for instance applying the concept of projectional editing.

  4. The problem of clocks in Verilog is not the existence of multiple clocks but the possibility for a designer to do anything he wants with that. Clock in digital systems MUST BE a special wire, like reset and other “wires with a semantics”.
    As I said in the talk, this problem is similar to programming in assembler on complex data structures. Any time you get a byte, you don’t know what it is: higher level programming languages solved the problems by introducing “types”; similar evolution should be triggered on HDLs. Today, designers using Verilog or VHDL, are used to declare the type of wires in their name, by prefixes or suffixes, to minimize errors. Obviously the compiler doesn’t know.

Thanks
Luca

1 Like
8

Hi Luca

Thanks for your reply.

Interesting comments about FPGA. I suppose I was thinking here at least in part about one concrete way in which software engineers and language designers can gain some tangible experience with HDLs and what synthesis targets. One way to do that is via FPGAs because either a HDL like Verilog or HLS with C/C++ can be used. As soon as one gets to thinking about optimising a design even with HLS, a tool’s reports will provide details of number of LUTs, flip-flops, DSP block etc used and the generated Verilog/VHDL can be viewed if desired.

I’m thinking this can help one understand what it means to unroll a loop to a set of finite hardware resources.

As you said in your talk, there is a gap to be bridged both from the software engineer to understand the hardware level and the hardware engineer to appreciate more about the software and PL side of things.

I take your point of course that particular types of applications tend to be better suited for FPGAs. Then again, we see so-called soft cores (e.g. ARM) being implemented on FPGAs but that’s probably via Verilog.

It would be great to learn more over time about what you say above and how it relates to your emerging language:

…but a lot of work has still to be done on the direction of formal correctness. I’m strongly convinced that the road is working on the semantics of digital objects. Avoid wiring by abstraction or assigning “strong type” to wires so that the designer only has the freedom of doing correct things. On this side there is a lot of room for language engineering, for instance applying the concept of projectional editing.

David

1 Like
9

Very interesting presentation!

Apart from learning a lot about HDLs, I was particularly intrigued by the apparent conundrum of being stuck between traditional HDLs, which provide a “connection” mechanism, but one that is too low-level, and current trends in HDLs, which provide much greater ability to abstract, but are really too algorithmically focused, and thus potentially too far away from the hardware and hardware concerns.

I think we actually face a very similar problem in software, where we typically connect different pieces of software much more than we write algorithms, yet our languages are highly focused on expressing algorithms, and our abstraction mechanism are essentially procedural (or functional), leading to architectural mismatch.

You can see this problem manifest itself in how non-algorithmic problems are made to conform to algorithmic solutions in ever more creative ways (Rx, “Reactive” UIs, async/await, RPCs, …).

I wonder if abstraction mechanisms based on connectors rather than functions or procedures might be helpful for HDLs, and vice versa whether connector/connection semantic requirements of HDLs might be helpful in informing such an abstraction mechanism.

2 Likes
10

Really interesting parallelism…

11

Hi David, my intention is to share details as soon as I have an alpha release. I’m working on ANTLR+Kotlin flow as described by Federico in his publications. stay tuned :slight_smile:

1 Like
12

In HOPL IV: History of Programming Languages (2021) one of the conferences was about Verilog HDL and its ancestors and descendants

You can watch the video: PLDI 2021: Verilog HDL and its ancestors and descendants

1 Like