Identifying `reg` type in UHDM model

[hs-apotell]

There doesn't seem to be a way to identify reg type in UHDM model. The type is modeled as logic_typespec but there's nothing in the model to differentiate it with regular logic type.

module top ();
  reg a = 0;
endmodule

Surelog/src/DesignCompile/CompileType.cpp

Lines 1094 to 1108 in d5f0e26

	case VObjectType::paIntVec_TypeLogic:
	case VObjectType::paIntVec_TypeReg: {
	// 6.8 Variable declarations
	// Other net and variable types can be explicitly declared as signed.
	isSigned = false;
	if (sign && (fC->Type(sign) == VObjectType::paSigning_Signed)) {
	isSigned = true;
	}
	logic_typespec* var = s.MakeLogic_typespec();
	var->Ranges(ranges);
	var->VpiSigned(isSigned);
	fC->populateCoreMembers(type, isSigned ? sign : type, var);
	result = var;
	break;
	}

[alaindargelas]

The standard does not make any difference, that is why, they are equivalent.
Except "logic" was introduced with SystemVerilog, "reg" was there since the beginning of Verilog.

https://electronics.stackexchange.com/questions/331393/what-is-the-difference-between-logic-reg-and-wire-in-system-verilog-explainati#:~:text=There%20is%20absolutely%20no%20difference,wire%20is%20a%20signal%20type.

[hs-apotell]

I didn't say that the implementation is wrong. As per standard (and for the needs of the simulation) it is correct. But, the allModules model is incomplete because it does not reflect the source code. For instance, for rewriting a file in verilog information like this makes a difference. Holding this sort of information in the model makes it complete without negating the standard in anyway.

[Thomasb81]

The VPI object model aim to be an abstraction from the source code to deal with various notation with the same meaning. So it is not possible to regenerate the original source code from the data model in many case.

[hs-apotell]

This is a recurring comment about VPI API being one thing and us trying something different/impossible. All I have to say to that is the same that I have been saying all along - adding/extending to the standard doesn't violate the standard. VPI standard, for the most part, is about simulating a design and not for using that same representation for tooling, and so is lacking. My understanding is that the authors/maintainers of this library wishes to use the UHDM model for purposes like language server, code rewriting tools, offline design verification, and other similar tools. If that hasn't changed then it needs to be made explicit in the project description. I hope (and wish), the Universe in "Universal Hardware Data Model" includes tools and not limited to the universe of simulators only.

Our focus is on tooling for EDA engineers. We have projects - language server, graphing, and verification tools - in progress that depend on the UHDM model (or some variant of it). To support these features, we use the non-elaborated model which is non-simulating model variant. I have personally been working on separating out the elaborated and non-elaborated model so changes can be isolated and doesn't cause ripple-effect. In the process, we keep identifying parts that are incomplete in the non-elaborated model and these open issues are related to that.

[Thomasb81]

Thanks to share your mind.

Apparently we have different understanding of what mean "Universal" in this context.

My understanding of Universal in UHDM is tool compatibility : I would for example be able to write an EDA software that I use with a different vendor implementing the same API since it is standard. So once this software is available I can compile with Cadence, Synopsys, Mentor and extend those software with my feature.

If UHDM is capable or more, it is vendor specific and I will not be able to use those feature with another software vendor.

Apparently your understanding of Universal is more as a commodity database structure in which you expect to find some particular information required by your specific use-case, but not identified by the Ieee1800 standard.

With the lack of documentation and without knowing exactly your usecase, I should admit that I take Ieee1800 as a strict documentation for this project, and I try to challenge what I do not understand regarding my mind set.

Since in systemVerilog logic and reg are equivalent, there is no need to identify precisely what was in the original source code. If code generation is targeted, maybe a tool setting can help and you can produce different keyword for verilog and systemVerilog...

While for standard data, there is not need of particular documentation : user can simply refer to Ieee1800. If we add vendor specific API, I think the documentation of those extra data is probably required... To my opinion reading the yaml model is not enough and could be an huge work depending of the feature.

[hs-apotell]

I would for example be able to write an EDA software that I use with a different vendor implementing the same API since it is standard. So once this software is available I can compile with Cadence, Synopsys, Mentor and extend those software with my feature.

And nothing I proposed breaks that compatibility with other tools. I did not propose to modify the existing API. I proposed to extend it. If the other tools you talk about don't need it they can safely ignore it. Having something in the model doesn't mean every tool has to use it. Standard proposes minimum requirements not absolute, in my opinion.

If UHDM is capable or more, it is vendor specific and I will not be able to use those feature with another software vendor.

And, why is that a problem? If a tool/simulator supports specific version of the IEEE standard that doesn't mean the standard has to be locked to that version and never change because a specific tool compatibility will break. AFAIK, all known simulators support features that aren't part of the standard and that doesn't mean one can't use those tools for strictly standard complaint code.

With the lack of documentation and without knowing exactly your usecase, I should admit that I take Ieee1800 as a strict documentation for this project, and I try to challenge what I do not understand regarding my mind set.

I welcome the challenge and collaboration is great. But I am afraid, that the current VPI standard does not fulfill tool requirements. Just simply refer to the Language Server Protocol (this is also a standard, BTW) and look at all the features that a good implementation has to support and contrast that to what the standard dictates. Many of these features will be impossible to pull off with the information available.

Since in systemVerilog logic and reg are equivalent, there is no need to identify precisely what was in the original source code.

Yes, for the simulator and I did not propose to change that. For tools, that difference matters. In fact, I didn't even propose a solution to the issue at all. I merely made a request that these need to be somehow differentiated in the model. It could very well be just another field in the model that specify the true type just like how a number of other models do (like constant with vpiConstType, net with vpiNetType, and alike). That does not affect the simulator in any way, except for a few additional bytes of memory to hold the information in the model.

user can simply refer to Ieee1800. If we add vendor specific API, I think the documentation of those extra data is probably required...

I would back you on that. Documentation is required where we extend the API and/or digress from the standard in anyway. Auto code generation does make this a little difficult but surely not an impossible task.