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.Received on Mon Sep 3 21:40:04 2007
This archive was generated by hypermail 2.1.8 : Mon Sep 03 2007 - 21:40:13 PDT