RE: [sv-ac] RE: Clock flow

Hi Manisha,

My contention is that it would be better in case of ended/matched to
*explicitly* pass the clock from context, since they do not have inline
semantics. 
A) A relatively easy way to support reuse en-masse is enveloping the
unclocked sequences in a default clocking block (which is inside a
module say instantiated with the proper clock). 
B) For limited in-situ reuse use the arg passing mechanism, which I now
realize John had already mentioned in his email, missed it earlier.

"ended/matched" are in a sense sealing the sequence from context mucking
around with internals during instantiation, you want to change something
make the object parameterizable. Are these enough of reuse facilities ?
Sneaking clock in is really not warranted in my opinion.

Thx.
-Bassam.

--
Dr. Bassam Tabbara
Architect, R&D
Novas Software Inc.
(408) 467-7893

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Kulshrestha, Manisha
Sent: Thursday, September 01, 2005 12:07 PM
To: john.havlicek@freescale.com
Cc: sv-ac@eda.org
Subject: [sv-ac] RE: Clock flow

Hi All,

I agree with John that we should allow clock to flow into "ended". I did
not quite understand how default clock solves this problem. As per my
understanding default clock does not apply to sequence instances with
"ended" or "matched". The default clocking event applies to concurrent
assertions (not property or sequence declarations). In fact, the cases
where default clocking is being used, it is even more important to let
clock flow into "ended" as most of the sequences/properties are
unclocked. 

Thanks.
Manisha

-----Original Message-----
From: John Havlicek [mailto:john.havlicek@freescale.com]
Sent: Wednesday, August 31, 2005 4:27 PM
To: Kulshrestha, Manisha
Cc: john.havlicek@freescale.com; sv-ac@eda.org
Subject: Re: Clock flow

Hi Manisha:

> Is there any specific reason that the instance of a sequence with 
> methods ended/matched are getting excluded in the above case ?=20

First, I believe that these restrictions can be relaxed without
introducing backward compatibility problems.  This is because saying
that the clock does not flow through ended/matched means the sequences
instances to which these methods are applied must already have initial
clocking events defined.  Thus, if the contextual clock flows in, it
will immediately be overridden by the internal clocks of the sequences.

As I recall, the intuition for these restrictions was basically that a
clock flowing into a sequence instance starts affecting the beginning of
that sequence, while ended/matched are references to the endpoints of
sequences.  Thus, there is something counterintuitive about have the
clock flow "backwards" to get to the start of the sequence instance to
which ended/matched is applied.

Also, "matched" involves synchronization between clocks, so I think the
committee preferred to avoid the clock flow in this case.

On the other hand, especially with "ended", I think the case can be made
that it is a nuisance to forbid the clock to flow in.  

For example, if I want to code my sequences as unclocked and only attach
my clock at the top level of a property, then I want that clock to be
able to flow to all parts of the property.  If I need to use "ended",
then I am stuck--I have to declare an explicit clock for each sequence
to which I want to apply ended, and I have to make sure it matches the
clock in the context where ended appears.  This makes those sequences
less re-usable, or it forces me to a different coding style in which the
clock gets passed in as an argument.

My current opinion is that it would be a good thing to relax this
restriction for "ended", at least if "ended" is applied to an instance
of an unclocked sequence.

In the case of matched, it is less clear to me that it is a good idea to
relax the restriction.

I am curious to hear other opinions on this topic.

Best regards,

John H.

> Content-class: urn:content-classes:message
> x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
> x-originalarrivaltime: 30 Aug 2005 18:33:13.0181 (UTC) 
> FILETIME=[4786D8D0:01C5AD91]
> Date: Tue, 30 Aug 2005 11:33:11 -0700
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: Clock flow
> Thread-Index: AcWtkUhQ9sGOGAshR3KXswTojB6A8Q==
> From: "Kulshrestha, Manisha" <Manisha_Kulshrestha@mentor.com>
> Cc: <sv-ac@eda.org>
> 
> This is a multi-part message in MIME format.
> 
> ------_=_NextPart_001_01C5AD91.4803D100
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> Hi John/All,
> 
> In section 17.12.3 (Clock Flow), P1800 draft, it says that:
> 
> The scope of a clocking event flows into an instance of a named 
> property. The scope of a clocking event flows into an instance of a 
> named sequence provided neither method ended nor method matched is 
> applied to the instance of the sequence.
> 
> Is there any specific reason that the instance of a sequence with 
> methods ended/matched are getting excluded in the above case ?=20
> 
> Thanks.
> Manisha
>