uvm-sv vs e

[chenyong]

Hi,

when I'm learning uvm-sv, I was suggested by many people to study e for deeply understanding of uvm-sv. If the uvm-sv derived from e, my question is: why we need to "design" a new "way" instead of using e? is there any de-efficiency for e? what is the advantages for sv to superior to e? thanks

[bhunter1972]

SystemVerilog is not derived from e. Nor is UVM. Their aims are the same, but they are distinct languages.

You may find e to be more pure than the layers that UVM adds upon SystemVerilog. But e only runs on Specman, which is supplied by Cadence. So, you'd be tying yourself to only the one vendor, and it's probable that you may in the future find fewer prospects from it.

[dave_59]

Chenyong,

The UVM is derived from many sources. If you want to learn a language, you learn that language, not any of its predecessors. Unless less you are into academic research, of course. The main advantage SV over e is that it widely supported across many vendors as well as being widely adopted.

If you want to know the academic reason SystemVerilog was developed, you have to go back about 25 years ago back when there were many hardware descriptions languages. Users demanded a single language to build libraries of design IP so that they could re-use and exchange their IP and netlists (it also helped when you needed to exchange engineering resources). About 15 years ago, after Verilog had become dominate language for ASIC design, many languages for testbench development started popping up and once again users demanded a single language so they could re-use and exchange verification IP. The result was SystemVerilog and now the UVM.

[chenyong]

Hi,

maybe I got wrong information from other people, but when I read some tutorials on e, I do found many things similar to UVM-sv. I guess e emerges and popular early than sv, so maybe uvm-sv "borrow" some idea from e?

And from specman user guide, it said it could be supported by the third party tools. So if we don't think the reason of supplier, what is advantages and dis-advantages between uvm-e and uvm-sv? just from academic? thanks

[uwes]

hi,

althrough specman/e has been developed by verisity (later bought by cadence) the language has become a standard (ieee1647) years ago. apart from cadence(specman) the other vendors also supply e-support (just talk to them or watch other eda/verification blogs).

lets go back to the original question - uvm-sv vs uvm-e. basically UVM (U-"V"erification-"M"ethodology) describes an approach howto verify designs efficiently today. and as it is a methodology is should be language/tools independent. what you get with UVM is a set of building blocks and "best known methods" to tackle the big problem of design verification. UVM has been implemented in SV (via the VIPTSC) and an implementation of the same thoughts are avail for e (called "UVM-e"). having the same structure/terminology/methodology between the e-flavour and UVM-SV flavour allows verification engineers to design/handle/develop/understand verification environments using multiple languages.

btw: UVM is based upon RVM/VMM/AVM/eRM/sVM/URM(and its predecessors) and UVM-SV is supported by the three major EDA vendors.

looking at the underlying languages e vs SV you will see that they overlap with their features. while SV attempts to be a generic language for all design+verification (inheriting verilog for design) - e focuses on the verification aspect alone. the "generic" vs "specialized" language discussion is a repeated one which you will see in lots of different areas - all time when people promise a generic language which addresses all problems other folks come up with a DSL (domain specific language) which offers much more effiency in a particular field. looking at the current (out of EDA language) landscape you see new languages almost every day. the main diffs between SV and e are SV supports hardware design and e supports Aspect oriented programming on top of the typical object oriented (which both sv+e support).

to sum up:

- the methodology (UVM) is based upon concepts developed earlier for instance in e(eRM,sVM) or SV(RVM,VMM)

- i think people suggest to study the concepts (HOWTO do things) rather then focusing on a language. once you understand WHY you should be doing things like that you can easily map the concepts to either SV or e

- "SV" vs " e" is a long discussion which comes down to technical differences (design+verification vs verification only, generic language vs DSL leading to diffs in efficiency) AND "what resources can i access?" (do i have access to e/sv resources?....)

regards

/uwe

[chenyong]

thanks.

- i think people suggest to study the concepts (HOWTO do things) rather then focusing on a language. once you understand WHY you should be doing things like that you can easily map the concepts to either SV or e

[dave_59]

Hi,

maybe I got wrong information from other people, but when I read some tutorials on e, I do found many things similar to UVM-sv. I guess e emerges and popular early than sv, so maybe uvm-sv "borrow" some idea from e?

And from specman user guide, it said it could be supported by the third party tools. So if we don't think the reason of supplier, what is advantages and dis-advantages between uvm-e and uvm-sv? just from academic? thanks

You need to distinguish between e the language, and specman the simulator application that compiles e source code. As an application developed by InSpec, later renamed to Verisity, and finally acquired by Cadence, specman links with other simulators using the standard PLI mechanism. Any tool that supports the PLI mechanism can support the use of specman, which Questa does. Mentor's Questa does not support the e language without the Specman application provided by Cadence to compile and execute the e code.

If you are familiar with SystemC, you will also see many familiar things from that library, like the TLM communication interfaces and the reporting mechanisms. In fact many of the same developers worked on both. The register package came from the VMM.

Looking at this information from an academic point of view is fine, but I wouldn't suggest trying to learn the UVM by repeating how things were done in the environments where each feature came from. Some features don't translate very well in terms of efficiency when coming from other languages.

[chenyong]

Hi,

thanks for all of your experts' information for reply. The reason why I post this thread is that when I'm learning UVM, I always confused by some term, functions etc. To fully master the methodology, I hope to get some helpful guides from its original "source". The user guide for UVM seems not enough when I'm using UVM for verifications. thanks.