<Forwarding email from Jonathan Bromley> -------- Original Message -------- Subject: RE: [sv-bc] Clocking blocks - discrepancies hard to resolve Date: Tue, 7 Feb 2006 17:14:43 -0000 From: "Jonathan Bromley" <jonathan.bromley@doulos.com> To: "Rich, Dave" <Dave_Rich@mentor.com>, <sv-ec@server.eda.org> Dave, > Check out mantis 890 and see if the proposal clarifies things Thanks for the pointer. It's hard to keep up with all the activity on Mantis without nearly full-time involvement, and I had completely missed 890. Unfortunately it's still unassigned and we still have at least two conflicting implementations, so it means that for any practical purposes we must regard clocking blocks as being off-limits until a resolution is established and supported. Time for me to mount a soap-box: A clocking variable has two distinct "ends" - the design signal it drives or samples, and the clocking block variable that is sampled or driven by a client program block. (By the way, we are sorely in need of unambiguous *names* for each end of a clocking variable.) The LRM description of clocking would have been massively more lucid had it been defined in terms of the sampling and driving semantics of these two ends individually. Instead, we are forced to infer this information - at some cost of interpretive pain - from the description that exists. I am aware that others disagree with me because such a description smacks too much of enforcing an implementation, but I still hanker after it. -- 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 This e-mail and any attachments are confidential and Doulos Ltd. reserves all rights of privilege in respect thereof. It is intended for the use of the addressee only. If you are not the intended recipient please delete it from your system, any use, disclosure, or copying of this document is unauthorised. The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Received on Tue Feb 21 15:19:15 2006
This archive was generated by hypermail 2.1.8 : Tue Feb 21 2006 - 15:20:23 PST