Description

In order to make the development/debug of the ROM code easier and also bring more flexibility to the traces we want to print out, it'd be useful to introduce multiple levels of logging. We're talking about levels such as debug, info, warn, error and fatal. When running in a simulation environment, we might want to enable only a few traces given each one slows down the execution. The expectation may be different in an emulation environment where speed of execution isn't a bottle neck and we need more logs to help debug the code that runs.

Looking at the existing solution in the code, I could find a log API defined here, but this seems to be tied only to the tests.

Do we want to reuse this API and plug a different backend (implementation of base_log_internal_core()), or is it more appropriate to start from scratch in a different location?

One follow up question is about the expectation of what should be printed out. The existing log API prints out the file name and line number where the log came from, but for security reason, we might want to limit the output to the log itself with only an indication about the severity.

Other aspect, in a production environment, we might want to avoid printing most of the logs except some very generic ones (that wouldn't impact overall security). We could introduce a similar mechanism to what is already implemented here in order to print or not depending on a level of confidentiality. One difference though, the selection shouldn't be performed at runtime given we wouldn't want to embed critical log information into the generated binary.