Built-in Message Logging – Part 1 of 2

[Team Specman welcomes guest blogger Michael Avery, from our Services Group in the UK]

Messaging is important for two main reasons:

• It is essential for debugging


• It can greatly impact simulation performance

This is why Specman has a messaging infrastructure built-in to provide an easy to use, scalable and efficient mechanism.  Furthermore, Specman’s messaging capabilities allow you to do almost anything which you can conceive with messaging: colouring, formatting, rejection, modification, redirection, etc.

The infrastructure uses a predefined unit called a message_logger to deal with message requests. Message requests are made using the message() action.  By default, the “sys.logger” message logger is available, where sys.logger will deal with all message actions if you do not specify your own.  However, you can and should instance your own message_loggers, where at a minimum I’d recommend each UVC in a testbench should have its own message_logger.  In practice, it is very likely that major units like agents and monitors will also have their own message_loggers.

Given this background, here are some message_logger first principals:

• When a message request is made, this message is "seen" by every message_logger from the unit containing the message action, through each direct ancestor, all the way up until it reaches sys.logger. 


• Each message_logger has associated with it a maximum of 2 destinations: the screen and a file.


• Each of these loggers may have been configured differently, where some loggers may have been configured to ignore a given message.  In the “ignore” case,  message requests still get passed on up the chain to sys.logger, but only message_loggers which have been configured to respond to the message will do so; and only if that message request has not already been sent to the same destination by a message_logger closer to the origin of the message request.  i.e. the same message request will not be sent to the screen by more than 1 message_logger.


• Even if a message logger deals with a message request, it still passes that message request up the hierarchy.  This is because that message_logger does not know if a message_logger further up the hierarchy is configured to send the same message to a different destination (for example, a file to which the message has not been sent by another message_logger).

What about the amount of messages and the level of detail required from them?   In general, two factors come into play:

1. Clearly different levels of maturity of verification environment or RTL strongly influence the message quantity & quality.  For example, it’s oftern helpful to have lots of detailed messaging early on in the environment bring up and debugging process, then thin it out as the environment matures so you don't have thousands of detailed messages in our logs potentially obscuring important activity.


2. Verification at different levels of abstraction also influences messaging.  While similar in practice to (1) above, in this case as we move from module to system level verification then the messages from the lower level become less relevant.  In fact, the system integrator probably does not have enough detailed knowledge of the low level block to make sense of the message anyway.  That said, unearthing the roots of a system level bug may require a temporary reactivation of detailed messaging for a particular monitor instance connected to a particular DUT interface.

In the next installment of this series, I’ll share some tips on how to programmatically control message display to help speed your debug process.

Michael Avery
Cadence Services Organization, UK