Hi Arturo, Thanks for taking a look. In that example, I had clk defined as an argument to the covergroup. I thought that the clocking event @(posedge clk) would refer to the formal argument (ref logic clk), not to any external definition of clk. I even tried an example to make sure this would work, and it did seem to work for me. Is this correct? Thanks, Tom Arturo Salz wrote: > Tom, > > This proposal clears up all my prior issues. > One thing I'd like to point out is that in the first example of section > 16.18.6 (see below) > covergroup cg_active (ref logic clk, ref logic active, ref bit > active_d1) > @(posedge clk); > As the covergroup declaration lies outside the checker, its clocking > event is bound to the "clk" signal visible at the covergroup declaration > site. While this doesn't represents a fundamental problem, it does > deviate fro the intent of the original proposal in which the clocking > expression was bound to the checker port. > From a methodology perspective, this may not be the best mechanism and > perhaps the proposal should mention that. > > Arturo > > -----Original Message----- > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of > Thomas Thatcher > Sent: Thursday, February 21, 2008 5:33 PM > To: Gordon Vreugdenhil > Cc: Steven Sharp; dmitry.korchemny@intel.com; > Mehdi.Mohtashemi@synopsys.COM; sv-ec@eda-stds.org; sv-ac@eda.org > Subject: Re: [sv-ac] Re: [sv-ec]e-mail ballot Closes Wednesday February > 20 2008, 11:59pm PST > > Hi Gord, > > I have re-written the proposal to allow only covergroup instances within > > a checker. Take a look and see if that answers some of the most serious > > problems. The proposal is attached. > > Thanks, > > Tom > > Gordon Vreugdenhil wrote: >> >> Steven Sharp wrote: >>>> From: Gordon Vreugdenhil <gordonv@model.com> >>>> But that is immaterial to my question. If you have an auto > declaration >>>> in the enclosing scope, can a checker instance refer to that? No >>>> one has (yet) made any restrictions regarding the resolution rules, >>>> so I am assuming that the answer is yes. >>> In defense of this part of the proposal, I think the same issue > arises >>> for static variable initializers. An initializer on a local static >>> variable could be within the scope of an automatic variable, and I > don't >>> see anything in the LRM restricting it from referencing one. > However, >>> clearly it cannot be allowed to do so. Automatic variables are > created >>> by procedural execution entering their scope, and static variable >>> initializers are not executed in the context of a procedural entry > into >>> the scope. >> >> I agree on both fronts. My concerns are mostly that while I can >> reason about why something like: >> initial begin:b >> automatic int x = 1; >> static int y = x; >> ... >> should be illegal, it is harder for me to reason about things >> in the AC space since in various contexts more "synthesis" >> like behaviors seem to be expected and I haven't quite gotten to >> a point where I can predict what AC expects the behavior to be. >> >>> If concurrent assertions and checkers in procedural code were > similarly >>> static objects, independent of any procedural execution of the code, > then >>> things would be simplified. However, Mantis 1995 and 2110 break that >>> conceptual model. >> This is also what I'm struggling with. Some of the aspects >> of checkers appear to in fact be static (the text requires >> that for checker variables, etc), but it isn't quite clear >> to me yet exactly what the boundaries are and whether those >> boundaries are well formed. >> >> Part of my difficulty lies in lack of time to get everything in >> my head; part of it is also that various relevant pieces of >> the semantics and rules appear to be distributed in a half-dozen >> Mantis items and I don't know what is all relevant. >> >> Gord. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Feb 22 08:49:34 2008
This archive was generated by hypermail 2.1.8 : Fri Feb 22 2008 - 08:50:41 PST