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?
Blog Doing Math in FPGAs Tom Burke 18 comments For a recent project, I explored doing "real" (that is, non-integer) math on a Spartan 3 FPGA. FPGAs, by their nature, do integer math. That is, there's no floating-point ...