Verilab’s award-winning paper entitled “Using the New Features in VMM 1.1 for Multi-Stream Scenarios” is now available for download from the Verilab website. Please let us know if you have any questions!
Verilab have added their OCP uVC verification component to the OCP-IP Library.
The Verilab OCP uVC is a mixed language verification component for the Open Core Protocol (OCP) implemented using SystemVerilog and e verification languages. It can be used as an Open Verification Methodology (OVM) Verification Component (OVC) in SystemVerilog-only applications without the Specman layer (or license), or it can be used in Specman-based verification environments as a regular e Verification Component (eVC).
The datasheet for the OCP uVC can be downloaded here
Mark Litterick’s “Architecting the OCP uVC verification component” article written about in a previous blog has also been picked up by EDA Designline
Mark Litterick’s OCP-IP December 2008 newsletter article demonstrates how two key aspects of OCP – profiles and transactions — were adopted as fundamental building blocks for the architecture of a verification component targeted at constrained-random validation of OCP components and systems.
The article uses the Verilab OCP uVC as an example. This uVC is a mixed-language OCP compliant verification component that supports a major subset of Open Core Protocol Specification 2.2. The OCP uVC is implemented using SystemVerilog and e verification languages and complies with both the Open Verification Methodology (OVM) and e Reuse Methodology (eRM). The verification component can be used in SystemVerilog only applications without the Specman layer (or license), or it can be used in Specman-based verification environments as a regular eVC.
The OCP-IP article can be downloaded here
The full whitepaper can be downloaded here
Just a quick FYI… both David Robinson and I have posted our DAC presentations on Verification Planning and SystemVerilog Interoperability on the Verilab website. Please check them out and let us know if you have any questions or comments!
There was a recent surge of discussions about asynchronous clock domain crossings and metastability handling in Verilab email: Two people asked Mark Litterick essentially the same question just hours apart, and then a day later Jason Sprott noticed a Mentor CDC Verification paper that referenced Mark’s “Pragmatic Simulation-Based Verification of Clock Domain Crossing Signals and Jitter using SystemVerilog Assertions,” paper (Best Paper at DVCon 2006).
One particular statement in the Mentor paper caught my eye: "this model can still generate false errors: the waveforms show that input sequence A, B, C, D, E, F can result in output sequence A, B, E, E, E, where two consecutive inputs, C and D, are skipped". And this statement bothered me: I had spent a long time figuring out Mark’s model some while back, and while it was not at all intuitive to me, I did convince myself that it could never generate a simulated output sequence that was impossible in real hardware. So if the Mentor paper was correct, then I had missed something about Mark’s model, and I’ll be honest, I didn’t relish going back and studying it again.
Obviously I was just going to have to find a mistake in the Mentor paper instead. And to my considerable relief, I did. In fact, I found two:
SystemVerilog has two “similar” data types that allow variables to be grouped together in a handy package: the struct and the class. I’ve heard it often said, when explaining what a class (an object-oriented data type) is, that it is just like a C struct with functions. I used to have no problem with that, until, when reviewing and debugging testbench code, I started seeing some problems related to the way classes have to be treated differently to structs. One of the most common errors I’ve found is when data structures composed of classes are copied.
Consider the following: Read the rest of this entry »
I was having lunch with JL awhile ago, and we were talking about some recent Verilab email threads.
Participation in email threads is fairly high at Verilab: If you ask a question, you’re pretty likely to get an answer. Or three.
But even though participation is the norm, there is no guarantee that you’ll get an answer. There’s no guarantee that the person with the most useful knowledge will chime in. Well, these aren’t novel concerns, and there are tools to address them: Bug trackers. I’m rather a fan of bug trackers, and I think they could be used far more widely than is typical. And foolishly, I promised JL I’d write a blog on the subject.
So I started to organize my thoughts: My central themes would be the interface and the data model. I would argue that the bug tracker data model is far superior, but the interface is often far too cumbersome.
A bug tracker keeps state (and state history) and responsibility metadata. A bug tracker manages a to-do list, and if it weren’t a useful data model, then to-do lists would have gone extinct; and that ain’t happening.
Any communication that desires a response is actually an addition to someone’s to-do list: “Please respond”. And the vast majority of communications do desire responses: “Please book me on a flight to Aruba”; “What’s the Emacs keystroke for …?”; “I’m going to see the new movie on Friday at 8, wanna come?”.
Why not use a bug tracker for all of them?
Read the rest of this entry »
Folks interested in DFT would do well to head over to DFT Digest. In his latest post, John Ford ponders about the potential for hackers to learn information about the inner workings of a device via a side channel attack using scan chains. The topic reminds me of a presentation I attended at this year’s DATE conference in Nice. The presenter was discussing security issues and described how she wrapped her passport in aluminum foil to prevent would-be hackers from scanning info out of the embedded RFID chip.
Separately, John is compiling a list of DFT related links. If you’ve got some good ones to share head on over to his DFT Bookcase and or his DFT Forum and let him know!
SVUG started in March 2007 and has had a total of 8 meetings so far. It’s been a great first year for all of us involved with SVUG. The meetings and forum have been met with real enthusiasm. We’ve had some interesting technical discussions with new and experienced developers using SystemVerilog on their projects. We had some great presentations and tutorials, including me banging on about functional coverage, and Verilab’s Mark Litterick presenting some cool Assertion Based Verification techniques. We even managed to get some users to share their own tips and tricks, including our very own JL Gray.
I just got the stats for the fall 2007 meetings. 480 registered in total, 280 attended. Of the people surveyed (nearly everyone that attended the 5 meetings), 60% were using SystemVerilog today. Verification did pretty well out of that, with 67% of the share. Design got 10% and 23% said they used SystemVerilog for both design and verification. From a verification point of view another interesting stat was that 33% of the verification slice, were using the advanced testbench features of the language, and 32% were using SVA. It’s nice to see that more people are starting to use the HVL portion of the language for verification, not just writing assertions. I think this is due in no small to much better tool support and stability by all the vendors.
The growing attendance numbers of the SVUG meetings is a reflection of the interest and uptake of SystemVerilog by the design/verification community. I’m seeing an increase in our client projects using SystemVerilog Verification IP, and finding ways to hook SystemVerilog into their verification environments. Finally, it’s really beginning to feel like SystemVerilog is starting to make a bit of an impact.
