Forums

Detecting if an error happened in ModelSim

Started by Chris Maryan October 3, 2007
Is there a way to detect if an error or warning occured during a
simulation run in ModelSim scripting. I'm just trying something
simple: what I'd like to do is have my test bench simulation set up
script quit modelsim if there are no errors, or stop and leave
modelsim running if an error occurs so I can look at the waveform
trace (I'm launching modelsim automatically from Quartus).

Any thoughts on what I should be looking at to see if an error
occured?

Thanks,

Chris

On Oct 3, 10:59 am, Chris Maryan <kmar...@gmail.com> wrote:
> Is there a way to detect if an error or warning occured during a > simulation run in ModelSim scripting. I'm just trying something > simple: what I'd like to do is have my test bench simulation set up > script quit modelsim if there are no errors, or stop and leave > modelsim running if an error occurs so I can look at the waveform > trace (I'm launching modelsim automatically from Quartus). > > Any thoughts on what I should be looking at to see if an error > occured? > > Thanks, > > Chris
Not quite sure what your definition of 'error' is but if your testbench uses assertions to check that you're getting the proper results then the simulation will stop automatically for you for you to investigate waveforms. If no such assertions fire then the fact that the 'run -all' completes would mean there are no errors and Modelsim should end. Ex: assert (Mysignal = All_Things_Good) report "OOPS! Mysignal is not in the proper state" severity ERROR; You would have to set Modelsim to stop on severity level of 'ERROR' or higher. I believe this is the default, but in any case it is a settable thing (i.e. you can have it stop on severity 'WARNING' if you'd like). Not sure if this is what you're looking for or not though. KJ
Chris Maryan wrote:
> Is there a way to detect if an error or warning occured during a > simulation run in ModelSim scripting. I'm just trying something > simple: what I'd like to do is have my test bench simulation set up > script quit modelsim if there are no errors, or stop and leave > modelsim running if an error occurs so I can look at the waveform > trace
You could run vsim -c my_tb from some script and return pass/fail. If it passes, start quartus, else run vsim my_tb -do my_tb.do to run with waves for debug. See the testbench here: http://home.comcast.net/~mike_treseler/ for some command line examples. (I'm launching modelsim automatically from Quartus). That might be putting the cart in front of the horse. Unless the sim passes, I see no reason to spend time running or even starting up quartus. -- Mike Treseler
Thanks for the input, but what I would like to do is not stop on an
error (only on fatal, which is the default), catch all the errors and
then script a decision based on whether errors had occured or not.
That is, run -all completes regardless, reporting errors along the
way, then if it completed without errors do something (quit modelsim),
if it completed with errors do something else (don't quit).

Chris

On Oct 3, 1:15 pm, KJ <Kevin.Jenni...@Unisys.com> wrote:
> On Oct 3, 10:59 am, Chris Maryan <kmar...@gmail.com> wrote: > > > Is there a way to detect if an error or warning occured during a > > simulation run in ModelSim scripting. I'm just trying something > > simple: what I'd like to do is have my test bench simulation set up > > script quit modelsim if there are no errors, or stop and leave > > modelsim running if an error occurs so I can look at the waveform > > trace (I'm launching modelsim automatically from Quartus). > > > Any thoughts on what I should be looking at to see if an error > > occured? > > > Thanks, > > > Chris > > Not quite sure what your definition of 'error' is but if your > testbench uses assertions to check that you're getting the proper > results then the simulation will stop automatically for you for you to > investigate waveforms. If no such assertions fire then the fact that > the 'run -all' completes would mean there are no errors and Modelsim > should end. > > Ex: > assert (Mysignal = All_Things_Good) > report "OOPS! Mysignal is not in the proper state" > severity ERROR; > > You would have to set Modelsim to stop on severity level of 'ERROR' or > higher. I believe this is the default, but in any case it is a > settable thing (i.e. you can have it stop on severity 'WARNING' if > you'd like). > > Not sure if this is what you're looking for or not though. > > KJ
On Oct 3, 1:37 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> Chris Maryan wrote: > > Is there a way to detect if an error or warning occured during a > > simulation run in ModelSim scripting. I'm just trying something > > simple: what I'd like to do is have my test bench simulation set up > > script quit modelsim if there are no errors, or stop and leave > > modelsim running if an error occurs so I can look at the waveform > > trace > > You could run > vsim -c my_tb > from some script and return pass/fail. > If it passes, start quartus, else run > vsim my_tb -do my_tb.do > to run with waves for debug. > See the testbench here: > http://home.comcast.net/~mike_treseler/ > for some command line examples. > > (I'm launching modelsim automatically from Quartus). > > That might be putting the cart > in front of the horse. > Unless the sim passes, I see no reason > to spend time running or > even starting up quartus. > > -- Mike Treseler
Thanks Mike, running the sim twice as you suggested might be my answer, it doesn't take long. As for running Quartus first, I'm relying on it to give me gate level timings and pass that along to ModelSim. So my process is to compile in Quartus, then launch modelsim to test. If I was just doing RTL simulation, I could skip Quartus altogether. That and Quartus has a friendlier VHDL editor. Chris
Chris Maryan wrote:

> Thanks Mike, running the sim twice as you suggested might be my > answer, it doesn't take long. > As for running Quartus first, I'm relying on it to give me gate level > timings and pass that along to ModelSim.
Hmm. The quartus static timing is very good. Why run a gate sim which is much slower and tests less?
> So my process is to compile > in Quartus, then launch modelsim to test. > If I was just doing RTL > simulation, I could skip Quartus altogether.
I spend most of my time in simulation, but bring up quartus once in a while to look at the RTL schematics. -- Mike Treseler
Thanks for the feedback. What you said brings up a more general
question: what is your general design/validation process (in terms of
switching between Quartus, ModelSim and whatever else)?

In case it's not glaringly obvious, I'm relatively new to this.

Chris

On Oct 3, 2:18 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> Chris Maryan wrote: > > Thanks Mike, running the sim twice as you suggested might be my > > answer, it doesn't take long. > > As for running Quartus first, I'm relying on it to give me gate level > > timings and pass that along to ModelSim. > > Hmm. The quartus static timing is very good. > Why run a gate sim which is much slower > and tests less? > > > So my process is to compile > > in Quartus, then launch modelsim to test. > > If I was just doing RTL > > simulation, I could skip Quartus altogether. > > I spend most of my time in simulation, > but bring up quartus once in a while > to look at the RTL schematics. > > -- Mike Treseler
Chris Maryan wrote:
> Thanks for the feedback. What you said brings up a more general > question: what is your general design/validation process (in terms of > switching between Quartus, ModelSim and whatever else)?
1. I follow an synchronous template for synthesis code. This eliminates asynchronous feedback by design. If there is more than one clock, I write separate entities for each and use explicit synchronization. 2. I run vcom from the editor to validate syntax after a few lines of new code. The editor jumps to the first syntax error. 3. As soon as some output ports are described I generate a baseline reset/clock testbench from the editor and validate initialization. I add stimulus and verification procedures to close the loop on the testbench with a pass/fail output. 4. After each significant feature is described and verified by simulation, I run synthesis to check Fmax and the RTL viewer, and commit the changes to svn source control. -- Mike Treseler
On Oct 3, 7:49 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> Chris Maryan wrote: > > Thanks for the feedback. What you said brings up a more general > > question: what is your general design/validation process (in terms of > > switching between Quartus, ModelSim and whatever else)? > > 1. I follow an synchronous template for synthesis code. > This eliminates asynchronous feedback by design. > If there is more than one clock, I write > separate entities for each and use explicit > synchronization. > > 2. I run vcom from the editor to validate syntax > after a few lines of new code. > The editor jumps to the first syntax error. > > 3. As soon as some output ports are described > I generate a baseline reset/clock testbench > from the editor and validate initialization. > I add stimulus and verification procedures > to close the loop on the testbench with a > pass/fail output. > > 4. After each significant feature is described > and verified by simulation, I run synthesis > to check Fmax and the RTL viewer, and commit > the changes to svn source control. > > -- Mike Treseler
Thanks Mike, insightful and useful. Chris