RE: [sv-ec] Re: SV: Hierarchical reference to an object in a modport

Ben,

See my comments below. In general, there is nothing to prevent one
vendor from extending their interpretation of the language. What's
really bad is when vendors have different interpretations of the same
construct.
> -----Original Message-----
> From: vhdlcohen@aol.com [mailto:vhdlcohen@aol.com]
> Sent: Monday, September 12, 2005 9:13 AM
> To: Rich, Dave; sv-ec@eda.org
> Subject: Re: [sv-ec] Re: SV: Hierarchical reference to an object in a
> modport
> 
>  Dave,
>   1. I agree that rtl rtl_2(.m (b_if.m),..) is legal. But, are you
> saying that the following is ILLEGAL?
[DR>] My interpretation is that the following is illegal.
> 
>  rtl rtl_1(.m (b_if.rtl_if.m), // ILLEGAL?? LEGAL??
>  .a (b_if.rtl_if.a),
>  .b (b_if.rtl_if.b),
>  .clk (clk),
>  .reset_n (reset_n)
[DR>]  That said, I think this might be a useful enhancement, especially
since there is no what to get at modport expressions other than through
a connected port.
> 
>   2. While we're at it, Is this connection legal? What does the (.*)
> mean if the RTL has no interface, and the testbench uses the
interface?
>  rtl rtl_3 (.*);
[DR>] My interpretation of .* is that it expands to .name(name) for all
ports in the instantiated module. If "name" does not exist, than that is
an error. If there was more than one instantiated interface, or a
combination of local names and interfaces, there are currently no rules
that specify how you could do the hook-up
> 
>   3. There is an compatibility issue here because I know of one vendor
> that considers my example ALL legal, yet another vendor considers the
> rtl rtl_1(.m (b_if.rtl_if.m), ...) illegal. Also illegal is the rtl
> rtl_3 (.*);
> 
>   4. There is an compatibility issue among vendors, and I would like
to
> see a resolution on this.
[DR>] Me too.
> 
>  Thanks,
> 
> 
>  -----Original Message-----
>  From: Rich, Dave <Dave_Rich@mentor.com>
>  To: vhdlcohen@aol.com; sv-ec@eda.org
>  Sent: Sun, 11 Sep 2005 22:08:39 -0700
>   Subject: RE: [sv-ec] Re: SV: Hierarchical reference to an object in
a
> modport
> 
>  Ben,
> 
>  A modport does not create a scope (section 19.13 lists those
construct
>  that do). It is only used to represent an access list when used in a
>  port formal or port actual. There is no syntax in the language to
>  reference members of a modport.
>  '
>  Section 20.9 declares that all objects in an interface are visible by
>  simple hierarchical reference.
> 
>  The following is legal
> 
>  rtl rtl_2(.m (b_if.m),
>  .a (b_if.a),
>  .b (b_if.b),
>  .clk (clk),
>  .reset_n (reset_n)
>  );
>  Dave
> 
> 
> 
>  > -----Original Message-----
>  > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
>  > vhdlcohen@aol.com
>  > Sent: Friday, September 09, 2005 5:11 PM
>  > To: sv-ec@eda.org
>  > Subject: [sv-ec] Re: SV: Hierarchical reference to an object in a
>  modport
>  >
>  >
>  > I forgot the clock and reset conections. Below is the update.
>  >
>  > -----Original Message-----
>  > From: VhdlCohen
>  > To: sv-ec@eda.org
>  > Sent: Fri, 09 Sep 2005 20:06:54 -0400
>  > Subject: SV: Hierarchical reference to an object in a modport
>  >
>  > I looked through the LRM and do not find any statement that
>  disallows
>  > a hierarchical reference to an object in a modport. In the example
>  > below I have a hierarchical reference being connected to a port of
a
>  > module instance.
>  > The question is: Is it legal for me to make such connection?
>  > Specifically, is
>  > rtl rtl_1(.m (b_if.rtl_if.m), // LEGAL ???
>  >
>  > In case you're wondering why this unusual style, it's because a
>   > top-level and testbench designer defined the interfaces, assuming
> that
>  > the RTL guy will use. But the RTL guy did not use the interface,
and
>  > defined just straight ports. The question then becomes: Is the
>  > testbench correct?
>  >
>  > I believe that there misunderstanding in the community on this
>  issue,
>  > and I would like some clarification.
>  > ------------------------ // Updated
>  > interface sysbus_if (input clk, input reset_n);
>  > timeunit 1ns;
>  > timeprecision 100ps;
>  > logic m;
>  > logic a;
>  > logic b;
>  >
>  > modport driver_if (
>  > input m,
>  > output a,
>  > output b
>  > );
>  >
>  > modport rtl_if (
>  > output m,
>  > input a,
>  > input b
>  > );
>  >
>  >
>  > endinterface : sysbus_if
>  >
>  >
>  > module rtl (
>  > output logic m,
>  > input logic a,
>  > input logic b,
>  > input reset_n,
>  > input logic clk);
>  > endmodule : rtl
>  >
>  > module rtl_tb;
>  > // logic m;
>  > // logic a;
>  > // logic b;
>  > logic reset_n;
>  > logic clk;
>  >
>  > sysbus_if b_if(clk, reset_n);
>  >
>  > rtl rtl_1(.m (b_if.rtl_if.m),
>  > .a (b_if.rtl_if.a),
>  > .b (b_if.rtl_if.b),
>  > .clk (clk),
>  > .reset_n (reset_n)
>  > );
>  >
>  > rtl rtl_2(.m (b_if.m),
>  > .a (b_if.a),
>  > .b (b_if.b),
>  > .clk (clk),
>  > .reset_n (reset_n)
>  > );
>  > endmodule : rtl_tb
>  >
>  >
>  >
>  >
>  >
> 
>
------------------------------------------------------------------------
>  -
>  >
>  > -
>  > Ben Cohen Trainer, Consultant, Publisher (310) 721-4830
>  > http://www.vhdlcohen.com/ ben_ f rom _abv-sva.org
>  > * Co-Author: SystemVerilog Assertions Handbook, 2005 ISBN
>  > 0-9705394-7-9
>  > * Co-Author: Using PSL/SUGAR for Formal and Dynamic Verification
2nd
>  > Edition, 2004, ISBN 0-9705394-6-0
>  > * Real Chip Design and Verification Using Verilog and VHDL, 2002
>  isbn
>  > 0-9705394-2-8
>  > * Component Design by Example ", 2001 isbn 0-9705394-0-1
>  > * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn
>  > 0-7923-8474-1
>  > * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn
>  > 0-7923-8115
>  >
>  >
> 
>
------------------------------------------------------------------------
>  -
>  >
>  > --------
>  >
>  >
> 
>