BLOG

D'Artagnan, Athos, Aramis, and Porthos.

Yeah, I googled that. Busted. Soit.

Like the three musketeers, HDL code comes in two forms most designers can come up with. There is a third form, but let’s not get ahead of ourselves.

Now, a recently graduated engineer will not touch any RTL design at all. That is for sure :-). Back in the nineties, I had already written HDL code and demonstrated it on FPGA. But when I started at an ASIC consultancy firm, my first job was NOT RTL designer. Because a hardware description language has a syntax like software. You know “if then else” and “case” statements. The problem is there are two types of HDL files. Something I call behavioral code, also called testbench code or non-synthesizable code. An “if then else” in behavioral code is never intended to describe hardware, it is used to verify functionality. This allows me to use file IO, wait statements and complex math (log, sin, …). The full syntax and packages or include files are available to me.  And that is where I started.

The second kind is called RTL, register transfer level. This syntax is a subset of the syntax of HDL. Since the code is a textfile with a software like syntax, we use synthesis tools to translate the hardware description into our target technology.

The design plus a library of cells gives us a digital circuit called the netlist thanks to the synthesis tools.

We have specific syntax that can be:

Best thing? It changes over time! Tools do not support all new language features immediately. An example is “interfaces” in systemverilog. Some tools do support them. Some tools claim they support them but it turns out, not all features of interfaces. Some tools don’t support it but will add support in the future. Why do engineers start with verification? Because they went on a course and learned the HDL syntax. All of it, which is good for behavioral code (verification). But not for RTL. If then else nested statements translate automatically into a priority multiplexer. A case statement translates automatically into a non-priority mux. And a multiplier could be translated automatically. Unfortunately, in high-speed applications, the timing path from input of the multiplier to the output is going to violate the timing requirement that is enforced in the design. Hence, a multiplier is something that you need to design (or use IP). A fast multiplier is pipelined in more than one clock cycle. But how many? Depends on the designer. And last but not least, a synthesis tool cannot translate file IO into hardware. Or come up with a sinus or logarithm implementation. In verification, nobody cares about the actual synthesizability of constructs. And one learns to see how RTL is written in a correct way and what is synthesizable. By reviewing the RTL and verifying the RTL, one gets familiar with the limitations that RTL design has. If you would allow a recently graduated entry level engineer to write HDL code, it will compile. Because all will be legal HDL syntax. But it will most likely fail synthesis since they lack the experience that RTL designers have. And while we are at it, the partitioning over the last two decades from ajn all-in-one ASIC engineer to verification, DFT, STA, synthesis engineers has cut the link between all front-end design tasks. Pareto principle wise, 80% of the time of a project gets lost. Yes, you hear that correct. Because of back and forth between synthesis and design, STA and design and DFT and design. In the nineties, chips were much smaller and teams were accordingly small. We mastered all front-end tasks and hence avoided issues in DFT, STA and synthesis because we worked on all front-end tasks. That is no longer the case. Today, junior engineers look at horrible RTL code and assume this is the way RTL is written. And then they go through the mess of changing RTL because it fails synthesis, DFT and/or STA rules. So, they start using lint tools to get a feel of the problems later on.

They get thousands of violations that might or might not be an issue. And still things slip through, especially for STA since timing is not part of the lint checks (usually it ends with some clock domain crossing stuff but that’s it). I have a few easy to understand rules to write RTL code that doesn’t need lint checks but it is ready for synthesis, STA and DFT per definition. That is the value of an old geezer like me. Anyway, end of rant.

If you are still reading right now, you probably wonder about the third kind, right? Well, this is also a lost art of HDL design. It is called structural code or interconnect. There is zero logic in the file, and that is very important. It connects sublayer parts together. The interconnect generation can be fully automated. Automation means it removes the inevitable cut and paste errors, the mistakenly unconnected signals (after so many changes) and lots more. And … Drum roll. It allows to partition the synthesis process. This is important because it allows synthesis and early STA during design. Every sub block can write out a db file (synthesis database file). The interconnect reads in all underlying db files and uniquifies (if needed in case of multiple instances of the same block). The synthesis report will give you an idea of the area of the block or module. If you slightly overconstrain the clock, it will be able to tell you if the block meets timing. And it will report latches and flipflops that have no reset. That saves you an expensive lint license. And avoids most back and forth with the tools used to generate and check the netlist. And that hits two problems that cause a lot of issues in ASIC design today. I have seen many interconnect modules with logic in it (seriously, don’t do that). And, second, interconnect is hand edited which leads to mistakes. Even though one has version control, there will be connections commented out for who knows what reason. Hence, this structural connect code is not RTL and not behavioral. It should be pure wiring. And it should be completely automated. And in most companies that is definitely not the case. Hence, entry level designers today are learning from engineers that have lost touch with the whole front-end design cycle. The whole design, verification, synthesis, DFT, STA partitioning. Similar to a startup that grows, the partitioning into groups of people that have one task only, loses the project focus. Who likes the IT department in big companies? Fill in a ticket. Ticket gets assigned but maybe not right away. Then it is read and replied to, but maybe just with some questions. Or it is transferred to another department (partitioning into windows, linux, network, server department). For an ASIC project, the result is insulting to the basic principles of an engineer. Project slip. Over budget. Risk, cutting corners. Stress. Overtime (unpaid!). Rescheduling holidays for project tape-out priorities. And it is not even necessary if you adhere to some simple rules. That is what an engineer is all about. Reduce risk to the maximum given the budget and time. And it is a simple principle: KISS, keep it simple and stupid. Most companies, if not all, adhere only to the “stupid” part of KISS.

And that is so frustrating for many engineers that want to do better than what we see now.

A version of this article was posted on Linkedin.

Feel free to share the article and link with me on Linkedin!