parsing script arguments in QuestaSim/ModelSim

[Marcin Rodzik]

I have a problem with an automated testbench in ModelSim/QuestaSim. I
run a TCL script which invokes another script using the DO command. In
the other script, I use both SWITCH and SHIFT commands to examine
arguments the second script has been called with. After some
modifications of the scripts, I started to experience problems: my
verification software hangs or crashes - always in the same place in
the TCL code, namely, the 13th (sic!) SHIFT operation fails.
Meanwhile, a file is generated with something I believe is the call
stack. Its contents can be viewed here: http://tl.gd/3ehhma

I thought my software installation is corrupted or something, but I
tried to run the simulation on another computer with a different
version of the software installed, and I observed the same behaviour.
What's wrong? Is this my script or a bug common to many software
distributions?

Any suggestions and help will be appreciated.

MR

 

[RCIngham]

I have a problem with an automated testbench in ModelSim/QuestaSim. I
run a TCL script which invokes another script using the DO command. In
the other script, I use both SWITCH and SHIFT commands to examine
arguments the second script has been called with. After some
modifications of the scripts, I started to experience problems: my
verification software hangs or crashes - always in the same place in
the TCL code, namely, the 13th (sic!) SHIFT operation fails.
Meanwhile, a file is generated with something I believe is the call
stack. Its contents can be viewed here: http://tl.gd/3ehhma

I thought my software installation is corrupted or something, but I
tried to run the simulation on another computer with a different
version of the software installed, and I observed the same behaviour.
What's wrong? Is this my script or a bug common to many software
distributions?

Any suggestions and help will be appreciated.

MR

The effect of the 'do' command seems to be to execute the contents of th
target script in the current context. This is usually OK. However
sometimes this has odd effects, especially when returning, perhaps as yo
are observing.

Using the standard Tcl 'source' command executes the script in a chil
context, which means that it returns cleanly. Try and see if it helps.

Cheers!


---------------------------------------
Posted through http://www.FPGARelated.com

 

[Jonathan Bromley]

On Thu, 02 Sep 2010 03:24:32 -0500, "RCIngham" wrote:

Using the standard Tcl 'source' command executes the script in a child
context, which means that it returns cleanly.

For extra credit, discover and explain why that statement is
almost completely untrue.
--
Jonathan Bromley

 

[Jonathan Bromley]

On Wed, 1 Sep 2010 12:18:25 -0700 (PDT), Marcin Rodzik
<marteno_rodia@o2.pl> wrote:

I have a problem with an automated testbench in ModelSim/QuestaSim. I
run a TCL script which invokes another script using the DO command. In
the other script, I use both SWITCH and SHIFT commands to examine
arguments the second script has been called with. After some
modifications of the scripts, I started to experience problems: my
verification software hangs or crashes - always in the same place in
the TCL code, namely, the 13th (sic!) SHIFT operation fails.
Meanwhile, a file is generated with something I believe is the call
stack. Its contents can be viewed here: http://tl.gd/3ehhma

I don't much like the [shift] command (it's a ModelSim special,
not part of standard Tcl) but I just tried a sample with over 20
arguments and it worked just fine, so I'm guessing it's some
other problem. It's hard to know what happened from that
stack trace, but at a guess I'd suggest that you are somehow
restarting the simulation (or re-entering some kind of debug
behaviour) from within a breakpoint.

One useful trick is to display the current Tcl nesting
depth, using
echo "Tcl nesting = [info level]"
perhaps each trip round a main loop, or something like that.

This will certainly tell you if you have a Tcl execution
stack overflow, but it won't help if the problem is
re-entrant calls to the simulator.

Check out the [resume], [onbreak] and [abort] commands,
too. And make sure you are returning cleanly from any
scripts you execute during a breakpoint.

Another useful trick is to trace your [do] commands,
so you can see exactly what arguments they were called with.
Execute this script using [source] or [do]:

proc trace_my_do_commands {commandstring operation} {
echo "---tracing <$operation> $commandstring"
}
proc cancel_do_tracing {} {
foreach inf [trace info execution do] {
trace remove execution do [lindex $inf 0] [lindex $inf 1]
}
}
proc start_do_tracing {} {
trace add execution do enter trace_my_do_commands
}

Now, after you issue the command
start_do_tracing
every time you (or one of your scripts) executes any [do]
command, it will be displayed in full just before it's run.
If you weary of all the output, you can suppress the trace
with your new command
cancel_do_tracing

Hope this gives you some ideas.
--
Jonathan Bromley