<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