Turn spurious IP upgrade warnings into info messages

[jhegeman]

When using the upgrade_ip TCL command on an IP core that does not
need upgrading, a warning is issued:
'WARNING: [Coretcl 2-1042] No IP was identified for upgrade.'
This is distracting when scraping the output for real warnings. This
commit turns those warnings into info messages.

[alessandrothea]

Hi @jhegeman, good point. Thank you for bringing it up.
Regarding the fix, changing the severity level is best done in the ipbb command code, for example:
https://github.com/ipbus/ipbb/blob/master/src/ipbb/cmds/vivado.py#L352

[jhegeman]

Sure. I can do that too. I consider this more fundamental than the command level, personally, and more intrinsically part of 'how things should be done' under the hood.
I'll move this to the command level. (The advantage is that that is more uniform, also potentially across generators.)

[jhegeman]

Ahum... Actually it is not that easy. As the documentation for set_msg_config says:
"Message configuration rules apply to the current project and are passed automatically to subordinate processes, such as synthesis and implementation runs." (Emphasis mine.)
So one has to create the project before one can adjust the message severities. This means that some more restructuring is required to be able to drive the message severities from the command level in the project generation step.

[jhegeman]

So... I had another look.
I basically see three approaches:

• If one considers this message suppression/redefinition equally fundamental as the upgrade_ip command, this should be hard-coded in the generator. Just as the upgrade_ip command is.
• If one considers this message suppression/redefinition 'almost' as fundamental as the upgrade_ip command, but more like a customisation of the command behaviour, this should be implemented as an additional parameter to the generator's write() method.
• If one considers this message suppression/redefinition something that the build tool should not do, but that should be defined in the user project, it could be done in a setup file, and customised per project.

Personally I lean towards the first of the above. The upgrade_ip command is what leads to these spurious messages, and it is at that point that it should be addressed.
On the other hand, one could also defend the point of view that the tool (in this case Vivado) knows best, and that it is up to the user (and not the build tool) to redefine the message behaviour, if they so desire.

The question is: which approach to adopt for ipbb?