One of the issue I am facing currently in my code is that it is really sprinkled with a lot of uvm messages.
So much so that I have probably 1:0.5 ratio between functional code and debug messages.
I can definitely control the message using verbosity level during run time but my source code is still cluttered with a lot of debug messages.
I am just curious if this is anyone has good ideas to avoid this source code clutter?
For example, I can think of using some `define macros which may help to some extent.
It looks like you did not use the verbosity level in the right way. And you should dxo this from the very beginning. The UVM reproting mechanism is so powerful. You do not really something else.
In reply to verif_learner:
It looks like you did not use the verbosity level in the right way. And you should dxo this from the very beginning. The UVM reproting mechanism is so powerful. You do not really something else.
I think that is not an issue. I am not referring to the amount of log messages in the log files. Kindly read my post and let me know if I have explain the problem properly
In reply to verif_learner:
You should supply an example of the clutter that you wish you could remove or hide in your code.
Hi,
If my question is clear then all I need is any prior experience in handling this issue. I need general input or best practice used. I am not trying to solve any specific issue.
As I mentioned, I can use `define to reduce the amount of uvm reporting code lines. If there is any other option, I would like to understand.
In reply to verif_learner:
Without seeing an example of what you call “clutter”, this is a very subjective question.
Many times I see debug messages left in code because they didn’t fully understand how it works and should have been removed once the code was working.
Also, interactive debugging may be an alternative to the “entering/exiting” messages people put in their tasks.
I do not agree with your statement. The `uvm_info macros offer us all the freedom we need to devlop, debug a UVM verification environment and running tests and regressions with the same code without modifying/removing code lines. For this reason we can use the UVM_VERBOSITY.
If you are removing code you might have to include additional lines after making modifications in your code.
Because the UVM_VERBOSITY is evaluated first there is no overhead in the simulation. The macro will not be executed if the verbosity is higher as specified from the command line.
Christolph, I do not think you understand the OP’s concern. They are fully aware of UVM_VERBOSITY and its effect on controlling output. Their issue is about the readability of the source code bloated by too placing too many `uvm_info messages which gets in the way of seeing the functional party of your code.
One of the issue I am facing currently in my code is that it is really sprinkled with a lot of uvm messages.
So much so that I have probably 1:0.5 ratio between functional code and debug messages.
I can definitely control the message using verbosity level during run time but my source code is still cluttered with a lot of debug messages.
I am just curious if this is anyone has good ideas to avoid this source code clutter?
For example, I can think of using some `define macros which may help to some extent.
I would suggest to get rid of all those messages and insert the proper comment/reasoning for the code. I have seen in various projects that messages added before and after every procedural statement.
In reply to verif_learner:
I would suggest to get rid of all those messages and insert the proper comment/reasoning for the code. I have seen in various projects that messages added before and after every procedural statement.
I do have a fair amount of comments in the code to give a good idea to original author (that is me) and for third party users (other members in the team). I do need these messages in order to debug when something fails …
After some thought, this is what I am thinking of doing in order to reduce the code bloat due to debug messages. I am planning to delegate the debug message logging to a separate function.
The source of debug messages will call the function with some token/ID. This is the first pass. If there is still an opportunity to reduce the code clutter, I will further use macro (`define) to clean up the code better.
I am used to adding interface signals only for testbench which will give state of testbench at any point in time.
Debugging using display statements is again a manual check. If you need debugging in RTL code, appropriate amount of checkers should do. Or else you want to debug testbench status, above method of using interface makes debugging testbench with waveforms easier.
To design self debugging testbench also come up with check points your testbench could break and write checks (e.g. timeout counters for a event, assert(STATE) at appropriate point to see if testbench/rtl reached certain state, etc.)
To debug a code with `uvm_info is something and to write a debug friendly code is something else, I think!
In reply to verif_learner:
I am used to adding interface signals only for testbench which will give state of testbench at any point in time.
Debugging using display statements is again a manual check. If you need debugging in RTL code, appropriate amount of checkers should do. Or else you want to debug testbench status, above method of using interface makes debugging testbench with waveforms easier.
To design self debugging testbench also come up with check points your testbench could break and write checks (e.g. timeout counters for a event, assert(STATE) at appropriate point to see if testbench/rtl reached certain state, etc.)
To debug a code with `uvm_info is something and to write a debug friendly code is something else, I think!
Interface signals can only help you to some extent. The instantaneous state of the interface can be very well checked using these. What happens when that interface carries a packet. Hard to debug traversing cycle by cycle trying to make sense from bytes of data.
Debugging is always a manual step. The only question is the abstraction level at which one wants to debug - signals, transactions, packets, messages. So, I don’t understand what you mean by - Debugging using display statements is again a manual check.
The test bench is self checking (I don’t know if self debugging test benches exist, yet).
The question here is, what happens when a check fails. How do you go from a known failure to the root cause. You will need a lot of information to keep tracing back to the point of failure.
This is the reason source level debuggers exist in both SW and HW discipline. But those debuggers should not be the first line of analysis, in my view, but should be the last resort.
Debugging is always a manual step, where you have to be very constructive. Simple signal compares are not the right way you should debug ond observe your design and the testbench. The higher the level of abstraction is the amount of data will be reduced. And we have very different ways of debugging. All regular processes you should check with SVA and data compares should be done on the transaction level. Internal staes in the RTL, like FSM, FIFOs etc. can be also checked with SVA.
And you should really deal with the verbosity using the UVM reporting mechanism to issue data for the right level of development/debugging. I did not see a self-checking testbench but I saw automatic chekcers like scorboards. The right mixture of the different methods is the solution for your debugging problem. And debugging requires a certain kind of understanding. You can try to develop this but it is near impossible to teach this, because people are behaving so differently.