I'm working on what actual changes I'll put into the proposal. I will probably add a section to talk about using the sample() method. I'm thinking about something like this: "Covergroups may also be triggered by procedural calls to a sample() method (see ...). Inside checkers, the the call to sample() may not occur directly in initial_check or always check procedures, but a call to sample() may occur within a function that is called from an assignment in one of those procedures. They may also be called from final procedures, sequence match items, and assertion action blocks." I'll also create some examples to illustrate what happens when sample() is used to trigger a covergroup. Tom Thomas Thatcher wrote: > 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 Mon Jan 28 15:47:03 2008
This archive was generated by hypermail 2.1.8 : Mon Jan 28 2008 - 15:47:11 PST