[sv-ec] 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.