Hello,
Is it a good practice to separate declaration from implementation in UVM?
Even UVM source code is not written this way.
Thanks,
Alex
In reply to Alex K.:
Finally this is a question of you coding guidelines and the readability of the code. If you have piece of code for the interface protocol implementation it might be good to use the prototypes and external implementation.
In reply to chr_sue:
In my previous company we were avoiding using header files.
Wanted to understand what is the mostly used practice.
Having header files can resolve the issues with the compilation order:
- implementation class A using class C
- implementation of class C
This compilation order would be ok if we separated declaration and implementation.
When having it in the same file, such an order would lead to an error.
I think that using “import C” prior to declaration of class A would also resolve the problem.
What do you think?
In reply to Alex K.:
Regarding your data structure you should hold all files belonging to an agent or env in one directory. In my implementations I’m using one file where I include all these files in the right order. The whole stuff represents one package. This can be compiled without any problem and imported where it should be used.
ou can find more details on this on my personal webpage www.christoph-suehnel.de.
In reply to Alex K.:
Separating the class declaration from the implementations does not serve the same purpose as it does in other languages. SystemVerilog does not have the concept of class prototypes to aid in creating separate compiled objects that will get linked together at a later point. In SystemVerilog, you put both prototypes and implementations in a package, and then import the package. You can resolve some compilation order dependencies by using forward typedefs, but everything must be resolved within the package.
As mentioned, some people find it easier to read when you separate the class declaration from the implementations. It also makes it easier to protect your code by encrypting the implementations and leaving the declarations public.
In reply to dave_59:
In reply to Alex K.:
As mentioned, some people find it easier to read when you separate the class declaration from the implementations. It also makes it easier to protect your code by encrypting the implementations and leaving the declarations public.
Dave,
Given that it certainly improves readability of code, especially for BCL (Base Class Lib) - shouldn’t there be an attempt made to do this in UVM BCL? Many a times I end up scrolling the whole 1000+ lines to find prototypes of methods in UVM BCL. Is there some mantis for this?
I can even volunteer to clean up - but given that IEEE and several others are involved, I don’t see a quick way to merge that sort of a change.
Thanks
Srini
www.verifworks.com
In reply to Srini @ CVCblr.com:
Actually, at one time, the UVM BCL was separated into header files and implementations, but developers complained about having to open up two files to modify one method, so it was collapsed. Mantis 3294.
I haven’t been following the IEEE 1800.2 committee, but I understand that they will only be releasing the reference manual. Another committee from Accellera will be maintaining the BCL. Since the two committees will likely be staffed by the same people, the Accellera committee is currently dormant.
In reply to dave_59:
Thanks for the insight Dave. I was almost sure some folks at the committee would like that idea (if not all), you confirmed that assumption :-)
I personally have been recommending the code separation, but in the same file. It will still require modification at two places per method (if it means change of the signature of-course).
I take it that due to many reasons, UVM BCL can’t be cleaned up at this stage (Assuming many do like that change).
Regards
Srini
www.verifworks.com