VIRTUTECH CONFIDENTIAL    Previous - Up - Next

9.3   Error Reporting

The model should handle errors in a forgiving way. Avoid crashing or triggering assertions; instead, log an error message and try to continue anyway. If necessary, halt the simulator, but allow the user to continue manually.

There are three different kinds of errors that should be reported by a Simics device:

  1. Outside architecture error. A part of the device whose behavior is not specified in the hardware documentation has been accessed. For example, a reserved register has been written to.
  2. Unimplemented error. A part of the device which has been left unimplemented in the model (abstracted away) was accessed. This suggests a bug in the model, or that the model is used with software it was not developed for.

    In some cases it is sufficient to give a warning for this kind of situation, for example if the model returns approximate or invented values.

  3. Internal error. The internal state of the model implementation has been corrupted beyond repair. Look for "this will never happen" comments and reconsider...

Simics has extensive support for logging, allowing you to assign the output to different message categories, and different levels of verbosity. See the DML Reference Manual and the Simics Reference Manual for details. Logging is mostly used during development and debugging of the model, but is also useful to aid inspection of the device state during actual simulation.

Always use detailed error messages. Often, the error messages are the only source of information when a bug is reported by another user. It is not certain that the execution can be repeated, or that the developer will have access to the same setup.

VIRTUTECH CONFIDENTIAL    Previous - Up - Next