Greg Jaxon wrote: > Much as I agree with this sentiment, it compromises such > definitions as compile-time constant vs elaboration-time constant. But Verilog makes no such distinction. There is no VHDL like differentiation between "locally static" and "globally static". Expressions are either "constant expressions" or not. SV did make things slightly murky with "const" declarations which are not permitted as "constant expressions" but that is a different issue. The only time the phase "compile time constant" is used, the context permits specparam references which are clearly "elaboration" time values since they can depend on parameters. It is perfectly legal for an implementation to "partially elaborate" a design and produce "elaboration" errors during what the user perceives as "compile time". Similarly, errors/warnings that the LRM currently says are "compile time" are clearly sometimes "elaboration time". As one trivial example, 6.22.2 in the combined LRM says: No type checking is done by the compiler, except to check that the destination variable and source expression are singulars. How does enforce singular types at "compile time" if the types are module type parameters? Perhaps you were trying to get at something else. Could you clarify with an example of what you believe is compromised by my description? Gord > > Gordon Vreugdenhil wrote: >> Generally, I thought that the 3.8 section was quite good. The >> wording is fairly careful about indicating that compilation >> and elaboration can be intermingled. >> >> A couple of comments. First, the following could be a >> bit misleading: >> >> Beyond the rules defined for compilation units (see 3.8.1), this >> standard does not define how implementations should perform >> compilation and elaboration. >> >> There are other places in which behavior is specified in >> algorithmic manners. For example, the rules for upwards name >> resolution really do define a "how". So do the net resolution >> rules for determining the dominating net type and the rules >> for generate instantiations. There are likely to be other examples >> if the elab-time assertions come into play. I assume that >> this comment was addressing just the "file" semantics of compilation >> units, but I think that the reference here is a bit too subtle. >> >> I think that I'd like to rephrase this a bit and tie it in >> with the subsequent note: >> >> NOTE—throughout this standard, the terms compilation, compile and >> compiler often refer to the combined compilation and elaboration >> process. >> >> >> Perhaps something like the following: >> >> Although this standard defines the results of compilation and >> elaboration, the compilation and elaboration steps are not >> required to be distinct phases in an implementation. Throughout >> this standard the terms compilation, compile and compiler normally >> refer to the combined compilation and elaboration process. So, >> for example, when the standard refers to a "compile time error", >> an implementation is permitted to report the error at any time prior >> to the start of simulation. >> >> The "file" semantics of compilation units really addresses a >> different issue -- that SV normally doesn't care about order >> and context of design unit compilation except in a couple >> of cases. 3.8.1 deals with a context issue; the main ordering >> requirement is in 25.2.1 where it is clearly stated that packages >> must "exist" before their items are referenced. Perhaps the "exist" >> should be modified there to read "compiled" with a bit of discussion >> that this really does mean "compiled" and not the weaker "compiled or >> elaborated" interleaving that is normally permitted. In reality this >> gets into library issues and since SV doesn't really have a strong >> library concept, it is difficult to be precise. >> >> I think that we could address both issues by adding something >> like the following: >> >> This standard does not normally specify requirements regarding the >> order of compilation for design units. The two exceptions are >> the rules regarding "compilation units" (see 3.8.1) where >> actual file boundaries during compilation are significant, and the >> rules regarding references to package items (see 25.2.1) where >> the compilation of a package is required to precede references to it. >> >> Gord > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Apr 2 10:35:46 2007
This archive was generated by hypermail 2.1.8 : Mon Apr 02 2007 - 10:35:53 PDT