AlertLogPkg: Print to separate files

[rhinton]

On line 2226 of the current AlertLogPkg.vhd, the base AffirmIf procedure calls

AlertLogStruct.Alert(AlertLogID, ReceivedMessage & ExpectedMessage, ERROR) ; 

which forces calling Alert with a severity of ERROR. However, AffirmIf already has an AlertLevel input. I am trying to signal a FAILURE with an AffirmIf call, but the severity that I request gets ignored.

[JimLewis]

This is something that evolved in 1705 release. What I was finding was that I needed separate messages for Log (just the ReceivedMessange) and for Alert (both ReceivedMessage and ExpectedMessage). I also needed a boolean flag that enables logging on a transaction by transaction basis. This is the rationale for the new overloading.

OTOH, the old overloading still exists, it has just been moved to the deprecated section. It effectively still supports (via three overloaded procedures). Of course, the downside of this is that you loose the new style messaging and you loose the ability to enable logs on a transaction by transaction basis.

  procedure AffirmIf(
    AlertLogID   : AlertLogIDType ;
    condition    : boolean ;
    Message      : string ;
    LogLevel     : LogType  := PASSED ;
    AlertLevel   : AlertType := ERROR
  ) is
  begin
    AlertLogStruct.IncAffirmCount ; -- increment check count
    if condition then
      -- passed
      AlertLogStruct.Log(AlertLogID, Message, LogLevel) ; -- call log
--      AlertLogStruct.IncAffirmPassCount ; -- increment pass & check count
    else
      AlertLogStruct.Alert(AlertLogID, Message, AlertLevel) ; -- signal failure
    end if ;
  end procedure AffirmIf ;

The newer forms could be extended to support LogLevel and AlertLevel, however, that would also mean testing them.

Before we consider adding them, why do you want failure with AffirmIf? AffirmIf is intended for data checking, and hence, ERROR/PASSED is used.

FAILURE is intended for messages for which under normal conditions it is not appropriate to continue, such as the addressed device failed to respond. These items are not normally data checking, but instead protocol checking. With these I typically do not need a log PASSED message when they execute correctly, so I use AlertIf instead.

If you are using a methodology where you want to stop on any ERROR, even data checking errors, you can use SetAlertStopCount(ERROR, 0) ; With this, the first ERROR will stop the simulation.

[rhinton]

I'm not following your example, but I can see the difference between an Alert (protocol) vs. Affirm (data). Last time we talked, I got the idea that the Affirm was a souped-up version of the Alert that (optionally) logged successes to file. I liked the idea of a file "backup" showing exactly which tests passed and when.

I'm still figuring out what I really want from a methodology perspective, so I'm happy to go with the flow for now. Mostly I was simply surprised when I asked for a FAILURE and got an ERROR instead.

What I really wanted today was to be able to have a log file specific to the transactions of a particular subcomponent. I was disappointed when I learned that I get one and only one transcript. I know other options exist (like just using a FILE or the VHDL stdio project), but this might be a nice feature to add if it's convenient.

[JimLewis]

I'm still figuring out what I really want from a methodology perspective, so I'm happy to go with the flow for now. Mostly I was simply surprised when I asked for a FAILURE and got an ERROR instead.

If you put in a FAILURE, it should have been a compile error unless FAILURE somehow resolved to boolean.

What I really wanted today was to be able to have a log file specific to the transactions of a particular subcomponent. ...

I would like this too. Without breaking the methodology, I need arrays of files or arrays of protected types to do this - a VHDL-2017 feature. This is on my high list. Hopefully people are listening.

If I were to change the AlertLogType to be a protected type, I could include a file identifier internal to it for printing. This may work, but it would complicate things and either create a non-backward compatible change (which is bad) or require duplication of the interface subprograms to allow the AlertLogID to be an integer type or a protected type. The protected type would hold the integer based AlertLogId and the file identifier.

I will keep mulling it over. Maybe I can come up with something non-disruptive or maybe the overloading will not be too bad - but it basically doubles everything that is in there and doubles the number of testbenches.

[rhinton]

I was imagining something along the following lines.

• Overload opening a transcript file to return a transcript file ID. (I would use an integer, making the result a file handle like C's stdio.h.)
• One of the transcripts would be the default (like C's stdout).
• Add procedures to choose a non-default transcript by AlertLogID and/or AlertType. (I would add LogLevel here, but it looks like that's only in the deprecated interface now.)
  This would be more overloads to test, but not twice as much. I assume there would be a new facility in TranscriptPkg to lookup a file handle by number. Then you would probably need a lookup in AlertLogPkg to decide which transcript to target for a particular message, but again it feels like a simple array lookup.

This doesn't sound very hard, does it?

[JimLewis]

Ok. With the current language transcript package would have some finite set of file handles or identifiers. They would not be an array and they would have to be processed with a case statement.

It is gross but it would be a good prototype for vhdl-2017

With 2017 we get arrays of file identifiers and if I rember right they can be dynamically allocated which would allow allocation of a fixed size ehich could grow.

[rhinton]

A finite set for now should be fine. I assume you've seen the C-like standard IO package here:

http://bear.ces.cwru.edu/VHDL/doc/snug2002_20040606_slides.pdf

They use a fixed maximum of files. I assume if you set a reasonable maximum of 10, for instance, it would rarely be hit.

For the present, I would be happy to be able to log verbose debug stuff to a file while still sending the alerts to the simulator transcript. Recently a coworker who told me, "No, my simulation is working fine. I don't see any errors" because the alerts were going to the log file with the (very verbose) debug info.

[JimLewis]

Keep hashing out other features you would like as it will be easier to refactor and add them all at the same time rather than incrementally.

For the present, I would be happy to be able to log verbose debug stuff to a file while still sending the alerts to the simulator transcript.
Currently we track DEBUG, FINAL, INFO, PASSED for each level and control it there for both OUTPUT and the file.

How would the separate enable for the file work? Would it be a global enable override for DEBUG, FINAL, INFO, PASSED for the file, or would it be something that is enabled based on a particular Model / AlertLogID? Note FINAL was my first attempt PASSED and is an artifact.

I assume you've seen the C-like standard IO package here:
I remember reviewing it early on, but reminders are always appreciated. I am interested in creating a more flexible version of their pipes packages.

The VUNIT packages have different formats available for printing too, such as human vs. csv (for processing with a separate program). I think OUTPUT always uses human, where as the FILE can have different settings. If this is interesting, I will look at how to factor this in.

I assume if you set a reasonable maximum of 10, for instance, it would rarely be hit.

Here I was thinking a nice power of two like 32, 64, or 128 would keep me safe. I will have to figure out how to design this with the future in mind. I am going to cry as I write the fixed size code - it will be ugly.

[rhinton]

How would the separate enable for the file work?

I can see two easy ways.

1. As you suggested, select the destination based on log message type. In my case, I have some verbose logging for debug that I don't want showing up in the simulator transcript -- it would swamp everything else.
2. We could switch on alert vs. log. All the alerts (failures) go to the simulator while all of the log messages (successes) go to file.

If [C stdio-like functionality] is interesting, I will look at how to factor this in.

I thought their approach was interesting, and seemed easier to use than the VHDL FILE declaration, write, writeline approach. But mostly I was referring to their project because I believe they have a fixed number of file IDs available. I think they ran into some of the same issues we've discussed, so it would be worth a glance through their code to see how they solved these problems.

I am going to cry as I write the fixed size code - it will be ugly.

I'm never happy about making someone cry! Hopefully it turns out to be not too emotional. Unfortunately, you're right that it will be ugly. Hopefully the ugliness can be tightly contained in a few subprograms. Good luck!