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.
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.
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
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?
Replay available now: A handful of emerging network technologies are competing to be the preferred wide-area connection for the Internet of Things. All claim lower costs and power use than cellular but none have wide deployment yet. Listen in as proponents of leading contenders make their case to be the metro or national IoT network of the future. Rick Merritt, EE Times Silicon Valley Bureau Chief, moderators this discussion. Join in and ask his guests questions.