Re: [sv-bc] RE: Mantis 2962

From: Greg Jaxon <Greg.Jaxon@synopsys.com>
Date: Wed Feb 18 2015 - 12:27:16 PST

I've also received mention of the follow topics (I've found some Mantis
items that might apply):

- Extend packages from other files:
http://www.eda.org/svdb/view.php?id=2962

Matt, could you record a few technical comments re: 2962?
These aren't necessarily for immediate discussion, but they need consideration before that would be voted upon.

---

First one big objection: the description claims that "a number of units will depend on the package [...] small change in a single implementation for package item may enforce full package recompilation and number of design units recompilation." This problem can only exist in a product which supports some sort of separate compilation for distinct components.

Yet the proposal does not explicitly describe a solution to that problem (recompilations due to dependence). If anything it makes the problem more intractable by scattering dependences that arise due to mutual recursions between two or more function definitions of the package.

The one contribution 2962 makes is to suggest extern task and function declaration, from which we must conclude that "compilation" excludes linkage and inlining (i.e. product supports a very-deep form of separate compilation). Synthesis and Verification by synthesis must ultimately implement all functions and tasks. Synthetic compilation down to the level of gates therefore retains some burden of recompilation after a package edit. In synthesis, systems currently deployed confine this problem to one of re-analyze'ing components in need of the new definitions. Until a source is analyzed, it cannot influence the assembly of a separately-compiled system. In synthesis, package dependences are carried entirely by the sequence of  HDL analyze steps.

If extern declaration is one key, the proposal should also clarify whether incomplete typedefs can defer completion to a later implementation file. The devil is also in the details of extern prototypes (are they full ANSI-style only, or would non-ANSI headers suffice?)  Does this proposal intend some specific synthesis-semantics for the new construct  I.e. would an extern function have to be realized as an unresolved reference cell? Is this a veneer being applied to describe technology libraries, or will the packaged definitions be HDL implementations intended to be synthesized?

Would the original problem statement yield to a simpler option that one could declare certain packages (containing full definitions only) as "extern" with the new meaning being that all references to the package compile down to abstract references that are not resolved until elaborate or link time?  Can tasks, functions, and parameters always be treated this way by the full range of SV products? Precisely how should the resolution rules for these deferred-references operate in the various products?

It then makes two proposals with too few details for any final opinion. Based only on "first impressions":

• Proposal #1 seems to use the import statement in a novel way that clouds the issue of whether any names have been imported from the package into the scope which contained the import. Ordinarily a selection from a package (e.g., p::t1) does not trigger the import of the name t1 into the scope where the selection appears, even if a wildcard imports from p is also pending in that scope. If the scope-operator is allowed in a declaration header, it hardly needs to be done in the context of an import statement to make it legal or unambiguous.
  
  More importantly, definitions intended for a remote package would have to appear at "global" ($unit) scope to make clear that it is expressing an irrevocable definition within the named package. Were definitions allowed in any deeper scopes, the question of whether any one definition is useable becomes confounded with the question of whether the scope that defines it is ever instantiated.
  
  
• Proposal #2, for the new keywords implementation, endimplementation appears to settle that these definitions must appear at global scope.
  
• Both proposals have to prohibit the resolution of names mentioned inside the package definitions to names in the prevailing $unit scope. Such resolutions would only further tangle the dependence paths between source files.
  
• Does anyone else find the term "endimplementation" disturbing, given that the same package implementation may be resumed elsewhere?
  "End" signifies finality elsewhere in the language. After an "endmodule", we don't typically allow the definition of the module to be extended (perhaps by adding more processes). Would "endpackage" be regarded as the final closure of the package scope – admitting just enough implementations to flesh out its definitions?
  
• The compilation flow for packages with implementations distributed in this way needs more explanation. For instance, how many package declarations would be permitted for one package_name? Are 100% redundant implementations legal? Walk me through how I'd edit the API of a function I've already compiled once... What files do I have to erase first to avoid errors and warnings?
  

Unanswered by 2962 is whether linkage-coherence depends solely upon agreement of the extern APIs?
In the context of synthesis, mechanisms that defer the brunt of the elaboration effort until final linkage sabotage the benefits of separate compilation. In effect they force re-compilation on all compilation units whose elaboration-to-gates outcome depends upon anything external to itself. While this might make for a highly flexible system, it becomes much more difficult to reason about, since compilation itself no longer settles as much logical structure as we're used to.

That weaker level of compilation effort is already available in the form of analyzed source files. Those resolve all local-scope names and all package-scope names. If the tree of dependences it leaves behind has too much connectivity, then I submit this is due to how the packages are subdivided, or how the dependences are tracked. If every function appeared in its own package, re-analyzes would be reduced to the level envisioned by this proposal. That suggests to me that tracking those dependences at the granularity of functions and tasks would suffice to reduce recompilations to the same level, with only the reanalysis of the whole package being a possibly unnecessary extra cost. Note that under the existing standard model each time a package declaration is processed, it produces a brand new package. Under proposal 2962, what happens is far less clear. Are the externs merely checked against definitions previously installed? How do you edit an API? All those messy questions are avoided by just reanalyzing the whole package. It's not like it takes much time to do.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Wed Feb 18 12:27:32 2015