RE: [sv-ac] RE: review 1681 (global clocking)

I fixed one more minor typo in the motivation section: $next_i -->
$future_gclk according to the latest version of the proposal on the next
value functions.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Korchemny, Dmitry
Sent: Tuesday, June 26, 2007 2:11 PM
To: Doron Bustan; Eduard Cerny
Cc: sv-ac@server.eda.org
Subject: [sv-ac] RE: review 1681 (global clocking)

Hi all,

I updated the document (attached here for convenience) according to
Doron's comments and adjusted the numeration according to the Draft D3a.

See my comments in the original mail body below.

Thanks,
Dmitry

-----Original Message-----
From: Doron Bustan [mailto:dbustan@freescale.com] 
Sent: Tuesday, May 29, 2007 11:54 PM
To: Eduard Cerny; Korchemny, Dmitry
Cc: sv-ac@eda.org
Subject: review 1681

Hi Ed, Dmitry,

here are my comments.

 at page 5 it says"

    "If an assertion is controlled by $global_clock (see Note to editor:

insert a reference to Global clocking
    subclause here) then in simulation $global_clock is substituted by 
the clocking event defined in the
    global clocking statement. In formal verification the $global_clock 
is considered to be a primary
    system clock (see E.3.1). "

  and in page 6:

    "To assure consistency between simulation and formal verification, 
in the multiclocked properties referencing
    the global clock all other clocks should be aligned with the ticks 
of the global clocks: the property clocks may
    change only at the same simulation ticks when the global clock is 
changing (i.e., when the global clocking
    event happens)."

  my understanding is that for formal, all clocks must synchronized to 
the global clock, and in simulation it is only
  recommended. I think it is bad to have (possibly) different  semantics

for formal and simulation, so I think that you
  should also require synchronization at simulation.

[Korchemny, Dmitry] I changed the wording on the page 6 to:

"In the multiclocked properties referencing the global clock, all other
clocks shall be aligned with the ticks of the global clock: the property
clocks may change only at the same simulation ticks when the global
clock is changing (i.e., when the global clocking event happens). In
case when the clocks do not conform to this behavior, an error message
shall be issued."

* at page 6,  referncing => referencing

[Korchemny, Dmitry] Fixed.

Doron







Eduard Cerny wrote:

> Hello Doron,
>
> 1. It is the intent to allow clock changes inside always block, i.e.,
> the assertion clock dominates over always block clock dominates over
> default clocking.
>
> 2. I think it is a recommendation. Dmitry?
>
> Best regards,
> ed
>
>
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> > Behalf Of Doron Bustan
> > Sent: Wednesday, May 09, 2007 11:35 AM
> > To: sv-ac@eda.org
> > Subject: [sv-ac] review 1681
> >
> > here are my (minor) comments
> >
> > 1. in 17.7.3 (inferred clock) the change in the wording implies
> >     precedence of a clock in an assertion over a clock inferred from
> >     an initial/always block. In 17.13.5 it says that if both
clocking
> > events
> >     exist, they should be the same. There is no strict
> > contradiction here,
> >     but I think it is misleading.
> >
> > 2. At the beginning of p6, it is not clear to me whether the
alignment
> >     off the clock to the global clock is a requirement (with
> > elab error
> > when violated,)
> >     or a recommendation.
> >
> > Doron
> >
> > --
> > 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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.