I think that the only point behind the 4 tasks was to mimic those available at simulation time. If I understand correctly the discussion, it would be enough to keep elaboration error, warning and info. I personally have no objection. Regards, ed -----Original Message----- From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Gordon Vreugdenhil Sent: Tuesday, February 05, 2008 5:01 PM To: Gran, Alex Cc: Vreugdenhil, Gordon; john.havlicek@freescale.com; sv-bc@eda.org; sv-ac@eda.org Subject: [sv-ac] Re: [sv-bc] SV-AC request to review 1769 Gran, Alex wrote: > Gord, > > My thoughts on your question : Would it be "compliant" for an > optimizer to report and elab_fatal error if it does parts of > "elaboration" early? > > D4 Sec. 3.10 says > > "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." > > > So I would take that to mean the answer to your question is yes. Right - I agree. My concern is whether AC also agrees. AC has had some particular views of how things work that don't really mesh well with the generality of the rest of the language. I am concerned that there are assumptions underlying what it means to have an elab_fatal in terms of when/how that might be reported and how predictable the state of the universe might be when such a fatal occurs. My basic point in all of the questions was to raise awareness that it is valid to have *many* different approaches to elaboration and that is thus very difficult to reason about what terminating elaboration immediately even means. Given that, it isn't at all clear to me why such a strong statement is being made and what behavior *AC* expects. If they expect something predictable, I don't think that is a reasonable expectation. If they don't expect something predictable, what is the point of the hard statement? Gord. > Given > what 3.10 says I don't think there is really a concept of "early > elaboration" as far a the LRM is concerned as long as it happens prior > to start of simulation, the LRM appears to just consider it > "compilation and elaboration" > > Unless, 1769 is making a more distinct line between what is 'compile' > and what is 'elaborate' in which case I believe Sec 3.10 would need to > be modified as well. > > ~Alex > > > > > > -----Original Message----- > From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] > On Behalf Of Vreugdenhil, Gordon > Sent: Tuesday, February 05, 2008 10:59 AM > To: john.havlicek@freescale.com > Cc: sv-bc@server.eda.org; sv-ac@server.eda.org > Subject: Re: [sv-bc] SV-AC request to review 1769 > > > I have some issues with the differences between elab_fatal and > elab_error. Why does there need to be a difference between a user > directed "fatal" and "error"? > What assumptions are being made about how elaboration occurs and when > an "elab_fatal" occurs? Would it be "compliant" for an optimizer to > report and elab_fatal error if it does parts of "elaboration" early? > > I think that this distinction is treading on areas that should not be > in the LRM; there are too many potential assumptions about how and > when various aspects of elaboration occur. > > It is fine to say that if an elab_error occurs that no simulation > model is produced, but when and how that decision is made interacts > with various tool specific aspects. > > Can you give a specific example of a scenario under which AC believes > that it is important to reason about the behavior of the two forms in > a tool-independent manner that admits > *any* algorithm for elaboration? > > > At most, if the difference is preserved, I would like the language for > "elab_fatal" weakened to say that when elab_fatal occurs, the user is > not interested in further errors and an implementation MAY terminate > elaboration immediately (whatever that means). > > > Gord. > > > John Havlicek wrote: >> Hi SV-BC: >> >> In our meeting 2008-02-05, SV-AC approved the following >> request: >> >> SV-AC request that SV-BC review and approve 1769. >> >> >> J.H. >> > -- -------------------------------------------------------------------- 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Feb 5 14:25:38 2008
This archive was generated by hypermail 2.1.8 : Tue Feb 05 2008 - 14:26:01 PST