Everything posted by mooredan
mooredan posted a topic in UVM Simulator Specific IssuesI'm looking for best known practices for mananging UVM tests with Synopsys VCS. What I would like to do is to compile the testbench once and then simulate the different test cases in the same directory. For example, the test package contains test1, test2, and test3 (all extended from the base_test (extended from uvm_test class)). So the command lines after compilation would be: ./simv +UVM_TESTNAME=test1 -l simv.test1.log ./simv +UVM_TESTNAME=test2 -l simv.test2.log ./simv +UVM_TESTNAME=test3 -l simv.test3.log This can easily be placed in a shell script loop or a Makefile. The caveat is that I want to run all of these (plus, let's say, a hundred more) in parallel on a compute farm. What other command line options are necessary so that they do not clobber each other if run from the same directory? I'm pretty sure that there are other intermediate files or logs created along the way (like the transaction log). Yes, I know that I can create separate run directories for each, but I would rather not due to legacy reasons (I may be migrating from Incisive and this single directory thing working along with infrastructure that I wish to reuse). A pointer to a white paper or app note would be wonderful. I have searched this forum, google, solvnet, and asked a less-experienced AC this, so far, no joy. Thank you. Dan Moore Principal Engineer - ASIC Development Rohde & Schwarz, USA, Inc.
mooredan posted a topic in UVM SystemVerilog DiscussionsHi all. This is my first post here and I'm learning UVM, but I'm not new to verification or SystemVerilog. I've seen three examples of integrating uvm_reg_block objects into a test bench. two of them (jellybean and verificationacademy) create the extended uvm_reg_block object in the test object, whereas doulos creates it in the top level env (above the agent env). For a hierarchical point of view, the latter location seems to make the most sense. However, it seems that there's a bunch of hoops to jump through to get it working. From a ease of use sense, creating it in the test object (as long as you have a base test class from which all others are derived) gets around the struggles (at least the ones that I have had) with getting the right regmodel handle passed around to where it is needed. ...and the traditional non-register-model test/sequence building/flow works because it is the test that sets the regmodel handle in the sequence after it is created. The question that I have (and I might be opening up a can of worms here) is what is the consensus on where in the test bench hierarchy is the regmodel object built? What pitfalls might I face later on down the road if I choose one methods over the other? Thanks for you insight. Dan Moore - Principal Engineer - Rohde & Schwarz, USA, Inc.