I am working on UPF these days (SW side, not on verification side). UPF is not exactly a new language, but it is build upon TCL language. So one need a TCL interpreter in SW side to parse and analyze it.
The biggest roadblock/pain I see (with my 5-6 year experience in verification industry) is that there are N numbers of verification language/methodologies (SV, vera, eRM, OVM, VMM, UVM, and what not). But there is a single underlying philosophy/strategy behind almost all of these verification methodology. The difference lies in in which way the promoter of the verification methodology has written the base class for them. There will always be interface, a driver, a monitor, a transactor, channels, protocol packets in all of these methodology (The name might change from one methodology to another).
So a verification engineer has to learn a new methodology, translate his verification intent to the suitable class structure as specified by the verification methodology, compile the code along with the base class, and then run the simulation. I feel that the translation of verification intent in a "pre-defined" way so that it get conformed to a XYM standard is an extra effort, which should be get rid off.
Now consider the case where you have written your TB in OVM, and found that one of the essential verification component, that is freely available to is written in OVM. Agreed that you can you some converter class to bind these two with a great amount of pain; but the question is why not think of a way to get rid of the pain.
See the main page of http://www.testbench.in/. There are 5 easy labs, for verifying the same HW.
Here is what I think should be one way to get rid of SV/XMM, and make any verification environment compatible with each other.
What if we specify our verification intent in some UPF like fashion, and there is a tool which can convert it to OVM/UVM/AVM/eRM, or can compile it natively.
Now consider the code present at http://www.testbench.in/UL_04_PHASE_1_TOP.html
Why not have a language where the verification engineer can specify it as
create_interface mem_interface \
-setup_time 5ns \
-hold_time 3 ns \
-signal {{mem_date 7 0} {mem_addr 7 0} {mem_en} {mem_rd_wr} }
-clocking clocking_xyz
create_packet fcs_pkt \
-fields {{length byte} {da byte} {sa 127 0}}
add_constraint constraint_1 \
-packet fcs_pkt \
-condition { byte < 10} \
-condition { sa != 0 }
Now this is providing verification intent in a crisp/language/methodology independent manner. Tools can be written which can then convert these to required methodology, and make life easier for verification engineer.
knock, knock ... Is anyone leading major verification efforts listening !!!
