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 GitHub. 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 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!
When I hear the word shame, there is only one thing that comes to mind: Slapshot. If you’re Canadian, chances are you already know what I’m talking about. To everyone else, Slapshot is a hockey movie and shame comes from an interview where Jim Carr is talking penalties with Denis Lemieux, goalie for the Charlestown Chiefs. Denis comes up with this to describe high-sticking, slashing, tripping, hooking and spearing… Continue reading
Heads-up that I just posted my end-of-conference summary of the Agile2014 conference in Orlando. In short, it was a great conference with some very promising signs for agile hardware. You can read my full report here.
Finally solved a mystery this week after two different things happened. First… got an email from a coach telling me she was doing some kanban training with a hardware team. Second… had a chat with a couple guys about using scrum with a verification team. Put those 2 seemingly benign events together and voila… I finally find the right way to describe how I’ve approached functional verification the last couple years: it’s kanban with single item flow.
Here’s what that means… Continue reading
It’s still subject to change, but if you’re looking for our hardware/software co-dev demo at Agile2014 2 weeks from today you’re probably going to be looking for something like this…
Provided I can find the space, we’ll have the hardware + monitor where the demo runs (you program the hardware and see it run on the monitor), there will be a laptop to tinker, a few prepared stories to get people started (1 for each of the software/driver/hardware layers) and some pictures and diagrams to explain the the thing. Then there’s me to help and you to drive!
And yes… it looks super fun because it is super fun 🙂 .
It was a few months ago when Soheil and I posted our commitment to agile hardware development for our agile hardware/software co-development platform. The plan was to build a platform that would bring hardware and software developers together by showcasing TDD as a valuable technique in both domains. Neither of us really knew what we were doing at the time. But figuring the worst case scenario would be limited to complete failure and public ridicule, we went for it anyway ;). Now it’s just 18 days until our Agile hardware/software co-development demo makes an appearance at Agile2014 in Orlando. We’re cautiously optimistic we’ve avoided failure and are hoping any public ridicule will be minimal. Fingers crossed.
Mike Yang from Hillsboro is the winner of the limited edition AgileSoC.com T-Shirt. It’s great to see people taking the time to offer an opinion and spur conversation about agile hardware development so thanks to everyone who posted. Maybe we’ll do it again someday ;).
In case you missed it, here’s Mike’s winning comment… Continue reading
Since posting The Great Agile Hardware Myth last week, I tried to think of some obvious myth that exists in the mainstream; some claim that we’ve all made that, without fail, turns out to be absolutely and entirely false. Took a while but I think I found it. We could have called it The RTL Done Myth, but I chose to call it the The 90% Done Myth.
|We’re 90% done. If everything goes well, all that’s left is testing and debugging this last 10%.
||The gant chart that says we’re 90% done is lying to us. We know it’s lying to us because it’s lied to us before, many times. We’d rather not use this gant chart but because tracking development progress is so important and we haven’t figured out a better way to do so, we feel like we have no other option than to keep trying to believe it.