Scrum is big in software and it’s slowly creeping into hardware development. To me this is good news because Scrum would be a transformative for hardware teams. In an industry that relies heavily on the big bang, iteratively coming to potentially shippable checkpoints, as a team would do with Scrum, would be a welcome change. It would give users and customers early access to product (or some version of a product depending on the technology involved), there’d be increased opportunities for feedback and the narrowed sprint-to-sprint focus on feature subsets would propel a significant improvement in quality.
Yes, Scrum would be great for hardware teams… unless, of course, we strip out the practices and objectives that make it effective and bend the rest around practices we already use without actually changing much. That would be less great. Continue reading
In 9 years of blogging, I’m guessing at least half of what I’ve written centered around code quality or debug. For all the writing and time I’ve put into these topics, it took me until yesterday, for whatever reason, to realize I’m without a solid definition for debug. Or even a definition for bug for that matter. I guess I was relying on a common understanding of what bugs are and what it means to debug code. Realizing that may not be the case, I came up with a definition that captures what bugs are to me…
Bug: A state where a feature is defined, implemented and/or expected to fulfill a specific purpose but fails to do so.
There are times when I try and convince myself that unit testing my verification IP may not be necessary. Believe it or not, I can put together a pretty convincing argument. On a good day I shake it off and do the right thing. Other times I’m just convincing enough. I know it won’t end well, but I skip the unit tests and go straight to the code.
Here’s a couple arguments I’ve used on myself to get into trouble. Continue reading
I had a neat opportunity to do a lunch-n-learn with a large group of engineers a few weeks ago. It was organized by the IEEE Computer Society as part of a program they use to pair engineering teams with various speakers and topics. They found me through a referral from an agile software friend of mine. I pitched a topic that sounded interesting enough so it was all systems go. I flew in for a day the third week of november. We had 250 people tune in. Good realtime feedback and a great experience for me.
I’ve done webinars like this in the past but I’ve never felt like I left people with a solid feel for how they get started with agile hardware. I wanted this time to be different; I wanted to boil the mess of information that floats around in my head down to concrete possibilities; I wanted those listening to go back to their desks feeling like they had the gumption to get something started. Continue reading
SVUnit supports mixed language Verilog/VHDL unit testing.
It didn’t take much to do it but for some reason it took me a loooooooong time to get at it. It involves a new switch to the runSVUnit command line. Users can now specify a ‘-m <vhdl file list>’ where vhdl file list is all their VHDL files and extra VHDL-related command line switches. It’s been tested with Modelsim and Incisive. Probably works with VCS though I can’t say for sure because I haven’t seen it with my own eyes. If someone wanted to give VCS a try and let me know what happens, I’d appreciate it!
The updated runSVUnit usage is (emphasis on -m|–mixedsim <vhdlfile>):
As an example, if you’re unit testing a mixed language design with Modelsim where VHDL files in your design are listed in myVHDL.f and your Verilog files are in myVerilog.f, your command line would be…
runSVUnit -s modelsim -m myVHDL.f -f myVerilog.f
As always, if there’s any trouble with it you can log an issue on github, send me an email at firstname.lastname@example.org or leave something in the comments. If you were waiting on mixed language support to get started with SVUnit, now is your chance. Just scroll up and hit the big blue button to get started!
Happy unit testing!
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.