During simulation, the phases are executed one by one, where one phase must complete before the next phase begins. The following briefly describe each phase:
1.1 new
Also known as the constructor, the component does basic initialization of any members not subject to configuration.
1.2 build
The component constructs its children. It uses the get_config interface to obtain any configuration for itself, the set_config interface to set any configuration for its own children, and the factory interface for actually creating the children and other objects it might need.
1.3 connect
The component now makes connections (binds TLM ports and exports) from child-to-child or from child-to-self (i.e. to promote a child port or export up the hierarchy for external access. Afterward, all connections are checked via resolve_bindings before entering the end_of_elaboration phase.
1.4 end_of_elaboration
At this point, the entire testbench environment has been built and connected. No new components and connections may be created from this point forward. Components can do final checks for proper connectivity, and it can initiate communication with other tools that require stable, quasi-static component structure..
1.5 start_of_simulation
The simulation is about to begin, and this phase can be used to perform any pre-run activity such as displaying banners, printing final testbench topology and configuration information.
1.6 run
This is where verification takes place. It is the only predefined, time-consuming phase. A component’s primary function is implemented in the run task. Other processes may be forked if desired. When a component returns from its run task, it does not signify completion of its run phase. Any processes that it may have forked continue to run. The run phase terminates in one of four ways:
1.6.1 stop
When a component’s enable_stop_interrupt bit is set and global_stop_request is called, the component’s stop task is called. Components can implement stop to allow completion of in-progress transactions,
1.6.2 objections dropped
The ovm_test_done_objection will implicitly call global_stop_request when all objections to ending the phase are dropped. The stop procedure described above is then allowed to proceed normally.
1.6.3 kill
When called, all component’s run processes are killed immediately. While kill can be called directly, it is recommended that components use the stopping mechanism, which affords a more ordered and safe shut-down.
1.6.4 timeout
If a timeout was set, then the phase ends if it expires before either of the above occur. Without a stop, kill, or timeout, simulation can continue “forever”, or the simulator may end simulation prematurely if it determines that all processes are waiting.
1.7 extract
This phase can be used to extract simulation results from coverage collectors and scoreboards, collect status/error counts, statistics, and other information from components in bottom-up order. Being a separate phase, extract ensures all relevant data from potentially independent sources (i.e. other components) are collected before being checked in the next phase. Following are some examples of what you can do in this phase.
■ Collect assertion-error count.
■ Extract coverage information.
■ Extract the internal signals and register values of the DUT.
■ Extract internal variable values from components.
■ Extract statistics or other information from components.
1.8 check
Having extracted vital simulation results in the previous phase, the check phase can be used to validate such data and determine the overall simulation outcome. It too executes bottom-up.
1.9 report
Finally, the report phase is used to output results to files and/or the screen.
It is called in bottom-up order.
No comments:
Post a Comment