Xcelium: dump coverage information in the middle of a simulation

You should have a look at the coverage Tcl command - this allows you to dump coverage at any point in the simulation, as well as resetting coverage hit counts.
https://support.cadence.com/apex/techpubDocViewerPage?xmlName=tclcmdref.xml&title=Xcelium%20Simulator%20Tcl%20Command%20Reference%20--%20Table%20of%20Contents&hash=&c_version=24.03&path=tclcmdref/tclcmdref24.03/tclcmdrefTOC.html

For example:

# xrun.tcl
# run till part A has completed:
run 1us
# dump A coverage:
coverage -dump test_A
# reset counters and run test B:
coverage -code -reset
run
coverage -dump test_B

Thx, I had the feeling that something like this existed, but i might have looked in the wrong manual. I'm sure this will do the trick.

I have a follow-up question and since it is somewhat related I'll put it in here.

If I want to make this solution ... :

StephenH said:

# xrun.tcl
# run till part A has completed:
run 1us
# dump A coverage:
coverage -dump test_A
# reset counters and run test B:
coverage -code -reset
run
coverage -dump test_B

... dynamic, meaning I dont want to wait for 1us but rather want to react to a signal change triggered in the testbench. How would I do that?

I had the idea of doing something like that in the .tcl script:

# run the simulator and check for the flag every 1 us
while {coverage_dump_flag != 1} { run 1 us }
# dump coverage
coverage -dump cov
# run the rest of the testbench
run

This does not work, but how can I make use of the "coverage_dump_flag" variable that is beeing changed in the testbench during simulation? Do I have to probe the signal using "probe -create ..."?

Don't use Tcl's "while" loop, set a breakpoint on the signal value, and dput the coverage dump command into the action block for the breakpoint.

For example:

set num 0
stop -create -condition { #tb.coverage_dump_flag==1'b1 } -execute { coverage -dump "test_stage_[incr num]" } -continue
run

This should cause the simulator to stop every time tb.coverage_dump_flag is assigned to 1'b1, then dump the coverage to a uniquely named file, before continuing the simulation. I haven't tested this so you need to check and fix any syntax errors ;-)
I already linked the docs int he original reply so you can use that to find the exact syntax for the "stop" command.

Thanks for the speedy reply, Stephen. The syntax seems to be good, I've checked it on my end without the dynamic naming mechanic ("test_stage_[incr num]"). According to the documentation of coverage -dump, it will throw an error if a previous coverage dump with the same name is present. But it seems to me, that the -covoverwrite option in the irunArgs.f file does also apply to the coverage -dump .tcl command.

One issue remains (probably unrelated): I've compared two approaches:

1) starting the simulation with the "xrun -f irunArgs.f ..." command without using a .tcl script and having the default coverage dump at the end of the simulation (irunArgs.f: -coverage A).

2) with a .tcl script, using the command "xrun -input xrun.tcl -f irunArgs.f ...". For testing purposes the .tcl script has only one command "run". Everything else (design, irunArgs.f etc.) stayed the same.

The result is, that method 2 does not include all coverpoints that show up with method 1 and I am missing the lower hierarchy. The irunArgs.f does include the "-coverage A" option for both methods. I've checked the doku for coverage -dump to force the missing coverpoints to show up, but only found the "coverage -functional -select [*] -depth all" command for functional coverage, but it seems something similar is not implemented for toggle or code coverage.
What might be the reason for the different coverage dumps?

The xrun "-coverage A" is controlling what types of code get instrumented for coverage. Anything that you don't instrument at elaboration time, cannot later be enabled in simulation. "A" is sort for "ALL" so functional (covergroups and SVAs) should be enabled.

You don't need further Tcl commands to enable the instrumentation of coverage, the Tcl is only intended for noodling round to exclude stuff at simulation time and I wouldn't recommend it as it can cause issues later in your flow (e.g. when merging or doing other analyses).

I can't see any reason why your (1) and (2) would behave differently based on what you've written above, so we must be missing some important bit of information. It may be more efficient to debug over a screen-share. Would you mind filing a support case via https://support.cadence.com/ so that one of the hotline team can assist? We don't have a lot of Cadence people monitoring this public forum, and I am a bit too busy to deep dive on this topic at the moment...

The problem for that was on my part and not related to xrun. Done properly, there is no difference in the two examples (1) and (2), as it should be.

Thanks Stephen, I think topic can be closed.