Using Logs

Logs provide a mechanism to conditionally print a formatted message. What makes them powerful is that they can be enabled or disabled from different places in the testbench. Log supports levels DEBUG, INFO, FINAL, and ALWAYS. The level ALWAYS enabled, all the others are disabled by default.

In common with alerts, logs support two modes: simple and hierarchy. In simple mode, there is a single set of global controls for enabling DEBUG, INFO, and FINAL. In hierarchy mode, there are separate controls for enabling DEBUG, INFO, and FINAL in each model and/or control point in the hierarchy.

All printing done by AlertLogPkg uses the OSVVM TranscriptPkg. Hence, if TranscriptFile is open, printing is directed to the file, otherwise, printing is directed to std.textio.OUTPUT.

Simple Mode: Global Log Control

Simple mode is available by default. In simple mode, there is a single set of global controls for enabling DEBUG, INFO, and FINAL. The following provides a short example of setting log controls.

All designs that use log (or alert) need to reference the package AlertLogPkg.

library osvvm ; 
    use osvvm.AlertLogPkg.all ; 
entity tb is

In simple mode, levels can be enabled or disabled from anywhere in the testbench by calling SetLogEnable. The log ALWAYS is always enabled, all other logs are disabled by default.

SetLogEnable(DEBUG, TRUE) ;

The following log will print “A message” when DEBUG is enabled.

Log ("A message", DEBUG) ;

The format of a log message is as follows.

%% Log   DEBUG  A Message  at 15110 ns

Hierarchy Mode: Each model supports separate controls.

In hierarchy mode, there are separate controls for enabling DEBUG, INFO, and FINAL in each model and/or control point in the hierarchy.

To implement hierarchy mode, AlertLogPkg has a data structure inside of a shared variable. Each level in a hierarchy is referenced with an AlertLogID (of AlertLogIDType). To use log (or alert), a model must allocate an AlertLogID. Then when calling log (or alert), it specifies the AlertLogID as the first parameter in the call.

A new AlertLogID is created by calling the function GetAlertLogID. GetAlertLogID has two parameters: Name and ParentID (of AlertLogIDType). Name is a string value that will be printed as the hierarchy name.  The following creates an AlertLogID for the CpuModel.

constant CPU_ALERT_ID : AlertLogIDType := 
    --            Name (string value),         Parent AlertLogID
    GetAlertLogID(PathTail(CpuModel'PATH_NAME), ALERTLOG_ BASE_ID) ;

The AlertLogID is specified first in calls to Log and SetLogEnable.

SetLogEnable(CPU_ALERT_ID, DEBUG, TRUE) ; 
Log (CPU_ALERT_ID, "A message", DEBUG) ;

The format of a log message includes the AlertLogID as shown below.

%% Log   DEBUG  in CpuModel_1, A Message  at 15110 ns

Log enables can also be read from a file using the procedure ReadLogEnables.

ReadLogEnables("./Test1EnableDebug.txt") ;

The file read format is:

U_CpuModel DEBUG
U_UART_TX DEBUG INFO
U_UART_RX FINAL INFO DEBUG

Going Further

For a complete command reference guide, see AlertLogPkg_User_Guide.pdf