Jump to content


  • Content Count

  • Joined

  • Last visited

  1. UVM doesn't have to be serious all the time, does it? fyi... we got a new dog to keep us company in the office. His name is uvm. He's a good dog. He does tricks, but he can't jump. www.realityreused.com/support.html -neil
  2. SVUnit v0.1 is now available for teams that value bug prevention in ASIC and FPGA development. SVUnit is an open-source framework for test driven development and unit testing design and verification code written in Systemverilog. Version v0.1 supports systemverilog modules, interfaces and class units. Via its built-in mocking framework, SVUnit also supports unit testing of UVM components. You'll find more on SVUnit and test-driven development in Systemverilog as well as download links to SVUnit v0.1 at: http://www.agilesoc.com/svunit. -neil
  3. I'm trying to disable the info message that's displayed in the phase jumping. I'm doing this: to get rid of this message: without any luck. I suspect there's something simple I've got wrong but don't know what it is. Can someone straighten me out? thanks -neil
  4. Here's some commentary around a UVM Express example I'm building with SVUnit and test-driven development. This post talks about unit testing a monitor, coverage group and coverage agent with the same overall structure described in UVM Express step 2... http://www.agilesoc.com/2012/03/09/uvm-express-step-2-svunit-with-covergroups-and-uvm-agents -neil
  5. I was a vmm expert turned uvm beginner. after seeing people struggle with vmm and knowing uvm is... well... bigger, the barrier I was expecting and indeed found was pure information overload. I don't think there's a better way to put it. uvm is big and overwhelming. imho, uvm on it's own does nothing to encourage focused learning/ramp-up. Not to say you can't have focused learning/ramp-up, just that the library itself doesn't make how to do that immediately apparent. there's also the fact that it includes a lot of optimizations under the hood, global methods/properties and macros (which I assume are the applied lessons learned through use of it's predecessors) which makes it difficult for beginners to trace control and see what's going on. In short, uvm is big, powerful and hard to understand. to uvm express now... I think this is great for beginners. It suggests a ramp up path and starts from a very basic point (an interface bfm). It also suggests a way to focus on some pieces while temporarily disregarding others (look at functional coverage and leave random stimulus and sequences to later). I also think this is great for *experts* even though it seems mentor is suggesting otherwise. I think uvm express is a good mentoring tool for experts that could help close the gap between novice and expert verifiers. imho it also provides a better way to communicate and share code with designers (going back to the interface bfm again). of course it's also an idea which means you could apply it to any other library or use it with any other toolset - ideas are so much more portable than code - so anyone can apply it. I'd now consider myself intermediate because I've used uvm a bit and spent several hours getting to know the phasing and component control. I also already knew about tlm so the communications mechanisms were familiar. I'm to the point where I can figure out new features/components as I need them. Starting again though, I'd seriously consider the route suggested in uvm express. I think it'll improve uvm from an accessibility standpoint and I hope there's other ideas like this in the pipe. ...or maybe there already are other ideas out there that I'm missing?? -neil
  6. Here's a few of my thoughts on UVM Express that Mentor announced last week and how I think it could work very well for teams that are interested in doing incremental development. http://www.agilesoc.com/2012/02/24/why-i-like-uvm-express/ -neil
  7. ejessen, there's an option for an open source sv unit test framework as well called SVUnit which you can find at www.agilesoc.com/svunit. I think the most comparable sw framework would be cpptest if you're familiar with that. I'm in the middle of building a usage model that incorporates uvm into the framework (integrating uvm components was a big hurdle but as of a couple days ago, svunit is uvm component friendly). neil
  8. I have a demo video and a short article explaining how I use multiple uvm domains within the SVUnit test framework to verify components before integrating into a larger uvm testbench. You can find the video demo at: http://wp.me/P1GmTc-nB And accompanying article at: http://wp.me/p1GmTc-nx comments and opinions welcome! -neil
  9. Pretty sure that was a stupid question... can't override components after the build.
  10. Is this something I can do at the beginning of each iteration through the run phases? overriding a component with another that has an empty run phase would be just as good as the original sitting idle.
  11. dave, the scenario is a test that goes through a number of restarts. I'm setup to jump back from shut down to reset which is working well. Next is that for a given cycle through the run phases, I'd like to selectively turn off a component. Boiled down, I'd like to go through the common phases for all the components in the testbench, then select which components go through the run phases. The components that are idle don't have their run phase methods invoked. That enough info? thanks -neil
  12. This seems like it should be a simple question... I have a testbench that includes uvm components A and B. With both instantiated, I'd like to be able to control whether or not either/both are actually used in a given test. What would I have to do to have either of those components ignored during at least the runtime phases? -neil
  13. For anyone following along, it's phase jumping that I'm after. Here's an example of a test that will go through the runtime phases twice instead of once. neil --- class test extends uvm_test; `uvm_component_utils(test) bit jump=1; function new(string name = "", uvm_component parent = null); super.new(name, parent); endfunction task post_shutdown_phase(uvm_phase phase); if (jump) begin uvm_phase jph = uvm_pre_reset_phase::get(); phase.jump(jph); end jump = 0; endtask endclass
  14. After a little more digging, I'm guessing that what I'm trying to do is cycle through the runtime reset/config/main/shutdown phases (ie. at the post_shutdown_phase I want to reset to the pre_reset_phase). That make sense? Is that doable?
  15. Rookie uvm question on phasing... I want to start a uvm_component, then stop it, reset it's state, restart it, stop it again and reset it again. How would I do that? In old school vmm-speak, that'd be like: my_vmm_xactor = new(...); repeat (2) begin my_vmm_xactor.start_xactor(); #(a_little_while); my_vmm_xactor.stop_xactor(); my_vmm_xactor.reset_xactor(); end thanks, neil
  • Create New...