Considering SoC development requires several disciplines and considering our history of specializing and siloing these disciplines, it’s easy to see why people fall into the trap of equating agile development with concurrent development. But they aren’t the same. Continue reading →
They call them comfort zones for a reason, it’s because they’re comfortable.
I don’t like being in my comfort zone because when I get comfortable I fail to recognize when a change is necessary. I start framing uncomfortable change as impractical, then concoct seemingly logical arguments to avoid it. Trouble is, some of these arguments aren’t logical at all. They’re just my way of avoiding the pain that comes with taking the chance.
Some may think that becoming an agile development team is impractical; that the approach won’t work for them, that it’s too big a risk or it’ll be all pain and no gain. Where agile becomes impractical, it’ll be watered down or avoided.
As an example, suppose someone suggests XP as a model for an agile transition. Amoung other things, XP brings with it a series of primary practices. If XP doesn’t fit into your comfort zone, there’s any number of practical reasons for why you might avoid any – or all – of these practices (listed in bold). Continue reading →
Here’s a marketing video posted yesterday from Sonics about an Agile IC Methodology they’re promoting in the run-up to ARM TechCon. Normally I might not post stuff like this directly on AgileSoC.com but I’m making an exception because one of the people in the video is me… along with some other guys that are far more recognizable .
If you watch the video, I hope you’ll take a few minutes to comment. I’m interested to hear what people think about it and the fact that a few different folks within the industry are coming together to promote agile development.
You’ve started doing TDD or unit testing your systemverilog code with SVUnit, your defect rate is down and you’re producing better code. You’re at the point where your experience could benefit the rest of your team but you’re not sure how to get the point across.
Pretty much every testbench I’ve ever built, used or seen has a free-running clock that’s driven within a while or forever loop. Not much can happen without the clock in a synchronous design so defining the clock logic is usually the first and most obvious thing we do as verification engineers.
Assuming your design-under-test is synchronous to the positive edge (they almost always are), testbench components usually do their work somewhere off the posedge to avoid races. With even a simple testbench these days, there will be several components, each with their own thread, pushing or pulling data from various interfaces on the DUT. The free-running clock is that steady bass drum beat that holds everything together. Continue reading →
I’ve scheduled a regular agile hardware hangout to run weekly on Wednesday nights. You can either join us from the google group where I’ll post links and updates or you can go directly to the google hangout every wednesday at 7:30pst. Anyone interested in agile hardware development can join to ask questions and/or talk about whatever they like. Hope to see you there!
UPDATE: I’ve started an agile hardware hangout google group. I figured posting hangout links there would be better for keeping people posted on when/where we get a hangout started. Please join the group if you’re interested in this.
I often have a difficult time differentiating between good ideas and completely stupid ideas. I’ll admit to having had more stupid ideas than good ideas, also that I have no idea where this particular idea will end up. But in the name of friendly collaboration and pulling together the agile hardware community, I’ve decided I’m just going to go for it and see what happens.
I just posted version 3.1 of SVUnit to sourceforge. If you’ve been waiting patiently for me to get rid of the makefiles, the wait is over. From here on, we’ve got a simple command line script to run SVUnit unit tests with any of IUS, Questa, Modelsim, Riviera PRO and VCS.
The best place to start with version 3.1 is the README.txt in the release package. Pay attention to step 5 because that’s where everything changes (for the simpler and better). All the code in the release package, including the examples, has been updated to match the new scripts so there shouldn’t be anything misleading in there. Also exciting is that all the documentation has been removed (it was incredibly out-of-date and misleading to say the least). I still need to update the SVUnit on demand videos which I’ll do as soon as I can.
Lastly, here’s the usage for the new run script that I’ve been touching up over the past several weeks…
If you spot anything that needs attention, I’d appreciate it if you could file a sourceforge ticket. Touch-ups should be easy to turn around quickly. FYI… the next updates I’m considering are support for UVM1.2 and parameterized unit test classes as well as a few other things people have been asking for.
Thanks to those that gave feedback and helped get us to version 3.1!