Re: [sv-ac] 3478 : Why is this not addressed? // sv'09 fails to solve this issue

Hi Dmitry,

The proposal should be worked on in the svac and then sent to the svec and
svbc for review. The only reason it would be transferred to another
committee is if that other committee wanted to take it over from the svac.

I don't see this mantis item in your list of top issues for this PAR.
Are you considering this to be something that is required in order to
complete a mantis on your top list or is this something new?

The Working Group should be made aware of new mantis items that the svac would
like to work on. My understanding is that the svac is already concerned about
being able to complete its work by the end of September.

Neil

On 04/27/11 05:58, Korchemny, Dmitry wrote:
> Should I move it to SV-BC or SV-EC?
>
>
>
> Thanks,
>
> Dmitry
>
>
>
> *From:* Bresticker, Shalom
> *Sent:* Wednesday, April 27, 2011 15:50
> *To:* Korchemny, Dmitry; 'sv-ac@eda-stds.org'
> *Subject:* RE: [sv-ac] 3478 : Why is this not addressed? // sv'09 fails
> to solve this issue
>
>
>
> This is a more general need.
>
>
>
> It would be beneficial in testbenches as well.
>
>
>
> Shalom
>
>
>
> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of
> *Korchemny, Dmitry
> *Sent:* Tuesday, April 26, 2011 11:48 PM
> *To:* 'sv-ac@eda-stds.org'
> *Subject:* FW: [sv-ac] 3478 : Why is this not addressed? // sv'09 fails
> to solve this issue
>
>
>
> Forwarding Ben’s letter.
>
>
>
> Dmitry
>
>
>
> *From:* ben cohen [mailto:hdlcohen@gmail.com]
> *Sent:* Thursday, April 14, 2011 02:34
> *To:* Korchemny, Dmitry
> *Subject:* [sv-ac] 3478 : Why is this not addressed? // sv'09 fails to
> solve this issue
>
>
>
> On http://www.eda-stds.org/svdb/view.php?id=3478
>
> I feel that his is an important issue that needs to be addressed. The
> basic issue is that if you have a bidirect, an assertion from inside the
> DUT would not work all the time when the DUT is instantiated in a higher
> level of hierarchy:
>
> dut_io: assert property(@ (posedge clk)
>
> !oe |-> io_data==16'bZ );
>
> // Actually, when !oe, then io_data == whatever is externally driven.
>
> Similarly, from outside the DUT, when the DUT is instantiated,
>
> outside_dut1: assert property(@ (posedge clk)
>
> time4dut1_to_drive |-> io_data==whatever_dut1_is_driving );
>
> // However, the /whatever_dut1_is_driving/ cannot currently be easily
> expressed without digging into the DUT's internals.
>
> http://www.eda-stds.org/svdb/view.php?id=3478 was addressed to me by an
> EDA formal verification company, and I can see the need to express to
> express the internal and external driving value. I am the champion on
> this mantis; however, because of the new IEEE rules, I am de-championed.
> Someone should carry this Mantis. I also believe that the IEEE should
> allow guest speakers (by invitation only) in the meetings to address
> or explain certain technical concerns. In my case, I wrote this mantis
> 3478 and3195.
>
> Thanks,
>
> Ben Cohen
>
> ps. I hope that you're allowed to at least respond.
>
> ---------------------------------------------------------------------
> 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, and is
believed to be clean.