Good Luck
TeamCVC

virtual function void apply_config_settings(bit verbose = 0)
Automates the calling of get_config() during the build phase for all registered (using the automation macros) fields. This is really hidden magic, and I am not a big fan, but it does make things “easy” .
If you do not want apply_config_settings to be called for a component, then the build() method
should be overloaded and you should not call super.build(). If this case, you must also set the
m_build_done bit. Likewise, apply_config_settings can be overloaded to customize automated
configuration.
When the verbose bit is set, all overrides are printed as they are applied. If the component’s
print_config_matches property is set, then apply_config_settings is automatically called with verbose = 1.

Here is an example of apply_config_settings.

my_test extends ovm_test;

virtual function void build();
super.build();
endfunction : build

virtual function void end_of_elaboration();
root = ovm_root::get();
root.set_config_int(Tb0.env0.virtualSequencer.get_full_name(),
“count”, 1);
root.set_config_string(Tb0.env0.virtualSequencer.get_full_name(),
“default_sequence”, “RtrAllPathsVirtualSequence”);
Tb0.env0.virtualSequencer.apply_config_settings();

endfunction : end_of_elaboration

endclass : my_test

In my_test test case we configure virtual sequencer’s default sequence by RtrAllPathsVirtualSequence virtual sequence at end_of_elaboration phase. Then we call apply_config_settings to apply new configurations.

Thanks for letting users know about the Questa feature.

The reason, in case you didn’t know already, that Questa does not print the debug information automatically is that it is very expensive to keep all the information around to produce the testcase, and slows the solver down down during normal operation.

Also ‘-solveverbose 1|2′ provides information about constraints that do not fail.

Dave Rich

Most of your verification technologies discussed are mainly digital centric. As you are well aware, at 65nm and below, all Chips, SoCs and Systems are mixed signal. So, it would be great to have some mixed signal verification technologies discussed. In other words, how to integrate the analog and digital domains to provide a mixed signal verification solution for Silicon Realization, a key component of the overall Cadence EDA360 initiative.

Silicon Realization represents everything it takes to get a design into silicon. The result could be an analog or digital IP block for an SoC, an IP subsystem, or a complete IC without embedded software. Silicon Realization increasingly involves the creation and integration of large and complex digital, analog, and mixed-signal IP blocks. It goes well beyond conventional “mixed-signal” designs that integrate a few small analog blocks into a digital SoC.

Just a few thoughts for your next blog….

Kishore

Most of your verification technologies discussed are mainly digital centric. As you are well aware, at 65nm and below, all Chips, SoCs and Systems are mixed signal. So, it would be great to have some mixed signal verification technologies discussed. In other words, how to integrate the analog and digital domains to provide a mixed signal verification solution for Silicon Realization, a key component of the overall Cadence EDA360 initiative.

Silicon Realization represents everything it takes to get a design into silicon. The result could be an analog or digital IP block for an SoC, an IP subsystem, or a complete IC without embedded software. Silicon Realization increasingly involves the creation and integration of large and complex digital, analog, and mixed-signal IP blocks. It goes well beyond conventional “mixed-signal” designs that integrate a few small analog blocks into a digital SoC.

Just a few thoughts for your

You can find all of the details of the OVM/VMM booth here: http://www.ovmworld.org/tradeshows_dac2010.php

=Adam Sherilog