Continuous Linting with Automatic Debug

Lint tools analyze RTL statically and report code segments that do not comply with the selected coding guidelines. It is quick to run and as the error messages are very precise it is easy to fix the issues. It requires much less resources to fix a linting issue than to find and fix the same issue during simulation of a test. However, the large amounts of error and warning messages that the linting tools produce is a problem. Developers tend to push out linting until the very last moment just before the release. The engineers have plenty of critical test failures to attend to first, so it is a rational decision. However, this does not use the full potential of linting, because linting errors are very quick to fix, and some of the reported linting issues will be the same issues that takes much longer to debug during simulation. Pushing linting to the end of the project misses the opportunity to save a lot of time, but on the other hand developers cannot waste time by running the lint tool every now and again just-in-case they would find some good bugs. The solution is what we call continuous linting, where we combine the linting tool with an automatic debug tool of regression failures. At the start of the project we select the subset of the coding guidelines that the design must comply to. The automatic debug tool then runs the linting tool regularly, e.g. Each night, and when a linting issue is detected then the automatic debug tool sends a bug report to each individual with a list of linting errors this person has caused and in which commit they were introduced. We believe this unleashes the full potential of linting. By reporting the issues immediately to the individual that caused them instead of waiting to the end of the project, issues are fixed earlier at no extra human effort. The issues have to be fixed at some point and better sooner than later. This is all made possible by the automatic debug tool. As the engineers will fix their linting issues immediately- this will probably save time as some of the simulation bugs will be fixed faster and with less effort as more issues will be fixed due to linting error messages and fewer by manually analyzing simulation failures. In this paper we present the experience from a real ASIC project using continuous linting. We measured the number of linting issues that the automatic debug tool reported over a two month period. At the end of this period there were 0 linting issues outstanding. Had we waited until the end of the project to look at the lint issues there would have been 3617 lint issues in total to analyze. This is bound to have a significant positive effect on the project. The cost of fixing linting issues immediately by the person that just caused them is much less than for an engineer to sift through large amounts of lint errors and warnings at the end of the project.