Every time I perform my annual house clean-up, I have an intense debate with myself. And every time I decide not to throw away any of these notebooks that contain endless information about my previous projects, endless debugging cycles, and an even more endless amount of dust upon themselves. But not only do they not contribute to my work, but what’s worse, they annoy me time and time again, every time even more than the year before, as the bunch only got bigger and dirtier than the last time it survived the clean-up.
One might ask why I simply wouldn’t throw all the mess away, and the answer here is not as simple as it seems. There is always my zodiac Virgo sign, leading me to keep stuff that I don’t need, simply because my anxiety would spike with every item thrown away, as soon as there is the slightest chance I might need it in the future. Indeed, in a sporadic case, I use the information stored a long time ago. Unfortunately, it will then take me hours and nerves to find what I need.
Isn’t it paradoxical that I develop devices with colossal processing and storage power while at the same time I store the information concerning their development in a notebook? One can argue that I am an isolated case sticking to the primitive methods of work, but I know at least two more samples that sit right next to me, applying the very same strategy. And anyway, I think it is quite certain to say that there is something wrong with the entire debugging process across the industry and that it needs to be fixed.
So what makes debugging such a complicated process consuming ~50% of the hardware verification development cycle?
First of all, it is a process too prone to losing data. Any previous debugging cycle barely helps the following. Apart from our notebooks and memories, we do not have a practical way to collect debugging steps and rely on them to resolve similar problems. Often, we debug again and again the same issue, only in the end to realize that we already fixed something of a similar nature, which manifested itself in a different or even in precisely the same way.
Secondly, it is a process that we still typically perform alone, although everybody knows that even a rubber duck sitting across your table can help you ask the right set of questions that can lead you to the right path. That makes debug a challenging skill to learn and to teach.
Debugging - a sixth sense?
Finally, debugging relies heavily on our intangibles, gut feeling, intuition, and the sixth sense. On the one hand, it can indeed be a super-powerful feeling to solve an issue in a matter of seconds, thanks to our God-given talent. On the other hand, people tend to underestimate and easily forget all the situations in which our God-given talent led us to a completely wrong path, wasting a lot of time that we would save if only our debugging cycles were done systematically. This is especially true for more simple bugs for which we assume are undoubtedly not present in the later stages of the projects, such as a missing clock, a block under reset, and similar.
Solving Debug with Cogita
We in Vtool are targeting to solve all three of the challenges mentioned above. We are developing a debugging platform called Cogita, whose primary goal is to log debugging cycles, act as a debugging companion through interactive elements helping ask the right questions and providing correct answers, and actively participate in debugging processes by performing sophisticated Machine Learning algorithms and pointing us to details in our data which might have been missed otherwise.
Being an “interactive notebook”, Cogita stores all the information that would otherwise be forever sunk in the sea of my disposed notebooks, helps me navigate them, and does all the dirty work of digging through the mess, finding the necessary data instead of me.