It’s tuesday… maybe a little early yet… but I hope you’re checking your mailbox. If you’ve been an active member or enabler in the agile hardware community, you should soon have your commemorative 1710 day anniversary AgileSoC sticker.
Step 2… if you’ve got it in you to send me a selfy of you and your sticker, I’d love to be able to post a few of those as inspiration for others to join our little community. You can either email it to me at firstname.lastname@example.org or tweet it to @nosnhojn.
Thanks again, all!
Update: Here’s a few shots of people taking credit for agile hardware. Love it! Keep’em coming!
If you’ve been watching the clock since Bryan first brought up the idea of agile hardware with me back during SNUG 2009, you’ll know that we’ve been working on AgileSoC.com for exactly 1710 days. That’s March 15th, 2009 to today.
To commemorate the 1710 day anniversary of AgileSoC.com, I figured something special was in order. Specifically, something special to recognize the people that have helped fuel this little experiment; those who have helped turn very little into a little more. Continue reading
I’ve come to a checkpoint in the construction of the AMBA IP library that’s packaged with MiniTB. After some part-time development over the last couple months, I have read/write support for ABP and basic read/write support for AHB (you can see the full list of supported features here). These are open-source masters and slaves that I developed using MiniTB.
Next step is AXI, which I’ll start later today. But before I go there, I wanted to share some lessons learned… Continue reading
Last week I posted an initial version APB master. This week is an updated APB and an initial AHB master. These are open-source verilog BFMs packaged and ready for use in MiniTB, an open-source responsible development platform. Continue reading
Today, I released a first version APB master BFM with MiniTB. This is the first in a few steps I’m hoping we take in the development of MiniTB. I’d like to provide a user-friendly platform for developers building SoCs with AMBA interconnect. APB was the simplest place to get started. Depending on interest, we’d move on to AHB and/or AXI IP as well. Continue reading
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