RE: [sv-bc] dotted names and interfaces

From: Steven Sharp <sharp@cadence.com>
Date: Thu Jan 17 2013 - 14:07:58 PST
1.       Virtual interface arrays are true arrays and can be indexed by variables.  They have an explicitly declared element type which includes the parameterization, and can only be assigned an interface that is compatible.  One way to index an array of interface instances is to use a generate-for to assign the instances to the elements of a virtual interface array, after which you can access them through the virtual interface array with variable indices.  If some element of the instance array has parameterization that doesn’t match the declaration of the virtual interface array, this should produce an error for the assignment, if the proper type-checking is being done.

2.       There is no incompatibility in your example.  There is nothing about the interface port which demands a particular parameterization. I don’t think there is even a syntax for declaring the parameterization of an interface port.  It accepts whatever parameterization you connect to it.  This goes even further with generic interface ports, where the declaration doesn’t even specify the type of interface, which is determined by what gets connected.  When you do declare the type of interface, the parameterization is still generic.  One price for this flexibility in getting whatever you connect, without having to declare it explicitly, is that interface array ports are like arrays of instances rather than arrays of virtual interfaces.  That means they are not guaranteed to be homogeneous, so they cannot be indexed by variables.



From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Daniel Mlynek
Sent: Thursday, January 17, 2013 4:58 AM
To: Mark Hartoog
Cc: Rich, Dave; sv-bc@eda.org
Subject: Re: [sv-bc] dotted names and interfaces

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> [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<mailto: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<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 14:09:11 2013

This archive was generated by hypermail 2.1.8 : Thu Jan 17 2013 - 14:09:25 PST