Whether or not Systemverilog/IUS is ready for YOUR team, depends on your situation. Is management willing to invest the time & money to train the team to a competent level? Are you comfortable with doing a little of your own detective-work, to track down bugs and develop workarounds for your testbench (I’m sure you’ll need to do this from time to time)? Are you comfortable with Cadence’s application engineering support? Is your project nearing completion, with some looming deadline coming up, or is it still in the planning stages, with schedule flexibility? etc.
I had the (time) luxury to use my project’s “schedule slack” to investigate OVM (and by extension, Systemverilog.) I was/am the only full-time Systemverilog (SV) guy on my team, and I found it SV’s verification features, despite syntactical similarities with Verilog, were fundamentally different (in concept and semantics.) People with past E/VERA backgrounds are already familiar with transaction-level concepts and general programming abstraction, but hardware engineers tend to fight these all the way. (My coworkers still thing a variable-name “CSN” is preferable to ‘ChipSelect_’!) Therefore, I chose to start with a standalone testbench (without OVM), to get up to speed with the language.
Although I haven’t yet had a chance to really dig into OVM, I did learn quite a lot from architecting a standalone (non-OVM) block-level testbench project. Among the IUS (6.2s004) idiosyncracies that I’ve come across: no support for union; enum-declarations must be literals, can’t define them as (compile-time) constant expressions, const only partially implemented, Simvision’s source-code browser doesn’t ‘auto-expand’ variable-`define macros … I need Novas Verdi for that, IUS $cast operator is not as powerful as Questasim’s – can’t use it to spot-check a typecast-to-enum variable, etc.)
Despite that, I didn’t encounter a major showstopper. It’s fair to say I spent more of my time conquering my inexperience (in SV semantics and methodology), than dealing with tool-based issues. On the plus side, dealing with those ‘issues’ actually turned out to be a good mental-exercise! (…how to implement a ‘concept’ using 2 different language methods.)
Overall, I feel IUS’s Systemverilog is production-ready for ‘major development’ (example: transaction-level testbench for complex SoC ASIC.) The support engineers have workarounds for the tool’s shortcomings (which aren’t showstopping, compared to last year’s IUS 5.83.) With OVM on Cadence’s official roadmap, there’s a coherent, organizational commitment to solidifying SV support to a common-baseline (rather than just adding new language features in random combos, seemingly at random.)