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.
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.
I’ve often heard the statement that hardware developers follow a more disciplined development process than software developers. What I haven’t heard much about is what it means to be disciplined and/or why that’s the case. So let’s open that discussion in hopes it takes us somewhere useful.
- How would you characterize a disciplined development process?
- What makes one team more disciplined than another?
- What’s the best example you’ve witnessed/heard of a team acting following disciplined development process?
- Why is it important to have a disciplined development process?
- Who follows a more disciplined approach to development: hardware or software? Why is that the case?
Those questions are for you so feel free to address any/all of them. No right or wrong answers to these questions, just opinions. Please share yours :).
In the DVCon abstract I submitted last month, I mentioned a new verification component called the uvm_boat_anchor. The uvm_boat_anchor is top-secret development so not much was known at the time about this new component, even by me. For the abstract, all I could say was:
The paper concludes by introducing a new UVM component, the uvm_boat_anchor, that further demonstrates the perils of continuing to ignore the value of this basic yet entirely necessary technique.
It’s been a couple weeks since and while the team working on the uvm_boat_anchor is still operating in stealth mode, I’m happy to announce that I can finally give people a sneak peek. Continue reading
I don’t normally need much motivation to try something new on AgileSoC.com. So at the first sign people were interested in the idea of adding a forum to help facilitate discussion between hardware and software developers, I went ahead with it. As of this morning, you can now post topics to AgileSoC forums.
To start, we’ve have 3 areas for people to contribute. First is the general category. Got a question or comment for other AgileSoC.com followers? That’s where you’ll want to post it.
Next, we’ve got the Hardware Developer Seeking Agile Software Guidance and Mentoring. In case the title isn’t obvious enough, here’s what that’s all about…
And then the big one, Agile Software Developers With the Time And Patience to Help Out, where I sincerely hope we find some agile software folks courageous enough and patient enough to lend a hand to a hardware developer in need of a little inspiration.
There they are… the new AgileSoC forums. Let the discussion begin!
This may be a good idea… it also may be a terrible idea. Either way it’s worth a shot. You’ve heard of take your kid to work? Well, this is kind of like that except the kid is a hardware developer. Continue reading
DVCon call for papers hit my inbox last week. This time around, to possibly save myself the effort, I figured it might be more productive to let other people decide whether or not mine is a topic they’d like to see at DVCon. I’ve got a draft title and abstract so far…
How UVM-1.1d Makes the Case For Unit Testing
In six weeks, two verification engineers discovered 10 defects in the UVM-1.1d release. The defects were not lurking in the shadows of complex corner scenarios; it didn’t take hours of constrained-random stimulus to discover them; nor was there any need for functional coverage with intelligent feedback. These were simple, obvious defects discovered with an equally simple and obvious technique. It’s called unit testing and it comes from software development where the value placed on code quality and maintainability is higher than what we aspire to in hardware.
UVM-UTest is an open-source project with the goal of demonstrating how unit testing can be used to bring software level quality and maintainability to design and testbench code. This paper documents the development of UVM-UTest, how it was conceived, statistics and style for unit tests written, its success in terms of defects found in UVM-1.1d, the lessons learned and recommendations for applying unit testing beyond the UVM. The paper concludes by introducing a new UVM component, the uvm_boat_anchor, that further demonstrates the perils of continuing to ignore the value of this basic yet entirely necessary technique.
I’ve submitted proposals twice in the last few years. Neither was accepted. Agile development and test-driven development – the topics I’ve submitted – aren’t your average mainstream, audience grabbing topics so that wasn’t overly surprising. Maybe this proposal is different. Or maybe it’s not. Either way, I’m leaving it for you to decide.
If there’s enough interest, I’ll submit it and see what happens. If you really like the abstract, share it with your colleagues so they can vote, too. Or if you hate it, may as well share it, anyway. I don’t mind people seeing my incredibly terrible ideas. I’ll just entertain myself with it.
Proposals are due Aug 27th so share the link and get your votes in asap!
Get the latest version of MiniTB
[CSSBUTTON target=”https://github.com/nosnhojn/miniTB/archive/master.zip” color=”000000″ textcolor=”ffffff” float=”left” newwindow=”true”]Download MiniTB[/CSSBUTTON]
Through the hardware industry’s continuing infatuation with leading verification technologies – constrained-random verification, functional coverage, numerous fancy methodologies, intelligent testbenches and a host of others – the needs of designers have been thoroughly ignored. That changes with MiniTB. Continue reading
My First SVUnit Test Challenge. It’s easy and perfect for anyone new to SVUnit. Continue reading
Let’s have some fun, shall we? I’m looking for people to show their commitment to hardware quality by taking the
Great final day at the Intel Agile and Lean Development Conference. It started with a keynote talk by Jim Tremlett of Rally, I had morning talk and an afternoon talk and filled in the rest of the time with hallway discussion. As always happens to me during an agile conference week, I’m tired and my head hurts. That was compounded by me giving 2 talks in the same day which I’ve never done before. But I made it and now it’s time to crash. But first… Continue reading