FPGA Central

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

Andrew FPGA wrote:

> # ** 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

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

[email protected] wrote:
> 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.

Mike Treseler wrote:

> 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...

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

Andrew FPGA wrote:

> 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