[P1800] SV-AC feedback on Champions feedback

> 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.
> 
> -- 
> 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.
> 
> 



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


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