Re: [sv-bc] rules for interface module port used in nested instantation as port for another module

From: Greg Jaxon <Greg.Jaxon_at_.....>
Date: Mon Jul 13 2009 - 12:26:35 PDT

Section 25.5 has a paragraph saying:

If a port connection specifies a modport list name in both the module instance and module header declara-
tion, then the two modport list names shall be identical.

In my opinion, three major things are lacking in the sections devoted to modports:

1. A distinct connection semantics for variables being connected via a modport.
   Although modports were developed in answer to synthesis concerns about how to take variables across hierarchy without sim/synth mismatch, simulators never took seriously the idea that this syntax might require them to promote the variable to a wire,  and so the present LRM does not appear to effectively alter the connection semantics despite saying that variables connect "as if" they were ports with the given (wired) direction.  Now that data types on nets are standardized, perhaps we can  try again with some other syntax to ask simulators to accurately model what synthesis engines can produce.
2. In actual port expressions, the modport qualifier is applied like a field selection operator ".".  It is not clear where this belongs in an interface array port expression.   I think if the subfield notation is going to continue to be used, it should be able to go wherever a subfield can be put in a selector expression, and it means the same regardless of where it is written.  Lack of modport array syntax could be used to deprecate it if we come up with a better syntax for point #1.
3. A clear statement on whether the modport list limits only direct accesses (i.e. is an API), or all accesses (i.e. completely specifies the necessary connections module-to-module).

Greg Jaxon
Disclaimer: These are not voting positions, just observations

Daniel Mlynek wrote:

I've doubts for below sample. I haven't found in LRM rules for conecting interface port to module instantation. Can anyone take a look a responce to my doubts:

interface iface;
 reg r; 
 reg r1;
 modport slave (input r);
 modport master(input r1);
endinterface

 

module top;
 iface if_();
 sub uut(if_.slave);
endmodule

 

module sub(iface if_);
 sub1 uut1(if_.slave);// dillowed?  imho forbidden as this is already slave
 sub1 uut2(if_.master);// dillowed? imho forbidden as from slave we do not have access to master
 sub1 uut3(if_);// if_ here is restricted with slave modport so in uut3 there will be also slave mopdort in use 
endmodule

 

module sub1(iface if_);
endmodule

DANiel

 

--
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. Received on Mon Jul 13 12:29:38 2009