The motivation for why those constructs are needed would help as well,
particularly when combined with what will likely be very problematic
compositions with procedural instantiations. Expected "lifetime" of the
implied processes, visibility, etc. will all need to be defined and the
expectations and basic semantics from the AC will be needed before any
substantive work could be done by BC.
Gord.
On 11/16/2010 7:54 AM, Rich, Dave wrote:
>
> Dmitry,
>
> Most of these items have no proposals yet. Can you or someone on the
> SV-AC add some notes to the issue that explains the current thinking
> in the committee? It would also help to state what the concern was
> that made the SV-AC ask the SV-BC to review them so we don't have to
> guess.
>
> Dave
>
> Dave Rich
> Verification Technologist
> Mentor Graphics Corporation
> *New Office Number: 510-354-7439*
>
> *Twitter-32* <http://www.twitter.com/dave_59>***Technorati-32*
> <http://go.mentor.com/drich>
>
> *From:*owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of
> *Korchemny, Dmitry
> *Sent:* Tuesday, November 16, 2010 2:00 AM
> *To:* Maidment, Matthew R; sv-bc@eda.org
> *Cc:* sv-ac@eda.org; neil.korpusik@oracle.com; Karen Pieper
> *Subject:* [sv-ac] RE: Cooperation request in definition of simulation
> semantics of emerging checker constructs
>
> Thanks,
>
> Dmitry
>
> *From:*Maidment, Matthew R
> *Sent:* Tuesday, November 16, 2010 11:58 AM
> *To:* Korchemny, Dmitry; sv-bc@eda.org
> *Cc:* sv-ac@eda.org; neil.korpusik@oracle.com; Karen Pieper
> *Subject:* RE: Cooperation request in definition of simulation
> semantics of emerging checker constructs
>
> I will add a brief review of these issues to the agenda for the next
> SV-BC meeting and assess how SV-BC involvement in AC matters will
> impact to the WG's approved SV-BC goals.
>
> Matt
>
> *From:*owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of
> *Korchemny, Dmitry
> *Sent:* Tuesday, November 16, 2010 1:25 AM
> *To:* sv-bc@eda.org
> *Cc:* sv-ac@eda.org; neil.korpusik@oracle.com; Karen Pieper
> *Subject:* [sv-ac] Cooperation request in definition of simulation
> semantics of emerging checker constructs
>
> Hi SV-BC,
>
> SV-AC is starting working on the following checker enhancements:
>
> ·2093: Checker construct (Mantis 1900) should permit output arguments
>
> ·3034: Allow continuous and blocking assignments in checkers
>
> ·3033: Allow procedural control statements in checkers
>
> ·2743: Allow subroutine_call_statement in a checker
>
> ·2751: P1800-2009: checker formal arguments may not be connected to
> interfaces // WHY
>
> These enhancements have been approved by the Working Group and are
> targeted for the current PAR. The implementation of these enhancements
> is related to definition of a consistent simulation semantics for the
> new constructs and may have an implication on the rest of the
> language. SV-AC requests your help and cooperation in reviewing and
> discussing relevant parts of the emerging proposals to keep
> SystemVerilog language consistent and to reduce the changes to the
> absolute necessary minimum.
>
> Thanks,
>
> Dmitry
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> --
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.
-- -------------------------------------------------------------------- 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.Received on Tue Nov 16 17:16:28 2010
This archive was generated by hypermail 2.1.8 : Tue Nov 16 2010 - 17:18:58 PST