Be afraid, be very afraid
Be afraid, be very afraid
For Halloween this year I’ll be blogging a real horror story. And when I say “real”, I mean real – everything you are about to read is the truth. Not some Spielberg made up scary stuff. Knowing that it’s real makes it just a bit scarier. I’ve obfuscated some details to protect the identity of both the innocent and the guilty.
It all started some months ago, I was getting off a train in a European capital city and stepping into a thick swirling fog. It was close to midnight. As I crossed the station platform I heard an owl hoot and fly away. Climbing into a taxi, off in the distance, I could hear a wolf’s lonely howl – or could it be a werewolf? A shiver ran down my spine as I knew that I would be rising early in the morning to attend a post mortem. (Cue that creepy music from “The Exorcist”).
Well, not a real “dead body” post mortem, but I was asked to sit in on a review of a project; a project which was quite definitely dead. Racked with delays, cost overruns, and lots of blame the project did not have a happy life. I had been involved in the project from close to its outset, and even early on I could see that it was destined for trouble. Needless to say, the corpse was not a pretty sight, and this meeting was not going to be a fun one.
The project had two major elements. But the project teams working on the different elements were not coordinated. They did not work together at all – in fact, they rarely communicated. They started off by writing a specification of how the two sides would interface. The specification was incomplete. It contained errors, and was out of date by the time it was published. As the project progressed, no one ever went back to update it – of course, this is inexcusable after the invention of the wiki. But that wasn’t all that bad, since few people read the spec. And fewer still even expected it would be complete or accurate.
Upper management decided not to co-locate these engineering organizations. While both engineering groups had some contributors in far flung corners of the world, the bulk of one group was in a city in the U.S. and the locus of the other was in Europe. There were many hours of time zone changes and cultural differences between the two. The two groups did not even start on the project at the same time, one started a full 8 months after the other.
After many staff years of effort on the part of both groups – literally, a multi-million dollar/euro investment by the parent company – the momentous day came where the two parts of the system were brought together to form the whole. The upper management of the project was shocked – shocked I tell you – that the whole thing did not come together and work the first time. Shocked that there would be months more development and verification effort before the product could be released.
Here’s where the delays and blame started to pile up. Both sides accused the other of gross failures. Functionality was thrown overboard, as there were features that simply could not be implemented without redesigning major parts of the system. The delays piled up. Promised delivery dates came and went. The marketeers saw their precious market window closing on them. Everyone wanted someone to blame. Smart folks were moving onto other projects.
A Horror story, no doubt. You may be wondering how a competent engineering organization could execute so poorly. Surely your own organization would never do anything like this. But there is one small detail I left out.
One group was designing software and the other was designing hardware.
Yes, lots of systems are still designed this way. And I hear you saying “Well, that’s just software”. Sure, software is more malleable (at least in theory). It’s layered, so you only need to worry about the layer that touches hardware, right? If you prove that A works with B, and B works with C, no need to verify that A, B and C all work and play well together, right? And, my favorite “That’s the software guy’s problem”. As a hardware developer, you were charged with developing the hardware – and you did it. If software team can’t get their job done, well, that’s not your issue. I’m guessing those shocked upper management types would beg to differ.
In my next blog post I’ll describe why you might want to worry about this, if you’re not already. There is functionality which is starting to break the traditional boundaries between hardware and software. I’ll describe it, and what you can do about it.
More Blog Posts
- Part 1: The 2012 Wilson Research Group Functional Verification Study
- Those nasty wire’s and reg’s in Verilog
- Getting AMP’ed Up on the IEEE Low-Power Standard
- Prologue: The 2012 Wilson Research Group Functional Verification Study
- Even More UVM Debug in Questa 10.2
- IEEE Approves New Low Power Standard
- Verification Horizons DVCon Issue Now Available
- Get your IEEE 1800-2012 SystemVerilog LRM at no charge
- IEEE 1800™-2012 SystemVerilog Standard Is Published
- See You at DVCon 2013!
- May, 2013
- April, 2013
- March, 2013
- February, 2013
- January, 2013
- December, 2012
- November, 2012
- October, 2012
- July, 2012
- June, 2012
- May, 2012
- March, 2012
- February, 2012
- January, 2012
- December, 2011
- November, 2011
- October, 2011
- September, 2011
- July, 2011
- June, 2011
- Intelligent Testbench Automation Delivers 10X to 100X Faster Functional Verification
- Part 9: The 2010 Wilson Research Group Functional Verification Study
- Verification Horizons DAC Issue Now Available Online
- Accellera & OSCI Unite
- The IEEE's Most Popular EDA Standards
- UVM Register Kit Available for OVM 2.1.2
- May, 2011
- April, 2011
- User-2-User’s Functional Verification Track
- Part 7: The 2010 Wilson Research Group Functional Verification Study
- Part 6: The 2010 Wilson Research Group Functional Verification Study
- SystemC Day 2011 Videos Available Now
- Part 5: The 2010 Wilson Research Group Functional Verification Study
- Part 4: The 2010 Wilson Research Group Functional Verification Study
- Part 3: The 2010 Wilson Research Group Functional Verification Study
- March, 2011
- February, 2011
- January, 2011
- December, 2010
- October, 2010
- September, 2010
- August, 2010
- July, 2010
- June, 2010
- The reports of OVM’s death are greatly exaggerated (with apologies to Mark Twain)
- New Verification Academy Advanced OVM (&UVM) Module
- The Dog That Didn’t Bark
- DAC: Day 1; An Ode to an Old Friend
- UVM: Joint Statement Issued by Mentor, Cadence & Synopsys
- Static Verification
- OVM/UVM at DAC 2010
- DAC Panel: Bridging Pre-Silicon Verification and Post-Silicon Validation
- Accellera’s DAC Breakfast & Panel Discussion
- May, 2010
- Easier UVM Testbench Construction – UVM Sequence Layering
- North American SystemC User Group (NASCUG) Meeting at DAC
- An Extension to UVM: The UVM Container
- UVM Register Package 2.0 Available for Download
- Accellera’s OVM: Omnimodus Verification Methodology
- High-Level Design Validation and Test (HLDVT) 2010
- New OVM Sequence Layering Package – For Easier Tests
- OVM 2.0 Register Package Released
- OVM Extensions for Testbench Reuse
- April, 2010
- SystemC Day Videos from DVCon Available Now
- On Committees and Motivations
- The Final Signatures (the meeting during the meeting)
- UVM Adoption: Go Native-UVM or use OVM Compatibility Kit?
- UVM-EA (Early Adopter) Starter Kit Available for Download
- Accellera Adopts OVM 2.1.1 for its Universal Verification Methodology (UVM)
- March, 2010
- February, 2010
- January, 2010
- December, 2009
- A Cliffhanger ABV Seminar, Jan 19, Santa Clara, CA
- Truth in Labelling: VMM2.0
- IEEE Std. 1800™-2009 (SystemVerilog) Ready for Purchase & Download
- December Verification Horizons Issue Out
- Evolution is a tinkerer
- It Is Better to Give than It Is to Receive
- Zombie Alert! (Can the CEDA DTC “User Voice” Be Heard When They Won’t Let You Listen)
- DVCon is Just Around the Corner
- The “Standards Corner” Becomes a Blog
- I Am Honored to Honor
- IEEE Standards Association Awards Ceremony
- ABV and people from Missouri...
- Time hogs, blogs, and evolving underdogs...
- Full House – and this is no gamble!
- Welcome to the Verification Horizons Blog!
- November, 2009
- October, 2009
- September, 2009
- August, 2009
- July, 2009
- May, 2009
RT @learningloving: SystemVerilog -- getting the effect of generated case items. http://t.co/rqrHv74JEr about 11 hours ago
#IEEE Celebrates Ethernet's 40th Anniversary and Life-Changing Technologies that IEEE 802.3(TM) standards help enable http://t.co/DTOcqUZaQN 10:17 PM May 21
Happy 40th Anniversary to Ethernet. It is now May 22nd in Korea, so I can get a jump on the celebration! Here is what Ethernet's... 7:42 PM May 21