Doug, I can give the user perspective. I would like the meaning of the ignore clause to be identical between when I run the simulation and when I view the results (which could be an entirely separate run). It seems plausible that the restriction on constant expressions is required to enforce the results being identical. I *would* like to be able to specify the value of the constant for a given run (in the code would be best); I think that is what instance constants would do for me. If there is a way to enforce the constant behavior of the ignore clause without the current restriction, then from a user's standpoint, it would be OK to remove the restriction. Mark -----Original Message----- From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Warmke, Doug Sent: Sunday, May 06, 2007 4:48 PM To: sv-ec@eda.org Subject: [sv-ec] New Mantis item on Coverage: bins rhs non-constant expressions Hi All, I've uploaded a new Mantis item http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0001802 Following is the Mantis Description, reproduced for convenience. Comments, anyone? Based on feedback, I can either create a proposal for this issue, or close the Mantis as "Not to be fixed". Consider this testcase: class myclass; int id; int ign_id; covergroup cg; coverpoint id { ignore_bins ign = {ign_id}; } endgroup endclass The P1800-2005 LRM currently states, in 18.4: The open_range_list used to specify the set of values associated with a bin shall be constant expressions, instance constants (for classes only), or non-ref arguments to the coverage group. Thus, the above testcase is illegal. Is this overly restrictive? The need for requiring constant expressions isn't clear. It would be possible to accept non-constant expressions, and take a "snapshot" of the expression value at covergroup construction time. There may be some subtelties involved, such as function calls with side effects as part of the expression. This should be considered, but we think it won't be a showstopper. Non-constant variables could easily be handled, in any case. One clear fact is that the expressions used on the rhs of coverage bins must not be allowed to vary with time after the covergroup is constructed. Regards, Doug -- 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 May 7 06:35:49 2007
This archive was generated by hypermail 2.1.8 : Mon May 07 2007 - 06:36:22 PDT