Why HDL needs to be further abstracted, applicative functor

Why HDL needs to be further abstracted, applicative functor

Suppose we want to integrate the AHB bus protocol into our sub-design.

The digital design process for an RTL/Verification engineer would be

"Well, we need an AHB interface at the boundary, and a functional unit block (FUB) to massage the incoming data into usable chunks, precisely at the clock cycle we need them. Maybe with options to clock gate and power gate as well."

In an ideal world, the boundary interface would be provided and the designer would just need to define the transform of data into these usable chunks, and when they need it.

For example, we would want something akin to

No alt text provided for this image

and this would magically synthesis into a working RTL with possibly some help from constraint programming.

Instead, what ended up happening is that the designer is usually burdened with the task of trying to connect each and every single wire and having to verify manually there is no port width mismatch and naming mistakes. For example

No alt text provided for this image

This is non-ideal because the designers don't think in terms of wire connection and the brain has a tendency to abstract or optimize away all the details that are deemed unimportant to the context. And rightfully so, because they are usually just boilerplate scenarios that occur over and over again.

Interestingly, the idea of a design abstraction implementing an interface that then returns another design abstraction seems to suggest some sort of applicative functor structure

See this guide for a short explanation of how applicative functors work

No alt text provided for this image

Using Haskell notation, the applicative functor implements

No alt text provided for this image

Where <*> stands for the applicative binary operator. We could then do something like

No alt text provided for this image

And that would be more in line with how a human brain works when trying to design a system. And I strongly suspect that there are similar or even more things that can be done in the verification space as well.

This is a very elementary treatment of the subject matter of course, but it shows how much can still be progressed in the domain of HDL and HLS.

As a design engineer, I can assure you the greatest complexity with interconnections is not the link layer, but the protocol one. Formatting flits is not an issue. (In SystemVerilog, one can use structures or interfaces to pack bits.) The protocol layer, on the other hand, is not a layer that lends itself to easy abstraction. This reflects a more significant issue. Nowadays, there is a naive quest for more abstraction. This inherits from software mindset that some try to extend to hardware. But hardware paradigm is different as a result of the substrate. All HDL provide modules as the only necessary construct to gather the functionalities.

要查看或添加评论,请登录

Alan Saw的更多文章

  • ASIC books and resources

    ASIC books and resources

    There are many excellent books about front-end ASIC design and architecture. Here are some of the few books/materials…

  • Understanding UVM

    Understanding UVM

    (Basic familiarity with SystemVerilog and OOP concepts are assumed) Let's talk about UVM. Entry-level engineers in the…

  • State of EDA and Domain Modeling for Digital Design

    State of EDA and Domain Modeling for Digital Design

    The semiconductor industry is often equated to trying to build a nano-sized city on a silicon wafer. The average time…

社区洞察