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.