Are there any Modelsim hooks to allow testbench code to figure out procedure call stack?

A

Andrew FPGA

Hi,
We are using Modelsim Xilinx Edition III 6.0d. Throughout my testbench
I make calls to procedures that generate stimulus or check results.
Sometimes these procedures might detect an errror condition and I use

report "Warning: BusWrite() detected invalid bus state prior to writing
to the bus"

Then if this error or warning condition occurs modelsim prints the
following in the transcript window.

# ** Note: Warning: BusWrite() detected invalid bus state prior to
writing to the bus"
# Time: 508552 ns Iteration: 0 Instance:
/pcmrxinterfacetxframerhornettb

The problem is, I make calls to BusWrite() in lots of places in my
testbench. How can I figure out which one of those calls was the one
that caused the message to be printed?

Are there any modelsim hooks that would allow my testbench code to
figure out the call stack and/or where in the source the procedure got
called from. I could print this info along with my error message above.


Regards
Andrew
 
M

Mike Treseler

Andrew said:
# ** Note: Warning: BusWrite() detected invalid bus state prior to
writing to the bus"
# Time: 508552 ns Iteration: 0 Instance:
/pcmrxinterfacetxframerhornettb

The problem is, I make calls to BusWrite() in lots of places in my
testbench. How can I figure out which one of those calls was the one
that caused the message to be printed?

Only by the time.
Bring up the waves and put a cursor on it.
Are there any modelsim hooks that would allow my testbench code to
figure out the call stack and/or where in the source the procedure got
called from.

You could set a breakpoint in the source.

-- Mike Treseler
 
N

nemgreen

Why not pass an additional parameter to BusWrite() that identifies the
caller

eg if you have 4 drivers, pass D1..D4 as a parameter with the call and
include this in any messages output.

ie.
# ** Note: Warning: D1 - BusWrite() detected invalid bus state prior to

writing to the bus"

- Norm
 
B

Bill Mills

Why not pass an additional parameter to BusWrite() that identifies the
caller

eg if you have 4 drivers, pass D1..D4 as a parameter with the call and
include this in any messages output.

ie.
# ** Note: Warning: D1 - BusWrite() detected invalid bus state prior to

writing to the bus"

- Norm

A variation of this is to add a parameter to return the status of the
BusWrite procedure, and let the caller handle it.
 
A

Andrew FPGA

Mike said:
You could set a breakpoint in the source.
Embarrassed to admit I hadn't thought of that. Works well in this case,
I break and then step through until the procedure returns.

But I can imagine for more complicated testbenches, it won't be so easy
to step out quickly. I'm trying to move away from the modelsim gui and
be more automated about my testing. Say I run the testbench in batch
mode overnight and the assert happens near the end of the run...
 
A

Andrew FPGA

Ok, but the downside is I need to remember to pass in unique
identifiers each time I make the call.
 
M

Mike Treseler

Andrew said:
But I can imagine for more complicated testbenches, it won't be so easy
to step out quickly. I'm trying to move away from the modelsim gui and
be more automated about my testing. Say I run the testbench in batch
mode overnight and the assert happens near the end of the run...

There are two phases to simulation:
debugging errors and regressing changes.

The GUI is useful for ad hoc debugging phase.
I want as much information as possible
to find the errors. But one they are
found and fixed, this effort is reduced to
comments in the code.

Once everything is working and meets timing
I need to close the loop on the testbench.
Here, I run a simulation to quickly verify that my small
change has not broken any major function that was
working before. I want to verify all the critical
expected values and see either
a PASS at the end or a break at the first
failure.

Have a look at my reference testbench for
an example.

-- Mike Treseler
 
Joined
Nov 1, 2008
Messages
1
Reaction score
0
Sorry for replying to this really old thread but I thought I would just add my $0.02...

The solutions discussed here are fine but it seems like it would be so much more elegant for modelsim to provide the call stack when fatal errors occur or have a system function that lets us figure it out. Even perl has the "caller()" function that lets you see where things are being called from. Seems like a pretty basic debug tool that would be VERY valuable, that would save a lot of time and would make the code much cleaner (by not having to pass the caller in every single function you ever create).

Then again there seems to be a lot of very basic features that Modelsim (and Synosis for that matter) never seem to get, even though the software world has been doing some of these things for decades now...

{step up on soapbox}
I wish more people would demand better from the vendors so that the level and quality of tools that we all use would continue to improve.
{step down}
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,830
Latest member
ZADIva7383

Latest Threads

Top