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

Hi Neil,

There are two issues preventing using the default clocking as a global
clocking. The first issue is that the default clocking is typically used
to specify the most frequently used clocking event in the module, while
the global clocking should specify the fastest design clock. In the
simplest case you will normally have:

default clocking @(posedge clk); endclocking

but

global clocking @clk; endclocking

The second issue, which is the most important is that the global
clocking is the same for the whole design, while the default clocking
may differ from module to module. Therefore assertion behavior in
different modules won't be consistent.

Thanks,
Dmitry

-----Original Message-----
From: Neil.Korpusik@Sun.COM [mailto:Neil.Korpusik@Sun.COM] 
Sent: Wednesday, March 07, 2007 4:32 AM
To: Korchemny, Dmitry
Cc: Jonathan Bromley; sv-ac@eda-stds.org; sv-ec@eda-stds.org
Subject: Re: [sv-ac] Feedback from sv-ec on global clocking (Mantis
1681)

Hi Dmitry,

I am trying to understand why the existing default clocking can't
be used for the situations where you are proposing to use the
global clocking. There seems to be a lot of commonality between
the two. Having both a default clocking and a global clocking
(i.e. global default clocking) seems to be problematic for the various
reasons that Jonathan outlined.


Neil



Korchemny, Dmitry wrote On 03/06/07 04:13,:
> 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.

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