Re: [sv-bc] Interface issues

Hi Françoise,

See comments below.

Francoise Martinolle wrote:

> We have found a few issues regarding interfaces. There are also
> separate issues regarding the VPI model but they may depend on what is
> or what is not legal in SV. So I am sending this email first to the BC
> committee.
> I would like to know if someone can clarify this at the next bc
> meeting or can respond by email.
>
> 1. BNF allows multi-dimensional interface arrays.
> -----------------------------------------------------------------------
>
> It looks like the bnf for module port declaration allows for
> multi-dimensional interface arrays ports.
> I thought at most we could have interface arrays of one dimension
> (same as array of instances).
> Look at the {unpacked_dimension}

I believe someone was going to take this up as a V2K errata. When they
added multi-D arrays to Verilog, they did not update the section on
arrays of interfaces. Presumably they thought people would use generate
instead and they were under the same time pressure as we (SV-BC) were. I
think people want multi-D arrays of instances. Much easier to read than
generate.

>
> interface_port_header ::=
> interface_identifier [ *. *modport_identifier ]
> | *interface *[ *. *modport_identifier ]
> ansi_port_declaration ::=
> [ net_port_header | interface_port_header ] port_identifier {
> unpacked_dimension }
> | [ variable_port_header ] port_identifier variable_dimension [ *=
> *constant_expression ]
> | [ net_port_header | variable_port_header ] *. *port_identifier *( *[
> expression ] *)
>
> *When applying the bnf, I could declare a interface port I with multi
> dimensions...
>
> module TOP (interface I [1:0][3:0]);
> endmodule
> That looks wrong.
>
> 2. Can you do declare an interface port to be a sub-element of an
> interface array?
> --------------------------------------------------------------------------------------------------------------------
> module TOP;
> I myI [0:1](); // instantiate an array of
> interfaces I
> M mod (myI[0], myI[1]); // pass the interface sub-elements down to
> module M
> endmodule
>
> module M (i[0], i[1]);
> I i[0:1];
> endmodule;
>
See 19.4.4 Modport expressions. This was added in 3.1a

> 3. Can you pass down the hierarchy an array slice of the interface array?
> ---------------------------------------------------------------------------------------------------------

Yes, why not?

>
> Note that the ranges of the interface port in devA are different [0:1]
> from the ranges in the interface array slice passed down [1:2].
>
> Note that the range of the interface port in devB is bigger that the
> interface array slice passed down. I think this means that the
> interface element array Sbus[2] in devB is unconnected.

Can't do this. Rules for connecting arrays of instances does not allow
unconnected ports elements unless the entire port range is unconnected.

>
> *module *top;
> SBus s[1:4] (); // instantiate 4 interfaces SBus
>
> devA a1( s[1:2] ); // instantiate devA, pass down interfaces s[1:2]
> devB b1( s[3:4] );
> endmodule
>
> *module *devA( Sbus s[0:1] ) ... *endmodule *// devices that use SBus
> *module *devB( Sbus s[0:2] ) ... *endmodule
>
> *4) modport port declarations relationship with existing interface
> port declarations
> --------------------------------------------------------------------------------------------------------------------
> Can the directions be different from the interface port declarations?
> Are they adding, replacing, existing prior interface port
> declarations? Or if they are conflicting is this a compiler error?
>
> Ex: is the following legal? What are the rules between the port, io
> declarations, nets and variables declarations inside the interface and
> inside the modports?
>
> interface main_bus (input wire clock, reset, output [15:0] data);
>
> modport master ( output clock, inout [15:0] data, input resetN);
>
> endinterface

Interface port directions do not have to match modport directions,
however, all other port connection rules apply. For example, if you have
a interface input variable, you could not have it as a modport output
also. That would mean two continuous drivers on the interface variable.
For wires, port direction is a "guide" anyways.

>
> 5) ambiguity of interface declarations with variable declarations
> -------------------------------------------------------------------------------------------
> When a module has an interface port and uses the non ansi port
> declaration, the compiler cannot determine if it was an interface
> declaration or a variable declaration.
> Ex:
>
> module ( i);
> myI i; // what is i? an interface or a variable, we cannot determine
> until the resolution of myI is completed.

>
> Suggestion is to add the keyword interface before myI:
> interface myI i;

I'll leave this for the BNF masters. I don't see what's different about
this from a structure.

>
> 6) ) Are instantiation of interfaces allowed inside another interface
> when the interface definition is outside? basically like for modules?
> I think the bnf allows it but I want to check.
>
> interface myI (input clock);
> endinterface
>
> interface bigI;
> wire clock;
> myI i1( clock);
> endinterface

Why not?

>
> That's all for the moment...
>

-- 
--
David.Rich@Synopsys.com
Technical Marketing Consultant and/or
Principal Product Engineer
http://www.SystemVerilog.org
tele:  650-584-4026
cell:  510-589-2625