Jump to content

UVM and reserved keywords in C++


Recommended Posts

Hello all,

 

As you may know, the Universal Verification Methodology is currently being "ported" to SystemC/C++ to better faciliate system-level and HW/SW co-verification centric use cases.

 

However, we noticed that the UVM SystemVerilog standard/API uses some methods which are keywords [1] in C++.

For example:

  • delete method in uvm_callbacks, uvm_queue, uvm_pool, etc
  • catch method in uvm_report_catcher
  • register method in uvm_factory

This means that future implementations of UVM in other languages cannot adhere to the same method names, and users are confronted with these as soon as they switch from one language to another.

 

I would highly appreciate if the UVM standardization team is willing to reconsider some of the method names, as part of the planned IEEE standardization, faciliating a better unification of the UVM API across languages.

 

Thanks,

Martin

 

 

[1] http://en.cppreference.com/w/cpp/keyword

Link to post
Share on other sites

Good catch Martin. Different method names is encouraged.

 

If my understanding is correct, I wonder if this is solvable by the C++ implementation doing a more qualified or scoped call like this.<delete|register|catch> or class::<delete|register|catch>.  Avoiding conflicts with some of these very common methods is very difficult even within the same language.  For example, if you are familiar with embedded Perl C API, it can easily conflict with Boost and standard library in C++. I just had to wrap/encapsulate libraries to avoid conflicts.

Link to post
Share on other sites

If my understanding is correct, I wonder if this is solvable by the C++ implementation doing a more qualified or scoped call like this.<delete|register|catch> or class::<delete|register|catch>.

 

No, this is not possible as C++ keywords (like catch, delete, register) are not part of scoping rules.  They are part of the grammar instead.

Therefore, I would second to rename these functions in UVM during the IEEE standardization.

 

/Philipp

Link to post
Share on other sites

I am no C++ expert, but delete() is actually a pre-defined method name for some array types in pure SV itself. So am wondering if that would have an impact somewhere or the other during this porting journey. 

 

In anycase, this in indeed a good catch and it will help if there is a way we can screen the entire UVM base code to identify all such issues (at least as many as possible) and address them.

 

Thanks

Srini

Link to post
Share on other sites

In anycase, this in indeed a good catch and it will help if there is a way we can screen the entire UVM base code to identify all such issues (at least as many as possible) and address them.

 

It should be possible to use "grep -w" (word match) for this purpose:

grep -rwE '(catch|delete|register|...)' /path/to/uvm/src

with "..." being all C++ keywords that are not already keywords in SV.  The same could be done for e, VHDL, Python, Java, ...

 

/Philipp

Link to post
Share on other sites

hi,

 

keep in mind that this requirement becomes N-way - to some extend its open ended.  we cant predict what keywords exists in other languages which at some point want a UVM implementation. 

 

>It should be possible to use "grep -w" (word match) for this purpose:

this would need to be enhanced because only the public/offcial API should be checked. neither the implementation nor the private API's should be highlighted. in addition the keywords of other languages would need to be included as well....

 

/uwe 

Link to post
Share on other sites

keep in mind that this requirement becomes N-way - to some extend its open ended.  we cant predict what keywords exists in other languages which at some point want a UVM implementation.

 

Sure, it's not possible to avoid such issues for arbitrary future languages.  On the other hand, we should still address the languages that have a UVM implementation being worked on or are likely to see such an implementation in the future.  Hopefully, people with interest in a particular language can do the check for potential conflicts and report back during the IEEE standardization process.

 

>It should be possible to use "grep -w" (word match) for this purpose:

this would need to be enhanced because only the public/offcial API should be checked. neither the implementation nor the private API's should be highlighted. in addition the keywords of other languages would need to be included as well....

 

Yes. The process can't be fully automated.  The "grep -w" suggestion from above can serve as a simple starting point to identify possible conflicts, mainly regarding the convenient "word matching" functionality to avoid false negatives where the keywords are only a part of identifiers.  You can easily exclude implementation files. Comments are not filtered either.  Still, the resulting list is hopefully short enough to be processed manually processed for "real" conflicts in the public/official API.

 

/Philipp

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...