the IP providers have to encrypt their code to protect their assets. So even if the code is written in the same language as the user's test environment they are still going to have issues trying to debug their VIP integration if they have no visibility into the VIP.
the language the VIP is written in should be of no concern to the end user as long as the performance and integration API is well defined.
Dhruba, This is why we introduced UVM Connect today. It bridges SystemVerilog UVM with SystemC (& C/C++), but can be easily extended to encompass those legacy languages you need that are not universally supported. You can find more information about UVM Connect on Verification Academy (http://verificationacademy.com/). Let us know what you think. I also blogged about a few other items that is needed for the industry to take some steps forward that includes this at http://blogs.mentor.com/verificationhorizons/blog/2012/02/17/uvm-some-thoughts-before-dvcon/. -Dennis
DKC, SystemVerilog, SystemC, and VHDL fans could say the same thing about their tool covering most of the open platform requirements and are open and how those C++ proponents are perpetuating unnecessary complexity.
I think the problem is somewhat self evident - "C, C++, SystemC, VHDL, Verilog, SystemVerilog, ‘e’, OpenVera, etc", the language landscape is a mess, and largely dysfunctional - whether you are doing design, verification or IP modeling.
Really the methodology needs to be moved onto a common open platform that people can develop the tools on. Fortunately C++ which covers most of it is open, and all you need to do is add the HDL threading model -
But some people like to perpetuate unnecessary complexity and proprietary tools.
PS: Brian - did you see Bjarne Stroustrups's talk about adding units to C++?
One of the most frustrating VIP challenges for SOCs is that quiet often they conflict with each other and the simulation tools. Since the VIP vendors are all competitor (as well with the sim tool vendor) it is impossible to send a failing test case to a vendor without violating an NDA of some sort. I quiet often encounter inter VIP conflict that were both delivered from the same vendor. All this makes the challenge of updating your VIPs for bug fixes (once you have them working) a daunting qualification cycle. There has to be a better agreement between EDA and VIP vendors. There are times that I can truly say that some VIPs produce "negative" work.
I agree with you, appears to be a big void in managing IP, in general. There a lot of issues related to SoC integration, and expecting that 'following the rules / standards" will not solve the problem, and it can be very costly, frustrating ...
I am involved with a SW company that developed a special product to manage IP, and addresses the following issues, pertinent to SoC integration:
1. Managing distributed design teams is a challenge
- Individual designers on multi-site distributed design teams do not see a common consistent view of the design data
- IP distribution is a real problem 8 hour delivery times for large PDK’s is common and often the transfers don’t complete
2.Ensuring consistent IP releases is hard.
- Customers complain of “release paralysis” because the design does not converge
- Automate the process of promoting new IP versions
- Delivering correct IP versions at tape-out can be error-prone
3. Many customers report re-spins due to bad IP versions being included in the final design
4. Design quality and progress is not visible at the SoC top level and subsystem level
Please contact me at email@example.com if you are interested to know more about this product.
I like this article because it points to a bunch of technical solutions (frameworks, languages, etc) that haven't quite worked out as well as intended wrt vip integration. Call me a pessimist, but I don't think stricter adherence to industry standards is going to eventually lead to a solution to vip integration. I say that mainly because that's been the primary focus the last few years for many people and organizations and - as this article points out - it hasn't worked out as well as people hoped.
Just an idea... but a different approach would be to have tighter integration between the people that are doing the development and integration. Base communications on standards (obviously), but when ambiguity, discrepancy and arguments arise - as always, *always* happens no matter how many standards you have and how "clear" they are - forget about applying more rules (i.e. standards). physically bring the people together that are doing the integration and have them figure it out.
For more details about verification IP solutions;Please visit http://verificationip.wordpress.com/2011/05/11/verification-ip-solutions/..
PerfectVIPs provide large portfolio of Verification IP solutions for your complex SOC design verification.
For details,send an email to firstname.lastname@example.org
Blog Doing Math in FPGAs Tom Burke 2 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 ...