RE: [sv-ac] RE: Mantis 1756

Manisha,

I must be somehow on a wrong wavelength, I am not sure I still
understand your question. As long as assert_off remains in effect on the
assertion, it will never run. If it it gets assert_on, it would run once
from the nearest clock tick. We may agree or not with that... I do not
have any real experience with this kind of enabling, but I could see its
usefulness, since running  such assertions from the first clock even
though it is in some initialization phase may not be usefull. On the
other hand, one could achieve the same effect by, e.g., blocking the
clock by the reset condition or something similar. 

Best regards,
ed

> -----Original Message-----
> From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com] 
> Sent: Thursday, August 16, 2007 12:19 PM
> To: Eduard Cerny; Eduard Cerny; Yaniv.Fais@freescale.com
> Cc: sv-ac@eda-stds.org
> Subject: RE: [sv-ac] RE: Mantis 1756
> 
> Ed,
> 
> 
> That is what I was asking. Is it possible that the user does 
> not want it
> to ever run if $assertoff is issued at the beginning and is effective
> till first clock ? Or this case never happens in a real design ?
> 
> Manisha
> 
> -----Original Message-----
> From: Eduard Cerny [mailto:edcerny@synopsys.COM] 
> Sent: Thursday, August 16, 2007 5:26 PM
> To: Kulshrestha, Manisha; Eduard Cerny; Yaniv.Fais@freescale.com
> Cc: sv-ac@eda-stds.org
> Subject: RE: [sv-ac] RE: Mantis 1756
> 
> Hi Manisha, 
> 
> if you do not issues asserton on that assertion, it will 
> never run. Or I
> misunderstood the question.
> 
> ed
>  
> 
> > -----Original Message-----
> > From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com] 
> > Sent: Thursday, August 16, 2007 1:06 AM
> > To: Eduard Cerny; Yaniv.Fais@freescale.com
> > Cc: sv-ac@eda-stds.org
> > Subject: RE: [sv-ac] RE: Mantis 1756
> > 
> > Hi Ed,
> > 
> > Isn't there any scenario where user would not want his assertions in
> > initial block to get executed ever if $assertoff is 
> effective at first
> > clock edge ? 
> > 
> > Manisha
> > 
> > -----Original Message-----
> > From: owner-sv-ac@server.eda.org 
> > [mailto:owner-sv-ac@server.eda.org] On
> > Behalf Of Eduard Cerny
> > Sent: Wednesday, August 15, 2007 9:47 PM
> > To: Yaniv.Fais@freescale.com; Eduard Cerny
> > Cc: sv-ac@server.eda-stds.org
> > Subject: [sv-ac] RE: Mantis 1756
> > 
> > Hi Yaniv,
> > 
> > this is only useful for concurrent assertions. Immediate 
> > assertions are
> > more like "if" statements, in procedural code. it does not 
> affect them
> > in any way.
> > 
> > ed 
> > 
> > > -----Original Message-----
> > > From: Fais Yaniv [mailto:yaniv.fais@freescale.com] 
> > > Sent: Wednesday, August 15, 2007 4:28 AM
> > > To: Eduard Cerny
> > > Cc: sv-ac@eda-stds.org
> > > Subject: Mantis 1756
> > > 
> > > 
> > > Hi Ed,
> > > 
> > > I had an action item to review your proposal regarding 
> > > $asserton/off/kill on assertions in initial block and it 
> > > seemed fine to 
> > > me regarding concurrent assertions.
> > > 
> > > These system tasks however influence also immediate 
> > assertions - The 
> > > proposal seem to refer only to assertions with leading clock 
> > > and I was 
> > > not sure from the proposal what is the intent regarding immediate 
> > > assertions, are they postponed or canceled as in current LRM ? if 
> > > postponed then when $asserton is later user are they 
> > activated in the 
> > > same timepoint ?
> > > 
> > > Thanks,
> > > Yaniv
> > > 
> > > 
> > 
> > -- 
> > 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.