RE: [sv-bc] Bit/Part select of modport named argument

No, you cannot legally write i.j[0][0] instead of i.j.

The LRM does not treat i.j[0] as an operator [] being applied to an expression i.j. It treats the entire i.j[0] as an operand. You can apply indexing to an identifier, which can have zero or more packed dimensions. You can only apply indexing as many times as it has dimensions. You cannot apply indexing to a general vector expression. Vector expressions are all just vector expressions, and don't have different numbers of packed dimensions as one of their properties.

The one case where indexing has been allowed on vector expressions is concatenation, and those are consistent with what I just wrote. They are simply treated as vectors, whether the thing in the concatenation was a scalar or a vector identifier with 1 or more packed dimensions. You can legally write {{{{i.j}[0]}[0]}[0]}[0] if you want, and it will yield the same as i.j for a scalar or 1-bit vector i.j.

The LRM does not say that the modport takes the type of an identifier if the port expression was an identifier. It says that it takes the self-determined type of the port expression. The self-determined type of an integral expression is just a vector. If you look at the rules for self/context-determined types of vector expressions, you will find rules for determining their bit-width and signedness. You won't find any rules for determining their "scalarness" or number of packed dimensions. They are all just vectors.

You can write "v+s" where v is a vector and s is a scalar, and you won't get any type incompatibilities, because a scalar is treated the same way as a 1-bit vector when used in an expression. The same is true if v is a 100-dimensional packed array. It is still type compatible, because when it is used in a vector expression, it is just treated as a vector. If you tried to keep track of "scalarness" for an expression, what would you say it was for a mixed expression like "v+s"?

This particular corner case of a scalar versus a 1-bit vector isn't a big deal, and I wouldn't worry too much about it. There isn't much point in applying an index to a 1-bit object anyway. But there is a more general case where it makes a bigger difference. Suppose you had

 interface iface;
    logic [2:0] [2:0] [2:0] x;
    modport mport (input .j (x));
 endinterface

The type of the identifier x is a 3-dimensional packed array. The self-determined type of the port expression x is a 27-bit vector.

If you use the self-determined type of the expression, as the LRM says, then i.j is a 27-bit vector. Then i.j[0] is a 1-bit value, and i.j[0][0] is illegal.

If port j were treated as a 3-dimensional packed array, then i.j[0] would be a 9-bit value, and i.j[0][0] would be a 3-bit value. This is quite different.

If you tried to follow such a rule, then how would you treat ".j(x+v)", where v has some different number of dimensions? At that point, you would have to acknowledge that this is an expression and doesn't get any dimensionality properties from x or v. But the LRM says the port expression is an expression even when it is just ".j(x)", so it gets no dimensionality properties from x in this simple case either.

-----Original Message-----
From: bradpiercephd@gmail.com [mailto:bradpiercephd@gmail.com] On Behalf Of Brad Pierce
Sent: Saturday, February 05, 2011 12:18 PM
To: Steven Sharp
Cc: Surya Pratik Saha; sv-bc@eda.org
Subject: Re: [sv-bc] Bit/Part select of modport named argument

So we could legally write i.j[0][0][0][0][0][0] and it would yield the same as i.j?

-- Brad

On Fri, Feb 4, 2011 at 9:24 PM, Steven Sharp <sharp@cadence.com> wrote:
> How can you distinguish a scalar from a 1-bit vector in this situation?  I think the distinction disappears when used in an expression, and the self-determined type is the same.
>
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Brad Pierce
> Sent: Friday, February 04, 2011 11:18 AM
> To: Surya Pratik Saha
> Cc: sv-bc@eda.org>> interface iface;
>>    logic [2:0] x;
>>    modport mport (input .j (x[1]));
>> endinterface
> Subject: Re: [sv-bc] Bit/Part select of modport named argument
>
> "The self-determined type of the port expression becomes the type for the port." Shouldn't you be able to use the name of the port in any way that's consistent with its type? In this case, it has a scalar type, and it doesn't make sense to be indexing into a scalar type.
>
> -- Brad
>
> On Fri, Feb 4, 2011 at 2:15 AM, Surya Pratik Saha <spsaha@cal.interrasystems.com> wrote:
>> Hi,
>> I have a design like:
>>
>> module top;
>> iface i ();
>> foo f (i.mport);
>> endmodule
>>
>> module foo (iface.mport i);
>>    initial begin
>>        i.j[1] = 1; // Bit select of modport named argument
>>    end
>> endmodule
>>
>> Is bit/part select of modport named argument allowed? I am also not
>> sure what is the meaning of that if it is allowed. Though some
>> standard tools do not give any meaningful error.
>>
>> --
>> Regards
>> Surya
>>
>>
>>
>>
>> --
>> 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.