0
votes

I'm trying to automate unit-testing of VHDL code using a TCL-script (TCL version 8.4) in ModelSim (6.5 PE).

Based on the relevant TCL-reference manual, I am currently able to handle assertions with the onbreak {} command as follows, which allows me to continue or stop simulation in a controlled way.

However, I would also like to be able to get some more context in that handler, in particular file-name, line-number and label of the assertion that triggered the break. I would then forward this information to a continuous-integration tool.

proc break_handler {} {
    upvar #0 now now
    # this is where I would need some more information about the current break point:
    set break_point_information "???" 
    puts "Break: after $now with $break_point_information!"

    # prevent infinite simulation:
    if {$some_condition} {
        stop
    } else {
        run -continue
    }
}

# Skipped: scripted compilation of project

# Stop on Note (1) ... Failure (4)
set BreakOnAssertion 1
onbreak { break_handler }

# Skipped: scripted simulation start and report generation

The information I want is essentially already printed to the console as

# ** Warning: End of Testbench
#    Time: 1234 ns  Iteration: 0  Process: /something/testing File: C:/something.vhd
# Break in Process testing at C:/comething.vhd line 1234

Hence, I could probably record and parse a transcript file. However, that's what I wanted to avoid in the first place... The closest I come is using [runStatus -full], but that gives much less information (e.g. just break simulation_stop).

1
The transcript is the only way to get information about assertion failures and other error conditions. If you run vsim in a subprocess through a scripting language (not the internal Tcl interp) you can also parse stdout for each command invocation to avoid having to read through an entire transcript if that's an issue. - Kevin Thibedeau
@KevinThibedeau Unfortunately not what I was hoping for, but thanks for confirming. The way you formulate your comment implies that you're quite certain about this. Do you have any citable source? - mbschenkel
The manual. Modelsim has never had good support for doing "sophisticated" things with a simulation. - Kevin Thibedeau

1 Answers

2
votes

The free and open source VUnit ( https://github.com/LarsAsplund/vunit) we've developed provides what your looking for. It will point to the error location and give you the call stack. We basically have an internal signal that is set true by the testbench (test_runner_cleanup procedure at the end) if there are no errors. If that signal isn't set for any reason (the procedure may not be called at all if the testbench is setup to stop on a failing assert) a piece of tcl code called by our Python script will see that. Here is a tcl snippet from https://github.com/LarsAsplund/vunit/blob/master/vunit/modelsim_interface.py

run -all
set failed [expr [examine -internal ${status_boolean}]!=TRUE]
if {$failed} {
    catch {
        # tb command can fail when error comes from pli
        echo
        echo "Stack trace result from 'tb' command"
        echo [tb]
        echo
        echo "Surrounding code from 'see' command"
        echo [see]
    }
 }