I'm only interested in solve the intra-time-unit glitches that are artifacts of arbitraty ordering of a simulator and not the design itself. So my proposal is exactly what I'm after. Matt -- Matt Maidment mmaidmen@ichips.intel.com >-----Original Message----- >From: Warmke, Doug [mailto:doug_warmke@mentor.com] >Sent: Monday, September 03, 2007 11:11 PM >To: Maidment, Matthew R; Brad Pierce; sv-bc@eda.org >Subject: RE: [sv-bc] Glitches in unique/priority case/if violations > >Hi Matt, > >That only solves the problem for glitches that happen within >a single time unit. > >It doesn't handle glitches in combinational logic that can >arise during simulations with timing delay (either gate library >cells or RTL with #1 etc. in it). > >The only way I can think of to gracefully solve the unique/priority >case/if problem is to force some sort of strobing into the picture. >This can be done via clocking events, like concurrent assertions. >Or, some form of "pulse reject" construct could be introduced. > >Regards, >Doug > > >-----Original Message----- >From: Maidment, Matthew R [mailto:matthew.r.maidment@intel.com] >Sent: Monday, September 03, 2007 11:03 PM >To: Warmke, Doug; Brad Pierce; sv-bc@eda.org >Subject: RE: [sv-bc] Glitches in unique/priority case/if violations > > > >In my opinion, there should be a class of assertions that are evaluated >at the end of the >time step in which they are triggered. The values that are sampled are >the final values for >that time step-- and no clock should be implicitly or explicitly >associated with the assertion. > >As awful as this may seem, I would propose an addition modifier to the >case statement to change >the evaluation from immediate to this new mode. Something like >postponed or observed or reuse some >keyword like assert or final. > >observed unique case (1'b1) inside > [a] out = ina; > [b] out = inb; >endcase > >assert unique case (1'b1) inside > [a] out = ina; > [b] out = inb; >endcase > >I'm not stuck on the position of a new modifier, I'm just throwing it >out there so I can >see what it might look like. > >I advocate leaving immediate assertions as they are and create this new >class to avoid >compatibility issues. > >Matt >-- >Matt Maidment >mmaidmen@ichips.intel.com > > >>-----Original Message----- >>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On >>Behalf Of Warmke, Doug >>Sent: Monday, September 03, 2007 9:40 PM >>To: Brad Pierce; sv-bc@eda.org >>Subject: RE: [sv-bc] Glitches in unique/priority case/if violations >> >>Hi Brad, >> >>I thought of this myself when I first saw Erik's proposal. >>After I read the proposal, I thought the technique he >>is proposing to deglitch those was not appropriate for >>the unique/priority case/if glitch problem. But, maybe >>there are some things that could be done. >> >>The fundamental issue with unique/priority case/if is the >>lack of a clocking specification that would be used to >>strobe the logic at appropriate times. >> >>In the immediate assertions situation, Erik is proposing to >>replace the immediate assertions with concurrent assertions. >>There are a few modifications to concurrent assertion semantics >>to make them appropriate for replacing immediate assertions. >>And by nature, concurrent assertions must be associated with >>an implicit or explicit clocking event. >> >>So, if we could oblige users to write their unique/priority >>case/if constructs in code where clocking can be inferred, >>perhaps the technology could work. >> >>But what about cases where no clocking can be inferred? >>Should those cases turn into errors? Backwards compatibility >>problems would then arise. Though backwards incompatibility >>with glitchy unique/priority detection could be argued to >>be not such a bad thing... >> >>For the assertions proposal, I think this clocking situation >>is easier. In cases where no clocking can be inferred, >>users will continue to use immediate assertions. They >>are susceptible to glitches, but at least there are no >>compatibility issues. >> >>Regards, >>Doug >> >>-----Original Message----- >>From: owner-sv-bc@server.eda.org >[mailto:owner-sv-bc@server.eda.org] On >>Behalf Of Brad Pierce >>Sent: Monday, September 03, 2007 9:07 PM >>To: sv-bc >>Subject: [sv-bc] Glitches in unique/priority case/if violations >> >>In http://www.eda-stds.org/sv-ac/hm/4668.html the SV-AC is proposing a >>possible solution for the glitch issue in immediate assertions. >> >>Is there some way that this proposal could be leveraged into >a solution >>for the glitch issue in unique/priority case/if violoations? >> >>That is, could the violations of unique/priority be defined >in terms of >>implicit immediate assertions? >> >>Erik's SV-AC proposal is at >> >> http://www.eda-stds.org/sv-ac/hm/att-4668/assertfinal070830es.pdf >> >>-- Brad >> >> >>-- >>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. >> > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Sep 3 23:15:21 2007
This archive was generated by hypermail 2.1.8 : Mon Sep 03 2007 - 23:15:29 PDT