Slacking off? Me?? I guess maybe I have been because someone finally got sick of waiting for me to get to a new SVUnit feature and added it themselves…
…and that made me happy.
As of 2 about weeks ago, Tudor Timisescu is the latest addition to the list of active SVUnit developers-at-large. That brings us to a grand total of 1… which is 1 more than the 0 we had before! Continue reading
Pleasantly surprised that I’m able to call DAC a big success for agile hardware.
Agile Evolution in the Verification Academy Booth
It started monday evening with the Agile Evolution panel in the Mentor Verification Academy booth. We were shooting for a half-hour open discussion where we went through some of the concerns people have with agile development (thanks to my work colleagues for helping come up with a list to get us started). Now that it’s over – and worked great – I can admit that I was a little nervous about the format. I knew the key would be people jumping in with their opinions because without that it would have been a boring half hour of one way conversation. Fair to say we did it though thanks to a great job from Dennis Brophy as moderator, Harry Foster as expert and me playing the role of ‘that other guy’. Continue reading
Here’s some information about a second agile hardware session at DAC in San Francisco. On June 8th at 5pm, you’ll find me and Harry Foster of Mentor Graphics in the Verification Academy booth talking about An Agile Evolution in SoC Verification. Here’s the session description from the Verification Academy events page… Continue reading
Good news and better news…
The good news is that I’ll be part of an agile hardware panel discussion at DAC this year in San Francisco. The discussion happens at 10:30am on June 9th at the Moscone Center and it’s happening thanks to Randy Smith and folks at Sonics. For more info, check out the conference website.
The better news is that this is the first of two (repeat: two) exciting chances at DAC to build the agile hardware community (I’ll point you to the other in part two as the details are finalized). Needless to say, two chances to reach out at a conference like DAC is a great opportunity so if you’re a fan of agile hardware, a practitioner, someone who wants to know more or somebody who wants to get out and publicly disagree with the whole idea, I hope to see you there!
On Friday I decided I could use a break from the blog so I’m going to step away for a bit. Not exactly sure for how long, but it might be a while. Or maybe not. We’ll see. Meanwhile, you’ll still be able to find me at firstname.lastname@example.org for questions, comment and discussion re: agile hardware. Later.
For me, this is a very exciting post because I think I’ve made some pretty important headway regarding TDD for hardware designers.
My big side project as of late has been a real pilot dedicated to using TDD to write RTL. I’ve blogged about some of the things I’ve learned already but the big eye-opener that I haven’t talked about yet is how TDD helps us with design partitioning and testability. Continue reading
It should be obvious by now that I don’t mind paddling against the current. And I don’t mind suggesting a rethink of “best practices” we use in hardware development. But then there’s the practices that even for me are touchy subjects, where I know I’d be uncomfortable. Continue reading
Considering there’s been lots of new visitors to AgileSoC.com the last few months, I figured now would be a good time to (re)welcome everyone with a reminder of why we’re all here! Continue reading
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