Graham is VP of Marketing at Real Intent. He has over 20 years experience in the design automation industry. He has founded startups, brought Nassda to an IPO and previously was Sales and Marketing Director at Internet Business Systems, a web portal company. Graham has a Bachelor of Computer … More »
How Bad is Your HDL Code? Be the First to Find out!
September 4th, 2014 by Graham Bell
(Courtesy of Andy Glover, cartoontester.blogspot.com)
It is a fact-of-life that as soon as RTL designers start writing the code for their modules, they will begin to introduce unintended errors. To eliminate these errors, designers will use a variety of tools to ensure the code is correct before hand-off. Functional errors are typically caught by a mix of static tools (auto-formal and assertion-based) and simulation. However, before designers start to uncover functional errors their code should pass RTL linting. Linting has the advantages of delivering very quick feedback on troublesome and even dangerous coding style that causes problems that can show up in simulation, but will likely take a much longer time to uncover. With the right lint tool, you can catch the “low-hanging fruit” before tackling functional errors.
As the code goes through refinement by a developer, Real Intent’s Ascent Lint is applicable at any stage of RTL maturity. Designers can be working with a mix of internally developed and external IPs with different levels of maturity and compatibility. And they can check their RTL early and often through development, confident it is ready for integration with other modules.
In order to bring this mix of IPs together under one umbrella, Real Intent recommends using a succession of Lint policy files. Each policy file is intended to achieve a significantly greater level of maturity towards achieving quality RTL using a set of Lint rules. The policies are tailored to apply across the broad spectrum of design types, but may be adjusted as needed. Design teams, after careful consideration, may skip individual steps in the flow in keeping with their priorities. Additionally, the sequence of policies is optimized to lend itself for early detection, faster debug and low noise. Here again, design teams may choose to re-order the recommendations based on their best practices.
HDL maturity is broadly classified into three stages of Initial, Mature and Handoff with an associated policy file. The three stages are defined as follows:
By fixing errors earlier in the design flow, with static verification such as Lint, significant project timeline savings can be achieved. Designers realize maximum productivity through using a staged set of policy files that address each level of code maturity. And designers can be confident that when their code is integrated into the project, they will not “look bad” to other team members, since they are delivering quality RTL for downstream simulation and implementation.