After some of our own analysis, it’s time to turn the conversation over to you! Here are all the data from our 2012 hardware project planning survey.
To quickly rehash what you’re looking at, this survey was conducted by Catherine Louis and I last year. The intention was to get a feel for how successful hardware teams have been with their current approaches to project planning. As you’ll see, we had people respond from all areas of hardware development from all levels. We’ve found the results to be quite interesting.
If you want a little more background, Planning to Fail in Hardware Development is a good place to start. In there you’ll find a link to our initial analysis posted on eetimes. Other articles we’ve posted since:
But enough talk from me. Since you’re here to see data, here it is!
-neil Continue reading
If you need a good way to waste 36% or your day, debugging code is your best bet!
That’s what I figured Thursday while listening to Harry Foster’s analysis of the 2012 Wilson Research Group Functional Verification Survey commissioned by Mentor Graphics. The survey is meant to show design and functional verification trends from hardware development. It’s well done and well presented by Harry.
Here’s the scene: you’re a hardware engineer at a conference sitting in on a talk about functional coverage. You’re there because you think functional coverage is important. You think you do a good job of building functional coverage groups but the title of the talk suggests otherwise. The speaker takes the stage… Continue reading
Verifying error conditions and UVM testbench checkers just got easier! The SVUnit UVM report mock lets you automate testing of UVM errors and fatals to increase confidence that the checkers in your testbench are defect free. The SVUnit UVM report mock is a scoreboard style checker where actual and expected errors are logged and compared to trigger a PASS/FAIL result.
Here’s how it works… Continue reading
Posted in TDD
Tagged svunit, UVM
I’ve had a lot of reading and commenting on my last post Time to Blow Up UVM. Now I’m looking for an anonymous show of hands to see if I’m on the mark or completely out to lunch regarding UVM.
Just as it seems the verification community has converged on a methodology – a universal methodology as it were – that finally meets the needs of EDA vendors, IP providers and users, along comes somebody to suggest we should blow things up entirely and start again.
‘Somebody’ is me.
Here goes. Continue reading
Thus far, we’ve seen numbers related to confidence in project planning and our failure to produce accurate project estimates. In this post, we’ll see that failing to meet project delivery dates doesn’t come from lack of effort, though we will see another sign that we’re indeed setting ourselves up for failure. Here’s three new data points from our project planning survey related to long hours, mounting stress and aggressive goal setting. Continue reading
Estimating effort is something we collectively struggle with in hardware development considering building the project plan is an exercise that everyone is involved in. Here’s the next few data points from our project planning survey that may have you wondering why we’re so wrong when it comes to estimating and project planning. Continue reading
We’ve had our first brave sole step up and offer his opinion based on data from our project planning survey! Our guest contributor is Gaurav Jalan, a design verification engineer with services firm SmartPlay in Bangalore. Gaurav, who runs his own blog focused on hardware verification, offers his opinion on variance in project plans.
Take it away Gaurav! Continue reading
We interrupt your regularly scheduled programming to bring you this short email back-and-forth I had with Aart de Geus last year during SNUG (Aart is co-CEO of Synopsys for anyone not familiar with the name). It happened just after his keynote where he spoke about something he called systemic collaboration. I remember it being quite interesting and thinking that in people terms, systemic collaboration seemed synonymous with cross-functional teams, a key characteristic in agile development. I asked the question in that direction… he was kind enough to respond. I’d be interested to hear what people think. Continue reading