Hi,
As a graduate student with interest in Verification career, which is a good methodology to start a job in - a team that uses UVM or a team that uses Specman? Does this matter at all? What are the pros and cons of each? There has been a lot of talk about UVM and a lot of focus on it with many job profiles requiring UVM knowledge. On the other side, there are roles that doesn’t bother about UVM and are rather happy to have no UVM exposure as their team uses Specman.
As a grad student currently applying for job openings, does this difference in methodology matter? Is UVM something that would put you above the pack and offer you a better professional future with time? Should I be focusing on learning Specman as well? How would starting a career with Specman be different as compared to starting a career in UVM?
Can I please get suggestions from the industry experts?
Thanks
In reply to s.melvin26:
Don’t expect to get a neutral answer your question on this UVM forum. But I can point you to some data where you can draw your own conclusions.
In reply to s.melvin26:
What you should have in mind Specman/e is quite an old approach, starting in 1996. At that time it was a revolutionary idea to verify HW by SW, but it was the first solution with a lot of disadvantages fixed overtime. And Specman is a solution supported only by 1 company: Cadence.
If you want to be independent from EDA companies it is an easy decision to start with UVM. If your employer has tons of e legacy code the decision is not easy.
Another point. e is an aspect-oriented language. This allows you to do very specific and tricky things. The function of the code depends on the compilation order. In contrast SV is an object-oriented language. Anything is well-ordered. This makes working in big teams more easy.