dlong
02-04-2008, 09:28 AM
Hi,
AVM has a configure callback function which is called just before run. URM and OVM have a pre_run phase and callback which is also called just before run. In OVM, classes derived from ovm_threaded_component inherit a virtual pre_run function that by default calls configure, thereby ensuring backwards compatibility with AVM. So far so good!
However, there is no mechanism to automatically call configure functions for classes derived from ovm_component but not derived from ovm_threaded_component.
I was wondering if this was an oversight or if it had been decided to only allow this callback for threaded components?
In practice, I don't think this will cause any major problems since the type of statements I would normally expect to put inside configure/pre_run (configuring the hierarchy, opening files, setup reporting options, etc) belong in the test or environment classes (both of which are derived from ovm_threaded_component). On the other hand, some AVM users may well have created a hierarchy with an avm_named_component top level which includes a configure function. Such code would need to be modified unless ovm_component is going to get a similar pre_run callback to ovm_threaded_component.
Any comments?
Regards,
Dave
AVM has a configure callback function which is called just before run. URM and OVM have a pre_run phase and callback which is also called just before run. In OVM, classes derived from ovm_threaded_component inherit a virtual pre_run function that by default calls configure, thereby ensuring backwards compatibility with AVM. So far so good!
However, there is no mechanism to automatically call configure functions for classes derived from ovm_component but not derived from ovm_threaded_component.
I was wondering if this was an oversight or if it had been decided to only allow this callback for threaded components?
In practice, I don't think this will cause any major problems since the type of statements I would normally expect to put inside configure/pre_run (configuring the hierarchy, opening files, setup reporting options, etc) belong in the test or environment classes (both of which are derived from ovm_threaded_component). On the other hand, some AVM users may well have created a hierarchy with an avm_named_component top level which includes a configure function. Such code would need to be modified unless ovm_component is going to get a similar pre_run callback to ovm_threaded_component.
Any comments?
Regards,
Dave