Remember when software development went thru a similar phase change? The book "The Mythical Man Month" seemed to clearly define the issues. Maybe we need a new "Surgical Team" approach to verification along similar lines. Anyone have a good team structure that can help in the verification space?
Many of the lessons in "The Mythical Man-Month" apply to verification teams as well as coding teams. Projects that simply throw more bodies at the problem rather than taking advantage of new technology such as TrekSoC may indeed run into the issues outlined in the classic book. The best solution is increased automation to make the existing team more effective even on larger and more complex chips rather than growing the team in an unbounded fashion.
Tom Anderson, Breker Verification Systems
Hmmm. I am not sure it is just about automation. Constrained random adds automation, but at the SoC level it may be inappropriate automation and thus it too can start to add to the problem. Automation only helps if it drives you in the right direction.
I agree with you 100%. As Adnan says in the original article, UVM and constrained random break down at the full-chip level. At that point, the recommended automation is via TrekSoC and its self-verifying C test cases. This is truly automation in the right direction.
NASA's Orion Flight Software Production Systems Manager Darrel G. Raines joins Planet Analog Editor Steve Taranovich and Embedded.com Editor Max Maxfield to talk about embedded flight software used in Orion Spacecraft, part of NASA's Mars mission. Live radio show and live chat. Get your questions ready.
Brought to you by