I think that the Champions and the P1800 WG have not approved 594, so that Stu can not enter it. That should occur by September 1, whereas Draft 4 is scheduled for October 1. Shalom > -----Original Message----- > From: owner-sv-ec@server.eda.org > [mailto:owner-sv-ec@server.eda.org] On Behalf Of Warmke, Doug > Sent: Wednesday, July 11, 2007 9:26 PM > To: Arturo Salz; Jonathan Bromley; Surya Pratik Saha; > sv-bc@server.eda-stds.org; sv-ec@server.eda-stds.org > Subject: RE: [sv-ec] RE: [sv-bc] Hierarchical reference in > clocking signal > > Hello All, > > Apparently this section was not updated with the changes from > approved Mantis #594. Please review it at > > http://www.eda-stds.org/svdb/view.php?id=594 > > Stu - Can you please add 594 into the next draft? > Somehow it might have been stomped out by the 890 edits, > though 890 didn't address 14.8 (used to be 15.8) at all. > > Thanks, > Doug > > -----Original Message----- > From: owner-sv-bc@server.eda.org > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Arturo Salz > Sent: Wednesday, July 11, 2007 10:57 AM > To: Jonathan Bromley; Surya Pratik Saha; > sv-bc@server.eda-stds.org; sv-ec@server.eda-stds.org > Subject: RE: [sv-ec] RE: [sv-bc] Hierarchical reference in > clocking signal > > Jonathan, > > In that particular example, the clock-variables are not > hierarchical expressions. The "a" in question represents an > interface modport, and allows users to access the members of > the interface or modport without the need for creating > hierarchical expressions to each interface member. > > Not all dotted expressions are hierarchical references. > > Arturo > > -----Original Message----- > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On > Behalf Of Jonathan Bromley > Sent: Wednesday, July 11, 2007 4:50 AM > To: Surya Pratik Saha; sv-bc@eda-stds.org; sv-ec@eda-stds.org > Subject: [sv-ec] RE: [sv-bc] Hierarchical reference in clocking signal > > Surya raises a good point. > > [Note: I've removed sv-ac from the list, and added sv-ec > whose responsibility this is.] > > > There is an e.g. in the LRM using hierarchical reference as signal > > identifier (page no. 218) > > Clause 15.8; in the new draft 3a it's clause 14.9. > > > clocking cd1 @(posedge a.clk); > > input a.data; > > output a.write; > > inout state = top.cpu.state; > > endclocking > > > Which is wrong as per BNF. > > Indeed it is. It seems that this one slipped the net of 890; > I'm ashamed I didn't pick it up when EC was working on that. > > If I don't hear a strong contrary opinion by the end of > today, I'll raise a Mantis item to fix this example and the > associated text. I believe it is simply wrong. The > clockings should be inside the interfaces, or else > hierarchical_expression should be used (as with the inout > clockvar in the above example). > Clockvars cannot have dotted names. > > I believe the use of @(posedge a.clk) is OK according to the > LRM, since it's an example of an "event_expression". > -- > 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. > > > > -- > 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.Received on Fri Jul 13 01:34:39 2007
This archive was generated by hypermail 2.1.8 : Fri Jul 13 2007 - 01:35:10 PDT