This is JL Gray's Typepad Profile.
Join Typepad and start following JL Gray's activity
Join Now!
Already a member? Sign In
JL Gray
Recent Activity
Hi Vivek, I agree that a language that natively includes UVM methodology constructs would be quite beneficial. Of course, there is probably at least one vendor that would say there is such a language already :). One thing I've been considering recently is whether the future of verification might lie in a language like Ruby or Python adapted for use as a verification language. There are already libraries available such as PyHVL to facilitate this. But much functionality is still missing. I also believe the recently created Accellera multi-language technical subcommittee could allow for additional innovation in EDA while enabling use of many different types of languages and methodologies in the same simulation. Thanks for your comment! JL
1 reply
Hi Kevin, Just to be clear, though - an actual monitor is needed somewhere. If you are driving your checking directly from your stimulus you are often taking a shortcut in my view. That doesn't mean you have to include any internal blocks in your checking, though if you've already written those checks at the block level why not reuse them? If you base your checks off of what is stimulated vs. what was actually seen on (say) the USB interface itself, you may not realize something is wrong. This is especially true with functional coverage. Coverage based on your stimulus makes the assumption that there are no bugs in the driver, and that the actual generated stimulus makes it to the DUT in the first place. I have seen testbenches where coverage being reported was totally bogus because the transactions in question were never being driven on the physical interface! JL
Toggle Commented Feb 8, 2013 on UVM Drivers and Monitors at Cool Verification
1 reply
Hi Kevin, I think there is a disconnect here. I'm saying that when building a driver for an interface, one should always build a corresponding monitor. You appear to be saying that when doing end-to-end checking you should do the checking at a higher level than the pin-interface. I agree with that. High level end-to-end checking is separate from implementation decisions made when building a bus agent. Embedded scoreboards, if available, are critical to making it easier to debug complex designs. I've often used both approaches simultaneously - an end-to-end scoreboard with internal block-level or cluster-level scoreboards to help discover bugs when the happen. That's much easier than trying to trace through a massive SoC to find out why the data you sent in via PCIe didn't come out via USB (for example). I almost always abstract away the interface (AMBA, PCIe, OCP, etc) from the higher level checking. For example, if you use the UVM register package, you would access your dut via register reads and writes. And any monitor I would use would update a shadow register model, allowing me to see the state of the DUT regardless of what physical interface was used to collect that state. So, are we actually in violent agreement here or is there something I'm still missing from your argument? Take care, JL
Toggle Commented Feb 6, 2013 on UVM Drivers and Monitors at Cool Verification
1 reply
Hi Kevin, Thanks for the comment. When I've worked on systems (PCI-e, FBDIMM, 10 Gig Ethernet for example) that have PHYs, we often bypassed the PHY for many of our functional sims just to make sure the basics were working correctly. That also tends to help with simulation performance. But regardless, we did want to know that data written on the host side of the PCIe block made it correctly out to the internal DUT side (AMBA, Avalon MM, OCP, etc) and vice versa. I'm confused as to why I wouldn't want to use a monitor to watch the data move from one side of the device to the other? Even if the phy were present, I could still extract the higher level data from the stream of bits and do the high level comparison. By the way, the last person to tell me a monitor wasn't needed on a SERDES interface because we were just going to do end-to-end checking was proven terribly wrong some months later when it turned out the data path + SERDES were impossible to debug without just such a monitor! Can you give me a bit more background on your concern about the approach I'm recommending? Perhaps I'm rooted in a different reality than you are. ;) Take care, JL
Toggle Commented Feb 5, 2013 on UVM Drivers and Monitors at Cool Verification
1 reply
:)
1 reply
Hi Abdelhak, You can build a SystemVerilog/UVM testbench around any Verilog module. The trick is knowing what, exactly, the testbench is supposed to do. So verifying a Verilog module against cryptographic attacks would require a deep knowledge of cryptography and the algorithm you are trying to verify. The UVM would just give you the tools to build the testbench framework. Take care, JL
Toggle Commented Jan 11, 2013 on UVM Drivers and Monitors at Cool Verification
1 reply
Hi Guarav, Thanks for sharing the link to your earlier post. You're right - It can be useful if you're using a new type of interface and can work with a vendor as an early adopter. Of course, if you're using a well-established interface, that might be less useful unless you are certain you'll be receiving high quality support from the vendor in question. JL
Toggle Commented Sep 29, 2012 on Characteristics of Quality VIP at Cool Verification
1 reply
Hi Neel, I suppose that's possible. But I think this is more of a personal methodology issue than library related... Some people are just inherently lazy ;). JL
Toggle Commented May 8, 2012 on UVM Drivers and Monitors at Cool Verification
1 reply
Hi Gaurav, Just so we're clear... this post is dripping with sarcasm... So it sounds like perhaps we are in complete disagreement? :) JL
1 reply
Um... I know ;). I didn't know you could directly access the functionality via keyboard shortcuts, though. Thanks for the link!
Toggle Commented Feb 25, 2012 on Screen Shots on the Mac at Cool Verification
1 reply
Actually, Richard, I disagree to some extent. C++ is a *terrible* language for verification. I used SystemC + SCV back in 2004, and it was a mind numbing experience, to say the least. A huge problem with a language like C++ with a library on top is that when you want to debug something, you end up having to debug through all of the library code. I think this would be less of an issue with a more modern language like Python or Ruby. And if I had to build something from scratch I might start there. But there is something to be said for a domain-specific language that has built-in constructs to match the problem you're trying to solve. JL
1 reply
Hi Jason. Agreed! JL
1 reply
You had me until you said "I'm starting to like SystemC too". Are you crazy?! :-). JL
1 reply
So, "dependence on the tool chain prevents any kind of meaningful open source sharing of powerful libraries". But ... "the largest issue addressed in your post is one of training". So which is it? I can tell you that people I know and respect who are sufficiently trained in SystemVerilog still find the language infuriating. And people who aren't trained sometimes think they actually know what they are doing, which makes things worse! Side note: you say companies "need to invest in training rather than consulting". But they should get training through "consultants and tool vendors". What's wrong with consultants? :-). JL
1 reply
It's interesting to note that EDA vendors (mostly) don't actually use the tools they build. Whereas the folks developing Microsoft Visual Studio or Eclipse probably use those tools on a daily basis. So they are actually developing tools for themselves, and also sell them to others! JL
1 reply
Hi Ankit, As I said in my post, I think it is incumbent on semiconductor companies themselves to drive innovation for exactly the reason you describe in your comment. There are still a very large number of teams who have *not* adopted SystemVerilog for verification. JL
1 reply
Sorry, Stardust. I know it's fun to pull the whole "e vs. SystemVerilog" thing whenever a discussion about the deficiencies of SystemVerilog comes up. But to do so is to miss the point *entirely*. Notice e was never mentioned in my post. I've worked on well over a dozen projects in the last decade, using e, SystemVerilog, SystemC, and C++. And if I include my Verilab colleagues, we've probably seen a combined total of at least 200 projects. I've seen what it takes to ramp up teams on how to properly do verification, and I've seen it *repeatedly*. My comments are based on this experience. If your experience differs, I'd love to hear more about your thoughts. But please folks, lay off the e vs. SV debate! JL
1 reply
Bryan, I just sent you an email. Let me know if you do not receive it at "jl at coolverification dot com" or "jl dot gray at verilab dot com" JL
1 reply
Hi Bryan, It's hard to say "what a small verification team" at a "small company" should do. It is highly dependent on the software skills of the people involved. If you don't have any ideas to the contrary, you should probably just stick with what you know (or what you could know based on training offered). Of course, I'd be happy to discuss in more detail offline if you like. JL
1 reply
Sean, To be honest, I'm not too worried about it. I think people will understand if links to events that occurred in the distant past no longer work. However, it would be useful if DAC took this into account and kept around a historical archive with working permalinks. JL
1 reply
You can "get_message()" and then "set_message()" from within the catcher. Check out the UVM Reference Guide for details. JL
Toggle Commented May 21, 2010 on UVM-EA Release Details at Cool Verification
1 reply
Dusty, For performance, instead of this: uvm_report_info("MYINFO1", $sformatf("val: %0d", val), OVM_LOW); Always use this macro: `uvm_info("MYINFO1", $sformatf("val: %0d", val), OVM_LOW) The macro will not allow the $sformatf statement to be evaluated unless the message is going to be printed based on a check of the verbosity. There are several permutations of messaging macros for the various message types. And this info applies to the OVM as well as the UVM. JL
Toggle Commented May 21, 2010 on UVM-EA Release Details at Cool Verification
1 reply
No problem, Dennis. JL
1 reply
Good question. I can't name a single other journalist who wrote for SCDSource. And I can't recall having been impressed by any article I read on the site after Goering. And I didn't read many of the articles. It's entirely possible I wasn't paying close enough attention or I was just noticing engineer-contributed content. Also, perhaps there wasn't much in the area of pre-silicon verification. JL
1 reply
Interesting. Of course, there hasn't been anything worth reading on SCDSource since Goering left, so I can't say the site will be missed. JL
1 reply