Jonathan, On the surface, it does look as if an interface port is just taking a reference to an interface instance, and allowing it be used as the root of a hierchical reference within the module. The LRM even claims "The syntax of interface_name.modport_name reference_name gives a local name for a hierarchical reference." However, this viewpoint breaks down for modports. The LRM also claims "The keyword modport indicates that the directions are declared as if inside the module." This was discussed in http://www.eda-stds.org/sv-bc/hm/5602.html An 'output' qualifier on a variable in a modport is not just a synonym for 'ref', because with an 'output' qualifier there is a continuous port driver for the output variable components of a modport. If 'output' were really just a synonym for 'ref' on a variable in a modport, what purpose would that keyword serve there besides misleading users who were expecting the "as-if" semantics of an 'output' port declared inside a module? [ In reply to http://www.eda-stds.org/sv-ec/hm/4511.html .] -- Brad -----Original Message----- From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Jonathan Bromley Sent: Wednesday, July 11, 2007 11:45 AM To: Arturo Salz; sv-bc@eda-stds.org; sv-ec@eda-stds.org Subject: RE: [sv-ec] RE: [sv-bc] Hierarchical reference in clocking signal Arturo, > I'm sorry if I mislead you. As we discussed in the past, we agreed to > remove the dotted expression forms from the clock-var Don't apologize - I had totally forgotten about 594, which completely deals with the issue. Mea culpa, and thanks to Doug for highlighting it. > I was noting that not all dotted expressions represent hierarchical > expressions. Clearly that's true, but I'm intrigued that you seem to be thinking of the module/program's port of modport type as being something like a struct variable. I had always imagined it to be more like an alias for the interface instance, with special visibility rules imposed by the modport. I need to go away and think harder about that - it has significant impact on some stuff I've been exploring recently. Thanks -- 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.Received on Wed Jul 11 12:14:26 2007
This archive was generated by hypermail 2.1.8 : Wed Jul 11 2007 - 12:14:45 PDT