Re: [sv-bc] dotted names and interfaces

From: Daniel Mlynek <danielm@aldec.com.pl>
Date: Thu Jan 17 2013 - 01:57:31 PST
1. so for interface port array it is illlegal
what about virtual interface arrays?

2. CODE with def param and array of interfaces on port should not even 
pass elaboration ass in case below ii[1] would be incompatible with 
array on port which expects iface with P==1;

    interface iface;
         parameter P=1;
         reg [P:0] a;
    endinterface

    module top;
         iface ii[10]();
         defparam ii[1].P=2;
         sub uut(ii);
    endmodule

    module sub(iface ip[10]);endmodule

W dniu 1/15/2013 7:25 PM, Mark Hartoog pisze:
>
> To allow variable index to an interface port array, we would have to 
> require that all elements of the array are identical. Currently the 
> LRM does not require that, since you can defparam one element of the 
> array. Defparams can lead to “ip[i].a” having different width for 
> different values of ‘I’.
>
> *From:*owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] *On Behalf Of 
> *Daniel Mlynek
> *Sent:* Tuesday, January 15, 2013 5:18 AM
> *To:* Rich, Dave
> *Cc:* sv-bc@eda.org
> *Subject:* Re: [sv-bc] dotted names and interfaces
>
> Term  "reference to a hierarchical reference" is not a term from LRM 
> afaik. You mean that this is smth like ref module port?
> If this is smth different that hier reference and member select then 
> maybe it should be separately mentioned in dotted reference chapter.
>
> If both virtual interface and interface port reference are not 
> hierarchical reference can we use variable to index over arrays of it? 
> for hierarchical reference it would be illegal - see example:
>
> interface iface;
>     int a;
> endinterface
>
> module top;
>     iface ii[10]();
>     sub uut(ii);
>     virtual iface vi[10] = ii;
>     initial begin
>         int i;
> repeat(2)begin
> $display(vi[i].a); //legal???
>             i=i+2;
>         end
> repeat(2)begin
> $display(ii[i].a); //this is illegal
>             i=i+2;
>         end
>     end
> endmodule
>
> module sub(iface ip[10]);
>     initial begin
>         int i;
> repeat(2)begin
> $display(ip[i].a);  //legal???
>             i=i+2;
>         end
>     end
> endmodule
>
>
>
>
>
>
> Mantis 632 disallows code like marked in below sample - Am I right:
>
> interface iface;
> endinterface
>
> module top;
>     parameter p = 1;
>     iface ii[10]();
>     sub uut();
>     sub1 uut1(ii);
>     if(p) begin :lab1
>       iface ii1();
>       sub2 uut2(ii1);
>     end
>
>       sub2 uut3(lab1.ii1);//<<<<<<<<<<<
> endmodule
>
>
> module sub ;
>   sub1 uut1(top.ii);//<<<<<<<<<<<
>   sub2 uut2(top.lab1.ii1);//<<<<<<<<<<<
> endmodule
>
> module sub1(iface ip[10]);
> endmodule
>
> module sub2(iface ip);
> endmodule
>
>
>
> DANiel
>
> W dniu 1/11/2013 7:08 PM, Rich, Dave pisze:
>
>     My understanding is that an interface port is indeed a reference
>     to a hierarchical reference, the same as a virtual interface
>     reference. See the end of 25.3
>
>     The LRM make a specific exception for references to types via
>     interface ports, but does not consider that an actual interface
>     connection could be a hierarchical reference. Mantis 632 was
>     supposed to address this, but did not go far enough.
>
>     Dave
>
>     Mentor Graphics
>
>     *From:*owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org>
>     [mailto:owner-sv-bc@eda.org] *On Behalf Of *Daniel Mlynek
>     *Sent:* Thursday, January 10, 2013 4:33 AM
>     *To:* sv-bc@eda.org <mailto:sv-bc@eda.org>
>     *Subject:* [sv-bc] dotted names and interfaces
>
>     LRM:
>     "A hierarchical name and a member select into a structure, union,
>     class or covergroup object share the same syntactic form of a
>     sequence of name components separated by periods. Such names are
>     called dotted names"
>     and later:
>     "The distinguishing aspect of a hierarchical name is that the
>     first component of the name must match a scope name while the
>     first name component of a member select must match a variable name."
>
>     I cannot find in LRM exact definition of what is the scope. I've
>     found definition like this : "scope_nameis either a subroutine
>     name, a module, program, or interface instance name or a generate
>     block name." but it is not full
>
>     There is at least 2 more constructs which share dotted name syntax
>     - which  are not explicitly mentioned above
>      - reference to interface port item  module uut(interface ip)
>     initial ip.m=1; // what is ip.m???
>      - reference to virtual interface items
>     Assuming that those are not listed in a member select part of
>     definition - both of those should be treated as hierarchical
>     references with all consequences?
>     IMHO 2nd  rather should be treated as member select as virtual
>     interface it self varaible so text could be changed:
>     "A hierarchical name and a member select into a structure, union,
>     class, virtual interface or covergroup object share the same
>     syntactic form of a sequence of name components separated by
>     periods. Such names are called dotted names"
>
>     But I'm not sure what about ref to interface port items - those
>     are not member selects for sure - but are they hierarchical
>     references?
>     You can reference to a type by interface port and you cannot do
>     this by hier reference. What about indexing with non constant
>     select on arrays of intances which are disallowed for hier refs
>     are those also illegal for interface port arrays?
>
>     DANiel
>
>
>
>
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>     and is
>     believed to be clean.
>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, 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 Thu Jan 17 01:57:42 2013

This archive was generated by hypermail 2.1.8 : Thu Jan 17 2013 - 01:57:55 PST