Re: [P1800] Fw: BOUNCE ieee1800@eda.org: Admin request of type /^\s*approve\b/i at line 9

Hi Karen,

This is a fairly old email. It came out back in mid-February.
We now have the sv-sc in place to deal with the major issues
flagged in the assertions area.


Neil




Karen Pieper wrote:
> 
> Forwarding bounced email from John Havlicek:
> 
> 
> In the SV-AC meeting 2008-02-12, the committee voted to approve
> the following responses to Champions negative
> feedback.  The vote for each response was 8y/0n/0a.
> 
> 
> Champions Major Negative Feedback on 1995:       
> 
> This proposal is essentially creating a generate block within a
> procedural context. I'm fine with limiting this to assertion
> statements for now, but that does alleviate addressing all the issues
> surrounding generated code. For example each assertion statement is
> replicated in the loop (including nested loops) and a generate block
> label needs to be created for every instance of each. The loop
> iterator should be treated as a genvar constant within each instance
> of the assertion statement.
> 
> SV-AC Response:
> 
> This is incorrect.  The assertion is not being rewritten, and therefore
> no artificial generate block is created.  The only effect is that the
> assertion is executed several times during the same time slot.  Erik
> sent the following clarification:
> 
>   ... this proposal was specifically written (with help from your
>   co-worker Gord) to *not* treat these as generate loops, and thus avoid
>   the (very valid) issue you mention.  Can you please re-review, in
>   consultation with Gord?  Thanks!
> 
> Champions should review this.
> 
> 
> Champions Major Negative Feedback on 1728:
> 
> It seems very odd that the let statement is allowed on an immediate
> assertion, which is no more complex than a 'if' statement, but not
> allowed in any Boolean expression. I understand the SV-AC rush to add
> features to the language and limiting those features to assertions,
> but limited this kind of feature to assertions does not serve the end
> user and the language very well. If there are issues preventing wider
> adoption of this feature, let then be flushed out now.
> 
> SV-AC Response:
> 
> The original intent of SV-AC was to make this construct general, but
> since other committees did not have sufficient time budget for
> reviewing it, it was decided to limit it for assertions only.  The
> proposal is formulated in the way that it can be extended in the
> future for additional areas of usage, and it is safer to publish first
> a limited version of the proposal than to come with an insufficiently
> elaborated general proposal.  We believe that this feature is
> essential for building assertion libraries and for doing formal
> verification.  SV-AC is already responsible for elaboration of
> templates for concurrent assertions (sequence and property
> constructs), and we see it as reasonable for SV-AC to provide a
> template for immediate assertions (let construct).
> 
> 
> Champions Major Negative Feedback on 1900
> 
> This proposal needs to be addressed when it can have the full
> attention of all the committees as effects every part of the language.
> Otherwise, I feel that this enhancement goes beyond the level of
> enhancements authorized by the P1800 PAR in embedding a new language
> with SV. The number of keywords and statements being introduced can
> not be thoroughly reviewed with the resources we have for the current
> par.
> 
> SV-AC Response:
> 
> This proposal was a focal point of SV-AC this year. It generalizes the
> notion of a concurrent assertion and is a gating capability for
> building assertion libraries and for doing formal verification in
> SystemVerilog.  We believe that the main application of checkers
> belongs to the SV-AC area, though this construct is also useful for
> coverage collection, and therefore it is within the bounds of the
> P1800 PAR.  The number of introduced keywords is relatively small:
> 
> -          checker/endchecker
> 
> -          [free] checkvar
> 
> -          initial_check/always_check
> 
> If the time required for reviewing this proposal is not sufficient, we
> believe that this issue should be addressed by the WG to extend the time
> line in order to allow proper reviewing of this proposal and addressing
> the reviewers' comments.
> 
> 
> 
> ------------------------------------------------------------------------
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try 
> it now. 
> <http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 
>  >
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.