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. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 Email: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Mar 6 01:18:11 2007
This archive was generated by hypermail 2.1.8 : Tue Mar 06 2007 - 01:19:10 PST