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

Hi,

perhaps it was not explained well in the document, but the purpose of
the goal of the global clock is to provide "time base" for all clocks
which would allow simulation and formal tools to align, to avoid
mismatches. The proposal for hierarchical default clock if so desired
would be independent of the global clocking proposal.

Best regards,
ed
 

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> Behalf Of Neil Korpusik
> Sent: Wednesday, February 28, 2007 1:12 PM
> To: SV_EC List; sv-ac@eda-stds.org
> Cc: adam.krolnik@verisilicon.com
> Subject: [sv-ac] Re: [sv-ec] mantis item 1681 - global clocking
> 
> <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.
> 
> 

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