>From: "Seligman, Erik" <erik.seligman@intel.com> >Don't forget that we may see this code in a module that has default >clocking defined-- so in that case, I think Adam's code would be fine. Hmm, I thought that the basis for having concurrent assertions in the procedural code was that the execution time of the assertion approximately matched that of the procedural code. Problems were caused because the execution times didn't quite match. Now you are suggesting that clocked assertions are OK in unclocked procedural code, where the execution times aren't even related. That doesn't make any sense to me. Also, if this was allowed before, it was with behavior completely different from what would occur with the new proposal. In general, it seems to me that trying to execute synchronous concurrent assertions from asynchronous logic isn't going to behave well. >(Not to mention the fact that with the new procedural triggering method, >we may want to relax the requirement that concurrent asserts need a >triggering clock.) Without a triggering clock, they cannot refer to anything sequential. With that restriction, and triggering when executed, they sound a lot like immediate assertions. Is there a good reason to have both? Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon May 5 13:59:50 2008
This archive was generated by hypermail 2.1.8 : Mon May 05 2008 - 13:59:59 PDT