Re: [sv-ac] sequence as clocking event to covergroup

From: Neil Korpusik <Neil.Korpusik_at_.....>
Date: Tue Jan 16 2007 - 10:33:04 PST
There is something known as a covergroup type option. One of these is the
strobe option (see 18.2 page 305 and 18.6.1). The strobe option is used to
prevent a coverage point from being sampled more than once in the same time
step. When the strobe option is specified for a covergroup the corresponding
coverage points are sampled in the Postponed region.

The strobe option seems to be one way to deal with multiple matches when a
sequence is used as a covergroup clocking event.

Neil



Eduard Cerny wrote On 01/15/07 07:10,:
> True... actually I missed that in the LRM. But is this a good solution?
> Would uniqueness even if chosen non-deterministically be better? (I
> know, local variables...)
> 
> ed
> 
> 
> 
>>-----Original Message-----
>>From: John Havlicek [mailto:john.havlicek@freescale.com] 
>>Sent: Monday, January 15, 2007 9:33 AM
>>To: Eduard.Cerny@synopsys.COM
>>Cc: john.havlicek@freescale.com; tej_singh@mentor.com; sv-ac@eda.org
>>Subject: Re: [sv-ac] sequence as clocking event to covergroup
>>
>>Hi Ed:
>>
>>Your suggestion contradicts what we already have
>>written about first_match in section 17.
>>
>>Do you intend to make this inconsistent with the
>>currently existing first_match semantics?
>>
>>J.H.
>>
>>
>>>X-MimeOLE: Produced By Microsoft Exchange V6.5
>>>Content-class: urn:content-classes:message
>>>Date: Mon, 15 Jan 2007 06:27:41 -0800
>>>Thread-Topic: [sv-ac] sequence as clocking event to covergroup
>>>Thread-Index: Acc3Yk/jxmzGV+eTSIWbGNAy5ZE/HwBTrOYg
>>>From: "Eduard Cerny" <Eduard.Cerny@synopsys.com>
>>>Cc: <sv-ac@eda.org>
>>>X-OriginalArrivalTime: 15 Jan 2007 14:27:43.0158 (UTC) 
>>
>>FILETIME=[5187F560:01C738B1]
>>
>>>Hi John,
>>>
>>>I agree with you that the covergroup should trigger on 
>>
>>multiple matches
>>
>>>of a seuqnce, but I think that with first_match it should 
>>
>>give only one
>>
>>>match even if there are possible multiple matches (by choosing
>>>non-deterministically one of them).=20
>>>
>>>Regards,
>>>ed
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On=20
>>>>Behalf Of John Havlicek
>>>>Sent: Monday, January 08, 2007 9:31 AM
>>>>To: tej_singh@mentor.com
>>>>Cc: sv-ac@eda.org
>>>>Subject: Re: [sv-ac] sequence as clocking event to covergroup
>>>>=20
>>>>Hi Tej:
>>>>=20
>>>>I have a few comments.
>>>>=20
>>>>It is true that the LRM does not give a complete definition of
>>>>multiplicity of matching and of when matching occurs.  On 
>>
>>the other
>>
>>>>hand, the LRM also does not leave these things completely 
>>
>>undefined.
>>
>>>>=20
>>>>I think that if a covergroup has a sequence instance as 
>>
>>its clocking
>>
>>>>event, then multiple matches of the sequence instance in the same
>>>>timestep should result in multiple triggerings of the covergroup.
>>>>=20
>>>>I think we should avoid allowing the rules for multiplicity=20
>>>>of covergroup
>>>>triggering on sequences to differ from the rules for 
>>
>>multiplicity of
>>
>>>>matching that apply in other scenarios, e.g.
>>>>=20
>>>>   cover property (
>>>>      @(posedge clk)
>>>>      sequence_instance ##0 (1, task_call);
>>>>   );
>>>>=20
>>>>I don't like the idea of trying to incorporate 
>>
>>first_match into the
>>
>>>>semantics of covergroups with sequence clocking event.  I 
>>
>>think the=20
>>
>>>>user can use first_match in defining a sequence, but then 
>>
>>the general
>>
>>>>rules for multiplicity of sequence matching should apply.
>>>>=20
>>>>In particular, a first_match can have multiplicity, e.g. if both
>>>>a ##1 b and c ##1 d match over a two-cycle interval, then=20
>>>>=20
>>>>   first_match((a ##1 b) or (c ##1 d))
>>>>=20
>>>>should match with multiplicity two over that interval.
>>>>=20
>>>>Best regards,
>>>>=20
>>>>John H.
>>>>=20
>>>>
>>>>>X-Authentication-Warning: server.eda-stds.org: majordom set=20
>>>>
>>>>sender to owner-sv-ac@eda.org using -f
>>>>
>>>>>X-MimeOLE: Produced By Microsoft Exchange V6.5
>>>>>Content-class: urn:content-classes:message
>>>>>Date: Wed, 6 Dec 2006 15:12:02 -0800
>>>>>X-MS-Has-Attach:=20
>>>>>X-MS-TNEF-Correlator:=20
>>>>>Thread-Topic: [sv-ac] sequence as clocking event to covergroup
>>>>>Thread-Index: =
>>>
>>>AccZfiKOmZ5lYIN/QgGxOLcn04V72QABWXHgAAFLp5AAAHSA7A=3D=3D
>>>
>>>>>From: "Singh, Tej" <tej_singh@mentor.com>
>>>>>Cc: <sv-ac@eda.org>
>>>>>X-OriginalArrivalTime: 06 Dec 2006 23:12:03.0364 (UTC)=20
>>>>
>>>>FILETIME=3D[F0C06E40:01C7198B]
>>>>
>>>>>X-Virus-Status: Clean
>>>>>Sender: owner-sv-ac@eda.org
>>>>>=20
>>>>>This is a multi-part message in MIME format.
>>>>>=20
>>>>>------_=3D_NextPart_001_01C7198B.F0397F78
>>>>>Content-Type: text/plain;
>>>>>	charset=3D"iso-8859-1"
>>>>>Content-Transfer-Encoding: quoted-printable
>>>>>=20
>>>>>But as Doron pointed out, the LRM does not define the=20
>>>>
>>>>number of threads.
>>>>
>>>>>=20
>>>>>How about defining it so that the number of events at a=20
>>>>
>>>>clock is same as
>>>>
>>>>>number of sequence attempts that matched at that clock.=20
>>>>
>>>>This is what I =3D
>>>>
>>>>>was trying
>>>>>to do with first_match but first_match will kill any 
>>
>>future matches.
>>
>>>>>=20
>>>>>So for a sequence expr that looks like
>>>>>=20
>>>>>a ##[1:$](b ##1 c) or (d ##1 e)
>>>>>=20
>>>>>it will not matter whether 'or' results in two matches or=20
>>>>
>>>>one match =3D
>>>>
>>>>>since
>>>>>both correspond to the same attempt.=3D20
>>>>>=20
>>>>>Tej
>>>>>=20
>>>>>=20
>>>>
>>>>=20
>>>>--=20
>>>>This message has been scanned for viruses and
>>>>dangerous content by MailScanner, and is
>>>>believed to be clean.
>>>>=20
>>>>=20
>>
> 

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Senior Staff Engineer                             Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Jan 16 10:34:11 2007

This archive was generated by hypermail 2.1.8 : Tue Jan 16 2007 - 10:34:29 PST