Actually, I made a mistake that Surrendra pointed out to me: if e.triggered is sampled, it will have false in the next time step, because triggered holds true only till the end of the time step where e occurred and sampling happens in preponed region. You can use @e as a clocking event in an assertion. ed From: danielm [mailto:danielm@aldec.com.pl] Sent: Monday, March 17, 2008 10:17 AM To: 'Eduard Cerny'; 'Lisa Piper'; sv-ac@eda-stds.org Subject: RE: [sv-ac] event triggered in concurent assertion Here we have situation : event - forbidden in concurecnt assertion - has no value event.triggered - allowed. There is similar situation for : string - forbidden in concurent assertion ???? string.len - should be allowed???? string.getc - should be allowed???? class_handle - forbidden in concurent assertion ??? class_handle.method - should be allowed???? The only condition for such methods calls in concurent assertion should be that the method is const, but SV unfortunatelly do not define contant methods. DANiel ________________________________ From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] Sent: Monday, March 17, 2008 2:35 PM To: danielm; Lisa Piper; Eduard Cerny; sv-ac@eda-stds.org Subject: RE: [sv-ac] event triggered in concurent assertion I see... e.triggered is a boolean that is true from the time the event is triggered till the end of the time step. So in principle I do not see a problem, except that since all variables are sampled, you would see the e.triggered as true only in the subsequent time step and only there. So, catching it in a concurrent assertion becomes a little tricky. It is probably better to transform it in an always block into something more persistent first. ed From: danielm [mailto:danielm@aldec.com.pl] Sent: Monday, March 17, 2008 9:26 AM To: 'Lisa Piper'; 'Eduard Cerny'; sv-ac@eda-stds.org Subject: RE: [sv-ac] event triggered in concurent assertion I think that here we have a misunderstanding - my question was about event triggered poperty (not the sequence one). You cannot use ended on event. So i'm repeating the question: LRM specifies that using event in concurent assertion is forbidden - but how about using triggered property? LRM do not precise that. module top; bit precond; event e; assert property (@(posedge clk) precond |-> e.triggered); endmodule DANiel ________________________________ From: Lisa Piper [mailto:piper@cadence.com] Sent: Monday, March 17, 2008 1:35 PM To: Eduard Cerny; danielm; sv-ac@eda-stds.org Subject: RE: [sv-ac] event triggered in concurent assertion Hi Ed, Is there a reason you cannot use e.triggered in a concurrent assertion versus e.ended? I thought you could use e.triggered anywhere you can us e.ended? Lisa ________________________________ From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Eduard Cerny Sent: Monday, March 17, 2008 7:41 AM To: danielm; sv-ac@eda-stds.org Subject: RE: [sv-ac] event triggered in concurent assertion Daniel, in this case e.ended is allowed. .triggered is to be used outside assertion or in disable iff. Regards, ed From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of danielm Sent: Monday, March 17, 2008 5:26 AM To: sv-ac@eda-stds.org Subject: [sv-ac] event triggered in concurent assertion LRM specifies that using event in concurent assertion is forbidden - but how about using triggered property? LRM do not precise that. module top; bit precond; event e; assert property (@(posedge clk) precond |-> e.triggered); endmodule DANiel -- 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.Received on Mon Mar 17 07:34:39 2008
This archive was generated by hypermail 2.1.8 : Mon Mar 17 2008 - 07:34:57 PDT