Tip of the Month

We can update you automatically when our Tip of the Month changes.
To receive regular notification of updates to our Tip of the Month section, click here.

Design for Debug and Good Advice

On a recent VHDL training course, we had some engineers from one of our client’s Test group attending. As you would expect, they were more interested in designing good VHDL testbenches than other course attendees, whose main focus was in writing synthesisable code. However, the Test group engineers spent longer debugging their VHDL code despite generally writing better testbenches. Their better testbenches tended to use assert statements, were better structured and tested more of the DUT’s functionality. There is no concept as Design for Test when writing RTL VHDL code, but as with other programming disciplines there are ways to code VHDL which result in less likelihood of coding errors. As such, we are interested here in writing code that is less likely to need debugging and where there are errors, writing easily debuggable code; let's call this concept Design for Debug. OK. Concept. Design for Debug. Yes. This probably means thinking more about the code before we write it, and probably writing more code, too. Is it worth it? Well, we generally find that it takes 4 to 5 times longer for engineers to debug the code they write on our training courses, than it does for them to think about the design and write the code. Yep, the old 80:20 rule strikes again. Even we, as experienced VHDL coders still have to debug our code. However, we also find that our debugging time is generally very quick. Although part of this can be attributed to familiarity with VHDL, there is a more important reason; we write more easily debuggable code. Let’s look at some of the approaches and techniques which lead to Designed for Debug VHDL code.