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

From: Jonathan Bromley <jonathan.bromley_at_.....>
Date: Tue Mar 06 2007 - 01:17:37 PST
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.
Received on Tue Mar 6 01:18:11 2007

This archive was generated by hypermail 2.1.8 : Tue Mar 06 2007 - 01:19:10 PST