I used to accept bugs as a part of what happens in hardware development. Start a new project, write a bunch of code, deal with the bugs that inevitably arise, stress out about whether I can fix them before development milestones, cross my fingers that regressions pass the day before tape-out, repeat.
After several years of acceptance I’ve started taking bugs personally. I hate bugs. They’re no longer acceptable and I’ve changed the way I write code to avoid the embarrassment of creating them. For me that means using SVUnit to unit test my testbench code as I write it.
Knowing that test-driven development and unit testing with SVUnit has improved my code in every way, that others have found the same and that it’s become an option for everyone, I’ve turned advocating for SVUnit into a bit of a hobby…
I’ve grown to attribute bugs not so much to developer ability or quality of specification or language or other commonly held positions but to the habits we rely on to write design and testbench code. Primarily, I’m talking our debug later approach to writing code. Write the RTL then debug the RTL; write the testbench then debug the testbench. We don’t think about it, we just do it. It’s a habit. It kills our productivity, just like cigarettes kill people.
While EDA reacts to long debug cycles by investing in new debug tools, the only way I see to improve quality is by adopting proactive coding techniques (test-driven development being one option that I personally use. There are others). But before we do anything, we need to realize that bugs are formed out of habit. Kick the habit and voila… fewer bugs. Continue reading
About a month has passed since the great unit testing discussion in the Verification Academy booth at DAC in Austin. It was my second year in the booth. Very grateful for having had the opportunity. It was a lot of fun!
The format involved me cycling through a bunch of questions and comments on unit testing as a series of topics during which time discussion would erupt with me and audience.
At least that was the plan! Continue reading
My kids play a game where they pick out people and argue about what their superpower is. If we’re all indeed born with a superpower, I’d have to say mine is ignorance. Admittedly – and, yes, unfortunately – this is a superpower that couldn’t be more lame. But accepting the hand I was dealt, I feel like I’ve turned ignorance into an advantage. Continue reading
Heads-up that we’ve moved SVUnit from Sourceforge to GitHub. This move was a long time coming, finally got it done a couple weeks ago. From now on, all new development will take place in the SVUnit GitHub repository. We may continue to post new releases to Sourceforge for a time while people sort out any download pointers, but I expect that’ll only last a few months. I still need to move open issues from Sourceforge to the GitHub issue tracker, but any new tickets should be filed on GitHub.
I regularly hear that part of why designers don’t have time for unit testing RTL is because they’re under extreme pressure to deliver RTL to PD. I have very little experience in this direction but I think it’s so PD can get on with floorplanning and <whatever it is they do>. The thing about the early RTL drops is that they almost always happen before any meaningful verification is done. They tend to be very buggy, sometimes borderline non-functional, but they must be useful otherwise the pressure wouldn’t exist.
While I don’t totally understand the reasoning, I do understand the pressure. When a design engineer says there’s no time for unit testing, I shrug my shoulders and sympathize as best I can.
Then I get thinking… what if there’s a way we could relieve the pressure by giving designers a way to deliver buggy, non-functional RTL faster than ever to PD? With the added breathing room, they could add a few unit tests as they code.
This is where Poser comes in. Continue reading
Seeing unit testing catch on and flourish with a new team has made the last few months at work pretty fun for me. Getting to this point, though, has been a ton of work. Considering the journey toward unit testing can have a lot of twist, turns, surprises and disappointments, I figured it would be a good time to recap in hopes my experience helps others grow unit testing within their teams. Continue reading
In a post a couple weeks ago called Sorry Design Engineers, I Can Do Better, I told design engineers that I’d do a better job of giving them what they need to unit test their RTL. I felt like I’ve been neglecting design engineers and decided I needed to set a new, more inclusive course. Tonight I took a first step in that direction. I’ve released SVUnit 3.10 with a simple clock and reset utility that’ll make it easier for design engineers to unit test synchronous and asynchronous logic. I also recorded a 25min code demo for design engineers to show how they can use SVUnit to unit test RTL modules. Continue reading
I’m looking for a list of discussion topics for a panel discussion that’ll happen at DAC in June. It’ll be a very informal/interactive session. We’ll take a list of topics and cycle through them in a series of 5-10min discussions. Audience will be encouraged to participate; agreeing or disagreeing as they see fit.
I’m looking for topics to get discussion rolling and am hoping you’ll chime in with your ideas. So if you’ve got a few minutes, I’d appreciate you joining the google group discussion and dropping a few comments or questions regarding unit testing, test driven development, SVUnit and/or related. As many as you can think of. Topics could be for or against unit testing, doesn’t matter. In fact the tougher the topic, the better! I’ll take 10-15 and and quote them in a series of slides. We’ll show the slides and invite the audience to weigh in.
Thanks for helping out!
Advanced verification methods put chip leads and managers at a real disadvantage, especially when it comes to visibility and predictability. With long testbench development times, early progress in constrained random is essentially based on trust; being random, the inherent uncertainty makes predictable scheduling and release milestones rare. Continue reading
© 2013-2016 AgileSoC All Rights Reserved