Log, Alert and Affirm in OSVVM

[Hassan]

The AlertLogPkg contains three type of functions:

Log; this has following levels: ALWAYS, DEBUG, FINAL, INFO, PASSED

Alert; this has following variants: Alert, AlertIf, AlertIfNot, AlertIfEqual, AlertIfNotEqual, AlertIfDiff. THe alert has following levels: FAILURE, ERROR, WARNING.

Affirm; this has following variants: AffirmIf, AffirmIfNot, AffirmPassed, AffirmError, AffirmIfEqual, AffirmIfNotEqual, AffirmIfNotDiff, AffirmIfTranscriptsMatch, AffirmIfDiff. When the affirm fails, an ERROR is raised.

Now questions arise because there is a level of overlap between these different categories. Now getting to the questions.

Q1. For log messages, what is the idea behind the different levels of log? Certainly we can enable and disable different log levels using SetLogEnable. The ALWAYS and INFO is self explainatory in meaning. But, when does one use these different levels: DEBUG, FINAL, PASSED?

Q2. Why does one need “Alert” functions when “Affirm” functions also exists? I am saying this since both of them are performing a check and then taking an action. The affirm prints a log message

Q3. Since “Affirm” functions combines Log and Alert, Why are levels: ALWAYS, DEBUG, FINAL, INFO, PASSED and FAILURE, ERROR, WARNING, not available for “Affirm” functions?

[Jim Lewis]

> Q2. Why does one need “Alert” functions when “Affirm” functions also exists?
Alert is for parameter checks – like is max >= min. These are properties that if violated, the design (or test case) is broken.

Affirm is for self checking. Each check is counted. A test quality is a function of the number of checks and we report that.

> Q3. Since “Affirm” functions combines Log and Alert, …
AffirmIf uses “alert ERROR” for test failures and “log PASSED” for test passed.

> Q1. For log messages, what is the idea behind the different levels of log?
ALWAYS – Always prints. Cannot be disabled by SetLogEnable.
INFO – Transaction level details of what a VC is doing
DEBUG – Detailed operational level of what a VC is doing for extended debug
FINAL – Messages that only need to be printed to collect test artifacts, but do not need to be printed normally. Intended for methodologies like DO-254.
PASSED – Only intended to be used by AffirmIf when a check passes.

[Hassan]

That means normally we would not need to use Alert, but only the Affirm functions?

By the way, I did attend your course on OSVVM many years ago, before COVID. I was quite unwell in that week when I attended and could not absord the finer points. I had one more colleague with me. That colleague left a few wekks later and a redundancy drive a few months drove most hardware engineers away by choice or otherwise. I left that organization as well. I am looking at OSVVM again for my current project.

[Jim Lewis]

I use alerts in protocol checkers. If a VC receives a transaction done event when a transaction is not active, that is an alert and not an affirmation – think of the older intel X86 interfaces that used the signal nRdy to indicate a transaction is complete – receiving a stray nRdy is a bad thing.

[Author]

Posts