Re: [sv-ac] RE: Issue 2578: Vacuity definition

Dmitry,
Here's an example:
(get_cache_status && cache_entry[addr]==INVALID |->
     request_main_mem_bus |-> main_mem_bus_ready) *implies*
(main_mem_bus_ready |-> ##[1:5] cache_entry[addr]==VALID);

To your question: My *question is why the second condition has been added.
If P1 is vacuously true, it does not mean that P1 implies P2 is vacuous.*

****
In the above example, a no request to get the cache status (P1 vacuous)
then acquiring the main bus and validating the cache entry is irrelevant.

Other conditions may have caused the update of the cache entry to other
some value.

I think that what we have is OK.
Ben

On Thu, Aug 11, 2011 at 6:18 AM, Little Scott-B11206
<B11206@freescale.com>wrote:

> Hi Dmitry:****
>
> ** **
>
> Can you provide some justification for why you think the given definition
> doesn’t work? To me this is one of those areas where sometimes you want the
> definition to be one way and sometimes you want it to be the other way. It
> sort of depends on how you look at vacuity… ****
>
> ** **
>
> I personally prefer the way it is currently written as I feel it is a
> higher bar for something to be declared nonvacuous. What you suggest allows
> the property in the antecedent to be vacuous while the overall property
> could be nonvacuous. That definition feels a bit weak to me. When I get a
> result of nonvacuous I want to know that all of the constituent parts also
> have nonvacuous evaluations.****
>
> ** **
>
> Thanks,****
>
> Scott****
>
> ** **
>
> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of *Korchemny,
> Dmitry
> *Sent:* Thursday, August 11, 2011 7:42 AM
> *To:* sv-ac@eda-stds.org
> *Subject:* [sv-ac] Issue 2578: Vacuity definition****
>
> ** **
>
> Hi all,****
>
> ** **
>
> I am sorry to reopen the discussion about a resolved issue. Should have
> done it at the last meeting. There are two problems that I would like to
> discuss.****
>
> ** **
>
> **1. **The following vacuity conditions for implies operator were
> suggested:****
>
> * If the antecedent is false, then (P1 implies P2) should be vacuous.****
>
> * Also, if the antecedent is vacuous, then (P1 implies P2) is vacuous.****
>
> * Also, if the antecedent is nonvacuous true, then (P1 implies P2) is
> nonvacuous if consequent is nonvacuous****
>
> ** **
>
> My question is why the second condition has been added. If P1 is vacuously
> true, it does not mean that P1 implies P2 is vacuous.****
>
> ** **
>
> **2. **Whatever the reply to my first question be, F.5.3.3 should be
> updated accordingly.****
>
> ** **
>
> 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. ****
>
> --
> 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.