RE: [sv-ac] Re: [sv-bc] SV-AC request to review 1769

From: Eduard Cerny <Eduard.Cerny_at_.....>
Date: Tue Feb 05 2008 - 14:25:10 PST
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