MiniTB is a simple yet powerful responsible development platform (RDP) that provides design and verification engineers with an alternative to complex verification methodologies like UVM.
That’s what should have been part of the initial announcement I made releasing MiniTB a few months ago. Originally, I envisioned it a smoke testing platform for RTL design engineers. Leaving it at that, though, I think underestimates the power of the simple platform Jean-Marc and I put together and the success people can create with it. MiniTB is not just a framework for smoke testing RTL, it’s a responsible development platform that addresses many of the concerns people have with current methodologies and techniques.
Complexity is always the first complaint people have when it comes to UVM. Second is how the addition of OO programming constructs to SystemVerilog has become the wedge that’s been driving design and verification engineers apart for the last decade. MiniTB intentionally stresses a level of simplicity and inclusiveness that have been optimized out of methodologies like UVM – slowly and deliberately.
MiniTB is powerful in that it gives you the flexibility to control your own destiny without locking you in. While it neither provides nor enforces complex methodologies around stimulus generation, configuration or communication, it also does not preclude you from leveraging existing methodologies or creating your own as you see fit. In short, MiniTB does not attempt to impose solutions upon functional verification engineers, it simply provides the framework and run-flow in which people are free – design and verification engineers alike – to create solutions that make sense to them.
If you’re a design or verification engineer that is tired of the complexity, try MiniTB.
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 :).
Very nice to see this kind of conversation popping up from Dave Rich at Mentor. He’s got a post on their verification horizons blog called A Decade of SystemVerilog: Unifying Design and Verification? to announce an upcoming conference talk. Glossing over just the title, you’d hardly expect this post to stand out from any other post on a big three website… probably just more backslapping and high-fives about how SystemVerilog has become the granite foundation for successful ASIC teams, how it’s been the catalyst for bringing design and verification engineers together in peace and harmony, how it’s feeding starving children, slowing global warming, etc, etc, etc.
But then there’s the matter of that pesky little question mark… Continue reading
Here’s another post spurred by Bill and our discussion from An Idealist’s View of Agile Hardware Development. This is a good one. If there were an award for best AgileSoC comment, Bill probably would have won it with this…
“Given the cost to tape out a large ASIC these days, we know that these incomplete designs are never going to be shipped. We are going to wait until most or all of the features are in before we ship. We don’t get multiple tapeouts to add incremental features like we can in software.
Now this may sound like I’m arguing against agile HW design but I’m really not. I’d contend that even if we were to just pretend that we could ship a design, it would force us to tie off a lot of loose ends earlier and plan the order we add features much more carefully. In fact, if we were to just change our view to add features in order from most important to least important, we would likely end up with a shippable design much sooner.
I think I may be arguing both sides of the issue here but I truly a believe that if we were to take a more holistic view of chip development and align development, verification and PD to operate in a more incremental fashion, we might just ship the final product sooner even if we don’t end up in that agile nirvana of being about to tape out on any particular Friday afternoon.” Continue reading
Last week, in response to An Idealist’s View of Agile Hardware Development, a fellow named Bill made some very thoughtful comments in a follow-up discussion he and I had. A couple of those comments have been good enough to spur on posts of their own. (I’ve requested Bill carry on with the discussion. I don’t mind having more to talk about!)
The comment we’ll take on here comes from a broader conversation about how agility stretches from design and verification through to physical design. In there, Bill makes a comment that I’ve heard more than once, both as it relates to PD and within the larger context of hardware development…
“…I think most projects do work in a semi-agile way without using those words.” Continue reading
If you saw the UVM boat anchor announcement last week you may have thought a 34 second ascii animation of a sailboat getting caught in the rain is a few hours of my time flushed down the drain and lost forever. Not true. Here’s why…
[youtube_sc url=WqWjWQu64MI width=640 height=480] Continue reading
Something I’ve been meaning to do for a while now is talk about the waterfall v. agile comparison that I’ve been doing in agile hardware talks for a few years now. Finally got around to recording and posting the video.
Here it is… waterfall v. agile development and why we need to start with the idealist’s view of agile hardware development instead of settling for something practical.
[youtube_sc url=3YA2fx2J7fE width=640 height=480]
It’s been a long while since we posted Mike Thompson’s guest blog, A Heretic Speaks (Why Hardware Doesn’t Fit the Agile Model), where he outlines his argument for why agile is a good idea that just can’t work for hardware. Since then, I’ve tried to think of the perfect response, the counter argument that would have everyone nodding their heads in agreement and screaming “Agile wins!”. Alas, I regret to inform you that Mike and the rest of the agile heretics out there have won. There is no perfect response because agile will never work in hardware. So instead of confronting Mike’s argument, I’m here to pile on. I hope I can help others who, like me, were deluded into thinking agile could work in hardware. Continue reading
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