Re: [sv-ec] mantis item 1681 - global clocking

From: Neil Korpusik <Neil.Korpusik_at_.....>
Date: Wed Feb 28 2007 - 10:12:27 PST
<forwarding email from Adam Krolnik>

-------- Original Message --------
Date: Wed, 28 Feb 2007 08:48:44 -0600
From: Adam Krolnik <adam.krolnik@verisilicon.com>
To: SV_EC List <sv-ec@server.eda.org>
CC: Havlicek John <john.havlicek@freescale.com>, Sv_Ac <sv-ac@server.eda.org>
Subject: Re: [sv-ec] mantis item 1681 - global clocking

Good morning all;

The idea of a global clock is interesting, but seems to be a problematic
for reuse.

The spec says in 15.12 "The main purpose of the global clock[ing] is to
introduce the [a] common system clock
for all concurrent assertions in the entire design. This is convenient
for synchronous designs."

What about synchronous designs with multiple clock domains. Surely, one
would agree that a design
with a JTAG controller (that has its clock) and main logic (with its own
clock) is still a synchronous system.
Yet clocking assertions from these two domains with one clock will
produce possibly wrong results compared
with clocking assertions with the local domain clock.

An example is shown:

   ...
   global clocking sys @(clk1 or clk2); endclocking

This example will need some explaining. Why is the global clock the
combination of all events of clk1 + clk2?
It is not common to see designs clocked on both edges of a clock.
Assertions written for one clock domain
will definitely fail if clocked with this global clock that has 4 times
the number of events as the logic.

In 17.3, it states, "where global clocking has been specified ... for
correct operation the user should make sure that
the ticks of all other clocks are aligned with the ticks of the global
clock. The simulation tool may issue an error message when it detects
that this requirement has been violated."

How can one fulfill this requirement in the general case simulation. I
have designs that have 3-4 clock domains, running
at different frequencies (some synchronous to each other, some not.) I'm
sure larger companies have dozens of clock domains.

The example in 17.14 shows this point. The property

    property p5;
       (a |-> ##2 b);
    endproperty

Is supposed to expect that B ocurrs 2 cycles after A. If you combine
that with the global clocking specification above,
how can this property be expected to pass when simulated with 4 edges of
a clock counting as a 'cycle'.

Instead of a global clock block, it would be more useful to have a
hierarchical default clock. Assertions obtain their
clock from the current scope, or the parent scope, up to this
hierarchical default clock. That way a verification engineer
can specify a clock block for a clock domain and place the required
clock block at the necessary levels of hierarchy to achieve this. Most
likely this would be something that is bound (via the bind statement) to
modules in a design.

With this approach, one can define the default clock for each domain
however the system is composed of pieces and
their specific clock domain.

-- 
    Soli Deo Gloria
    Adam Krolnik
    Director of Design Verification
    VeriSilicon Inc.
    Plano TX. 75074
    Co-author "Assertion-Based Design"


-- 
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.
Received on Wed Feb 28 10:12:48 2007

This archive was generated by hypermail 2.1.8 : Wed Feb 28 2007 - 10:12:56 PST