Hi John, I uploaded a new proposal to implement Yaniv's correction. The document is 2088_covergroups_20081029.pdf It should be ready for vote. Tom Fais Yaniv wrote: > Thanks Tom and Dmitry, > > I understand this works inside checker the same as inside module which > is good, > I have also reviewed the new proposal and it looks good and the two new > examples explains this well. > > one minor editorial note: remove one of "the the" from the following > text in the proposal. > > IF Mantis 2089 is accepted > A covergroup may also be triggered by a procedural call to its sample() > method (see 18.8). Inside a checker, > the the call > > > Yaniv > > > -----Original Message----- > From: Thomas.Thatcher@Sun.COM [mailto:Thomas.Thatcher@Sun.COM] > Sent: Monday, January 28, 2008 23:56 > To: Fais Yaniv > Cc: Korchemny, Dmitry; sv-ac@eda.org > Subject: Re: [sv-ac] ballot result on 2088 > > Hi Yaniv, > > Thanks to Mantis 2149, you are now able to override the sample() method > to allow arguments. Your example would get the sampled value, because > the sampled value is passed to the sample() method. > > However, if you used the default sample() method, with no arguments, the > covergroup would see the current values of it's covergroups and sigals > when it is executed. So, there's going to be a right way and a wrong > way to write covergroups. Note that this works the same way as it would > in a module. > > > Regarding calling of the sample() method from a function called from an > always_check. What is the problem with that? It's pretty much > equivalent to calling the sample() method from an always procedure in a > module. > > Tom > Fais Yaniv wrote: >> Hi Dmitry and Tom, >> >> I'm not sure I understood how this works, consider this example: >> >> checkvar logic [0:10] cv = 0; >> always_check @(clk) >> cv <= cv + inp1; >> cover property (evt1 ##1 (evt2 && cv>10,cg.sample(cv))); >> >> which value of "cv" is seen inside the covergroup ? is it the preponed > >> value seen by the assertion or the updated value assigned in the >> Observed region ? >> I would like this to be the preponed value so sampling of "old" values > >> from assertions would be enabled the same as it is for modules (see >> mantis 2149) >> >> >> Another point: >> >> is it possible to write this code for calling .sample() from within >> always_check ? >> >> function logic f_dummy; >> cg.sample(); >> return 1; >> endfunction >> >> checkvar dummy; >> always_check @(posedge clk) >> dummy <= f_dummy(); >> >> if so then it should be defined, in my opinion this can be disallowed. >> >> >> Yaniv >> >> >> -----Original Message----- >> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of >> Korchemny, Dmitry >> Sent: Monday, January 28, 2008 16:01 >> To: Thomas.Thatcher@sun.com; sv-ac@eda.org >> Subject: RE: [sv-ac] ballot result on 2088 >> >> Hi Tom, >> >> Please, see my comments below. >> >> Thanks, >> Dmitry >> >> -----Original Message----- >> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] >> On Behalf Of Thomas Thatcher >> Sent: Thursday, January 24, 2008 2:00 AM >> To: sv-ac@server.eda.org >> Subject: Re: [sv-ac] ballot result on 2088 >> >> Hello everyone, >> >> I'm trying to work through the different scheduling cases: >> Here is what I know so far: >> >> 1. Continuous check bits are never sampled. (Mantis 1900, 16.18.6.2) >> They are updated by the continuous assignment in the Observed >> region >> (Mantis 1900, 16.18.6.4) >> 2. Sequential check bits are sampled in the Preponed region, as the >> regular variables are. (Mantis 1900 16.18.6.2) >> Dmitry, >> This statement is kind of broad: Does this mean that any > reference >> to a sequential check bit (from a final block, or a cover group, >> for >> example) will see the sampled value? Or is this statement just >> talking about what happens in the original constructs allowed in > a >> checker? i.e. Assertions, continuous check bit assignments, and >> non-blocking check bit assignments. >> [Korchemny, Dmitry] The intention was about those constructs where >> sampled values of variables are expected, e.g., concurrent assertions >> use sampled values of their arguments. It is written in Mantis 1900 >> 16.18.6.1, page 21, that "All variables participating in the >> right-hand side of a checker variable assignment are sampled, except >> the continuous check bits". In all other cases unless it is stated >> explicitly, the current values are used. I will clarify the statement >> in Mantis 1900 >> 16.18.6.2: >> >> "Sequential check bits (see 16.8.5.1) are sampled in the Preponed >> region, as the regular variables are." -> "Sequential check bits (see >> 16.8.5.1) referenced in concurrent assertions and in the right-hand >> side of the checker variable assignment, are sampled in the Preponed >> region, as the regular variables are." >> >> I also added a clarification to 16.4: >> >> "The values of variables used in assertions are sampled in the >> Preponed region of a time slot, and the assertions are evaluated >> during the Observe region." -> "The values of variables used in >> assertions are sampled in the Preponed region of a time slot (except >> for continuous check bits in checkers, which are not sampled, see >> 16.18.6.2), and the assertions are evaluated during the Observe > region." >> The sequential check bits are also performed in the observed > region >> (Mantis 1900, 167.18.6.4) >> >> 3. Other variables are not necessarily sampled, unless they appear in >> an assertion, or in a checker assignment. >> >> [Korchemny, Dmitry] This is true for all variables. >> >> 4. The covergroup usually samples its arguments at the time when it > is >> triggered. The covergroup can be triggered by an event, or by a >> function call. >> >> Here is a list of possible cases: >> >> 1. The covergroup sampling event is @(posedge clk). As long as clk > is >> not ultimately driven by a non-blocking assignment, and any >> checker inputs are ultimately driven by non-blocking assignments, >> there should be no race condition, and the covergroup will always >> see the old values of any signal that it observes (whether > checker >> input, continuous check bit, or sequential check bit) >> >> if clk is ultimately driven by a non-blocking assignment, or a >> checker input is driven from a blocking assignment, then there > will >> be a race condition. The value of the checker input will be >> non-deterministic. However, this is no different from what occurs >> outside a checker. >> There still will be no race for check bit values, because these >> are not updated till the observed region. >> >> 2. The covergroup sampling event is a function. The function could > be >> called from an procedural block, from an assertion action block, >> or from a sequence match item. >> >> a) Dmitry, do you think it's possible to call a sampling function >> from an always_check block? It would probably not be easy. It >> would probably have to be done like this, because you allow only >> assignments within an always_check: >> >> checkvar dummy; >> always_check @(posedge clk) begin >> dummy <= cg.sample(); >> end >> >> [Korchemny, Dmitry] I don't think it is possible at all. sample() is >> void method, therefore it cannot be used in the right-hand side of the > >> assignment (as far as I understand it). >> >> b) If the sample() method is called from an assertion action > block >> or from a sequence match item, the processing occurs in the >> reactive >> region. There is no race condition, but the covergroup will > always >> observe the updated values of any variables, including checker >> inputs, continuous check bits, or sequential check bits. >> (Unless Dmitry confirms above that he intended any reference to >> check bits to use the Preponed sampled value [Korchemny, Dmitry] >> No, this is not the case, see my comment above. ) >> >> Again, this behavior is consistent with what already exists. >> >> >> Do we want to specify that any covergroup appearing in a checker will >> always see Preponed region sampled values? This means that covergroup > >> constructs will work differently inside a checker than outside a >> checker. >> >> [Korchemny, Dmitry] I like the idea to be able to sample CG values in >> the Preponed region, but I don't think it is directly related to >> checkers and may be subject of a separate proposal (targeted for one >> of the future releases). >> >> Have I forgotten any cases? >> >> [Korchemny, Dmitry] I don't see other use cases, either, therefore I >> believe that your CG definition in checkers is sound. >> >> Thanks, >> >> Tom >> John Havlicek wrote: >>> Hi Folks: >>> >>> Our ballot on 2088 failed due to negative vote. >>> >>> See the results below. >>> >>> J.H. >>> >>> >> ---------------------------------------------------------------------- >> -- >> ---------- >>> Ballot on Mantis 2088 >>> >>> - Called on 2008-01-15, final ballots due by 2008-01-21 T > 23:59-08:00. >>> yv[xxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan >> (Intel) >>> yv[xxxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny >> (Synopsys) >>> n[----------------------x-xxx---------x-x-xxx-x---x] Surrendra >>> Dudani >> (Synopsys) >>> yv[xxxxxxxx-xxxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais >> (Freescale) >>> t[xxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek >> (Freescale - Chair) >>> yv[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry >>> Korchemny >> (Intel - Co-Chair) >>> nv[xxxxx-xxxxxxxxx-xxx-x--xx--xxxxx----------xx-xxxx] Manisha >> Kulshrestha (Mentor Graphics) >>> n[------------------------------xxxxx-------x-xx-x-] Jiang Long >> (Mentor Graphics) >>> n[---------x------------x--xxx.....................] Joseph Lu >> (Altera) >>> v[xxxxxxxxxxxxxxxxxxx..............................] Johan >>> Martensson >> (Jasper) >>> n[---------------------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller >> (Freescale) >>> yv[xxxxx-xxxx-xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper >> (Cadence) >>> yv[xxxxxx-x-x-xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman >> (Intel) >>> n[-------x-x----x--------xxxx-----xxxx-xx----------] Tej Singh >> (Mentor Graphics) >>> yv[xxxxxx-x-xxxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara >> (Synopsys) >>> yv[xxxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher >> (Sun Microsystems) >>> |------------------------------------------------- attendance on >> 2008-01-15 >>> |--------------------------------------------------- voting >> eligibility for this ballot >>> |---------------------------------------------------- email ballots >> received >>> Legend: >>> x = attended >>> - = missed >>> r = represented >>> . = not yet a member >>> v = valid voter (2 out of last 3 or 3/4 overall) >>> n = not a valid voter >>> t = chair eligible to vote only to make or break a >>> tie >>> >>> >> ---------------------------------------------------------------------- >> -- >> ---------- >>> Rationale for Negative Vote >>> >>> [MK] >>> >>> I vote 'no' as I am not sure if this proposal handles all the >>> sampling >>> issues related to covergroups. I am not completely familiar with >>> covergroups but I do see that in the LRM there are multiple ways to >>> sample the variables which are used in covergroups. The 1900 also >> talks >>> about sampling of checker variables. E.g. in 16.18.6.2 it says: >>> >>> >>> Sequential check bits (see 16.8.5.1) are sampled in the Preponed >> region, >>> as the regular variables are. Continuous check bits (see 16.18.6.1) >> are >>> never sampled either in assignments (see 16.18.6.1) or in concurrent >>> assertions. >>> >>> What will happen if these check bits are used in covergroups ? The >>> new >>> proposal does not talk about it. >>> >> -- >> This message has been scanned for viruses and dangerous content by >> MailScanner, and is believed to be clean. >> >> --------------------------------------------------------------------- >> Intel Israel (74) Limited >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> >> >> -- >> 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 Tue Jan 29 10:46:18 2008
This archive was generated by hypermail 2.1.8 : Tue Jan 29 2008 - 10:46:41 PST