You may want to check that known-good RTL

In his blog Coding Horror, Jeff Atwood wrote: “Software developers tend to be software addicts who think their job is to write code. But it’s not. Their job is to solve problems.” Whether the tool is HTML, C, or RTL, the reality is we are now borrowing or buying more software IP than ever, and integrating it into more complex designs, and new issues are emerging.

When development teams mostly coded their own stuff, they made their own bugs, and they developed methods to hunt them down and eliminate them. That worked on relatively small code bases, with a high level of familiarity in both the code being written and the nuances of the environment to build it. “Oh, that message is just a warning …” is kind of the software equivalent of not reading the assembly instructions for a simple DIY project. Having a few nuts and bolts left over at the end of a small project isn’t all that alarming, as long as things work.

In coding, familiarity breeds complacency, which then leads to contempt. The first dynamic that developed was teams started borrowing code, from either distributed teams throughout the company working on similar projects in other locations, or third-party consultants paid to create code for projects, or from the open source community. Those folks, while mostly intelligent and well intentioned, operated under different conditions than the familiar surroundings of the main project. “Known-good” code from another team could easily inject build issues or outright defects when integrated into the project mix, and leave your team with a new problem.

Teams generally responded to that by reading the source code from the submitters prior to integration, a process which although time consuming can work if focused on a few modules of limited complexity. That led to academic and commercial development of static code analysis tools, automated readers that could quickly check rules against code bases of any size much more quickly and efficiently than human eyes alone.

The new and larger dynamic is buying IP, particularly in EDA projects where RTL is commonly used. In the “average” SoC (if there is such a thing), there are 85 IP blocks, with 85 swathes of RTL backed by the substantiation of someone, somewhere, as working. There are also concerns with FPGAs, since RTL eventually runs into real constraints of LUTs, interconnect, memory, power, clock domains, and other FPGA-specific resource limitations. Meeting functional requirements is one thing, but fitting into the larger picture of place and route, power optimization, and resource usage requires more intimate knowledge of the project environment.

This is where a design rule checker like Aldec ALINT comes in, enabling RTL developers to solve problems they are actually having with code from various sources. ALINT performs a set of standardized checks against industry guidelines such as STARC. More importantly, Aldec has recently added capability in a premium rule set to help with implementing “routing-unaware RTL”, which is a near-perfect description of that block of RTL you just borrowed or bought for your project. Additionally, ALINT allows customized policies, providing an even deeper level of project-specific knowledge to be checked automatically.

This quote from Hitachi Cable, Ltd. on ALINT captures what is happening in today’s complex SoC and FPGA designs with layers and layers of RTL from multiple sources, internal and external.

Since we started using ALINT, we have identified several critical problems in our current RTL design, including complex hierarchical issues that would otherwise result in excessive routing delays.

Implementing standard and custom rule checking found problems in a large, existing, and almost certainly deemed as known-good RTL code base that otherwise would have gone undetected well into place and route. Is the Hitachi experience unique? I doubt it; for a project of any reasonable size and complexity, there are problems lurking, if not already built-in they are certainly waiting to be exposed when one more piece of new IP is added.

The development process is shifting from exclusively writing code to integrating and co-verifying code from many sources, and this is especially true for RTL designs. Solving problems sooner in this new process is the key, and RTL design rule checking can play a vital role in navigating through increasing complexity.