Does each test have to be unique

Hi,

I am seeing issues such as -
identifier ‘newSeq’ previously declared

compiling tests. It seems that every time I create a new config object or new sequence object, I need to have a different name in each test case. UVM provides a way of compiling all tests together and then giving the ability to execute test using argumanet +UVM_TESTNAME but the drawback is that that in each testcase if I change some configuration parameters constraining or redfine my transaction or redfine a sequence then I must have a unique name for them.
Is there a work around for this so that I can use similar names in each test case and at the same time compiler does not show errors.

thanks
shrawan

In reply to shrawan_vaidya:

Your tests/testcases have always a different sequence/virtual sequence. The Name of These sequences have to be unique or should fiffer with respect to configuration objects. This is a simple Story. Using the same sequence name for different Content generates only confusion and might not be repetable.

In reply to shrawan_vaidya:

All of your tests, sequences, config_objects should be derived from common base classes for each. Then each test should have a set of overriding classes with the test name embedded in the name of the class. For example, suppose you have the base class test and extend that to test_A, test_B. Then you should have the base class seq, and the extended classes seq_test_A, seq_test_B. Each test uses the factory to override the creation of these extended classes. You can automate this be appending the test name to the base class when specifying the override by name.

In reply to dave_59:

Dave,

  1. It really does not make sense to everytime creae a new derived config object just to change some constraints and then override original one with this new one in the test. I am really thinking from resuability point of view and also maintainibility of test cases. Imagine each test case should have a different config object name while oberriding. And what if someone forgot to change the override name in a test. Say test1 has config1 and test2 has config2. But while overriding in test2 one by mistake puts override to config1. Then compiler won’t complain as the code for config1 exists in test1.

  2. How about if I want to use external constraint block. Say I have put external constraint blocks in config object and transcation objects.
    I would like to use them to do my random settings in my test. But then in every test I am going to do different settings. Will the compiler not complaint that I have defined multiple external constraint blocks. In anycase, which one will take presedence. The code that executes is only the test that runs. Other tests are just compiled in.

  3. “Each test uses the factory to override the creation of these extended classes. You can automate this be appending the test name to the base class when specifying the override by name”
    Could you point me to some example in line with you above remark?

Appreciate your help.

thanks
shrawan

In reply to shrawan_vaidya:

It really depends what you mean by overriding. If you are just changing the default values of config object variable settings, there is no need to create derived config objects. Your test can just make overriding assignments after creation or randomization.

I’m also not sure what you mean by external constraint blocks. Do you mean the constraints defined with the extern keyword and the constraint body outside the class body? When you extend a class, you have the choice of adding new constraints, or overriding existing constraints with the same name. Again, you do not need to create an a derived class just to change a constraint. Some constraints can be written so that all you have to do is change a setting.

constraint C { A inside {[cfg.start_range:cfg.end_range]};}

And for your third question, suppose you have test_A extended from base_test, and seq_test_A extended from base_seq. The from your base_test, you can write

set_type_override("base_seq", {"seq_",get_type_name()});

In reply to dave_59:

Thanks Dave!
Actually I am seeing all this more from Specman point of view as I have used it extensively in the past. Trying to simply find out best ways of writing environment and test cases.

Yes by external I meant constraints with extern keywords.
So my understanding based on your inputs is that config objects should be created in tests. They must be randomized and assignments must be overriden by the test.
The only reason why one would define a new config object in the test would be when he wants to add more fields to the config. Am I right?

constraint C { A inside {[cfg.start_range:cfg.end_range]};}
In this how to get cfg visible to transaction. Currently I could pass cfg in sequencer and access it in sequence using p_sequencer.cfg. Is there any way that cfg could be made visible to transaction while defining the class itself.

I still didn’t quite understand below. If there is a thread on this please poin me to that or I will simply wait till I get more matured in my usage of UVM.
"And for your third question, suppose you have test_A extended from base_test, and seq_test_A extended from base_seq. The from your base_test, you can write
set_type_override(“base_seq”, {“seq_”,get_type_name()});

thanks
shrawan

In reply to shrawan_vaidya:

Shrawan,
I believe you are looking for an AOP styled language feature in an OOP styled SV. FWIW - there are AOE (Aspect Oriented Extensions) to SV being proposed/discussed. I believe few user companies have been demanding this as well. However, I don’t believe it is being considered as strong candidate for next rev (Dave please?). Some tools have this AOE already for SV, though on-standard.

Regards
Srini
www.verifworks.com

In reply to shrawan_vaidya:

You now understand how to construct config objects. You use config_db::set()/get() to make the config object visible to most other objects, like other components and sequences. But for sequence_items and certain sequences that get created many times during a test, the overhead of get() it too much. So you may want to make a simple assignment to a local config field just after creating the object.

I think you need to become more familiar with the name versus type based factory overrides to understand how I was trying to automate the factory overrides.