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

>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 thetarget script in the current context. This is usually OK. However,sometimes this has odd effects, especially when returning, perhaps as youare observing. 

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

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

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

On Wed, 1 Sep 2010 12:18:25 -0700 (PDT), Marcin
Rodzik
<m...@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