[sv-ec] RE: [sv-ac] Feedback from sv-ec on global clocking (Mantis 1681)

<forwarding bounced email from Korchemny, Dmitry>

-------- Original Message --------
Subject: RE: [sv-ac] Feedback from sv-ec on global clocking (Mantis 1681)
Date: Tue, 06 Mar 2007 14:13:26 +0200
From: Korchemny, Dmitry <dmitry.korchemny@intel.com>
To: Jonathan Bromley <jonathan.bromley@doulos.com>, sv-ac@eda-stds.org, sv-ec@eda-stds.org

Hi Jonathan,

I would like to send a couple of my comments on the global clocking, we
will send the complete and official answer later.

The global clocking is aimed to address several goals:
* Be a global default clocking
* Specify the common denominator of all the clocks in the model
* Specify the finest granularity of the model assertion clocks
* Allow simulation alignment with formal verification

The first role of the global clocking is only syntactic: if no clock can
be inferred for a given assertion or a sampled value function (e.g.,
$past), then the global clocking event is used.

Though the main intent of the global clocking is to be the common
denominator of all clocks in the model, the requirement of the proposal
to check the synchronization of all assertion clocks with the global
clocking and ignoring the assertion clocks when they are not
synchronized with the global clocking event may be significantly relaxed
and stated as:

all clocks of the assertions using the global clocking event EXPLICITLY,
must be synchronized with the global clocking event.

Since the global clocking is not part of the current version of the
language, introducing the global clocking has absolutely no effect on
any existing assertions.

Your proposal on automatic global clock derivation answers most of the
practical needs, but sometimes it may also include another event. Here
is an example:

Let all the assertions but one be controlled by @(posedge clk). The
remaining assertion claims that some signal remains stable between two
rising edges of clk. This assertion should be explicitly controlled by
the global clock, but this clock does not control any other assertion.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Jonathan Bromley
Sent: Tuesday, March 06, 2007 11:18 AM
To: sv-ac@server.eda-stds.org; sv-ec@server.eda-stds.org
Subject: [sv-ac] Feedback from sv-ec on global clocking (Mantis 1681)

hi sv-ac,

The sv-ec meeting on 5 March 2007 wished to reflect to you
a number of concerns relating to the proposals for a global
clocking.  None of the members of sv-ec claims any special
expertise in formal verification, so we must ask your
forbearance of any misunderstandings.  As you will see,
many of our comments are requests for clarification of
intent.

As a general point, sv-ec is unhappy about adding any new
ability to specify simulation-wide global behavior.  Any such
un-scoped global behaviors are a barrier to re-use, and difficult
for users to specify correctly.  They cause parts of a model to
be illegal or legal, depending on other completely unrelated
parts of the model.  From a language and simulation point of
view it would be much more natural for the "global clocking"
to be in some way scoped, although we understand that this
would defeat its intent.  We would be grateful if sv-ac could
confirm (or rebut) our understanding that "global clocking" is
intended to be truly global for a model.

We understand from the documents we have seen that the concept
of a global clock is required to allow formal tools to work
with multiple clocks.  However, we do not understand the need
for such a global clock in simulation.  Consequently our
first response was to suggest that the global clock should
be specified in a tool-specific manner for formal tools that
need it.

We initially suggested that global clocking could be specified
not as a language construct, but as an attribute (*...*) that
could be interpreted by formal tools.  However, attributes
should never affect the meaning of a model for simulation.
Adding global clocking would cause some models that are
illegal today (those having unclocked properties, or
## delays with no default clocking) become legal; thus,
global clocking affects simulation behaviour and cannot be
specified through an attribute.

We note that you reject the idea of using the simulation
timeslots as a global clocking, on the grounds that it would
be inefficient in simulation.  We would be grateful for
clarification of this.  Would it be sufficient (for the
requirements of formal tools) for the succession of
timeslots in simulation to be used as a global clocking,
even though this might be inefficient in simulation?

We were unsure about your concept of alignment of
assertion clocks with the global clock.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Further notes from Jonathan Bromley personally, after
reading 1681 proposals more closely while writing this:

(1) In the 1681 proposals there seems to be some
verbal confusion between "system clock" and "global
clock".  I would urge that this language be made
consistent.

(2) At the meeting I stated my understanding that
"alignment" reflects the idea that all ticks of any
assertion clock are in the same timeslots as ticks of
the global clock.  On reading the 1681 proposals more
closely, I see that the idea is stronger than that:
any assertion clock that is not in the same timeslot
as the global clock is to be ignored.  I am very
troubled by this.  It means that a global clock
specification in a remote and unrelated piece of
code can invalidate the simulation semantics of an
established piece of code.  Especially in the case
of verification IP, it may not be possible for the
user to take account of all clocks used in assertions
when creating the global clock definition.  Even
with 1681's concession that tools could issue an error
in this case, I suspect that simulation-centred users
would find this unacceptable.

(3) I think there may possibly be a compromise available.
Would it be sufficient to have an automatically-inferred
global clock that is the union of all clocks used in
assertions anywhere in the model?  Such a clock would fire
only in timeslots where some assertion's clock already
fires, and therefore would have little impact on
simulation performance.  It's interesting to note that
such an automatically-inferred global clock would be
very similar to the behaviour of the "sys.any" global
event in the 'e' language.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223                   Email:
jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

-- 
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.