RE: [sv-bc] Interface and modport Mantis items

In the interest of making progress, I am willing to invest some time and effort in writing proposals to implement changes for which there is consensus, if the changes are fairly straightforward, such as Peter's A, for example.

Shalom

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Peter Flake
Sent: Monday, October 25, 2010 2:05 PM
To: sv-bc@eda.org
Subject: [sv-bc] Interface and modport Mantis items

Hi,

I apologize that I will not be able to attend today's call. But I have documented my vision of proposed enhancements to fix the Mantis Items selected by Shalom.

BTW I am ok with the proposals for parameterized functions, but I too have some doubts about using classes in synthesizable code.

Regards,

Peter.

I propose the following language changes to deal with the various issues raised. These are in my priority order.

 1. Allow interface specializations to be used in port declarations. For example:
module m #(parameter N=16) (IFC#(N) ifc, input [N-1:0] in);
module m #(parameter N=16) (IFC#(N).mymodport mp1, input [N-1:0] in);

This fixes Mantis 905 and 2502.

 1. Allow modports and functions to be defined within generate blocks and to be given standard names e.g
block name [iteration number].modport name.
This syntax should be accepted wherever a modport name is used. This also allows each modport to have its own version of a function with static data. Similarly, it should be possible to refer to any generate scope in an interface port.

This fixes Mantis 75, 167, 343 and 1611. The combination of A and B allows module ports to be configured by parameters.

 1. Weaken the type checking so that a match between port declaration and port connection is achieved if the types and names of all modport items match. Similar checking would apply to a virtual interface. In implementation terms, this could mean that the symbol table of modport item names yields an alphabetically sorted index to instance-specific tables of pointers to the objects (nets, variables etc.). For virtual interfaces, such a table would have to be built for each new assignment and cached for the next time. This approach allows different interfaces with a similar modport to be compatible. It also allows the interface binding to be controlled by configurations. The sensitivity list and other checks normally done at elaboration time should also be done instead at run time, for each new assignment of the virtual interface.

This fixes Mantis 1706, 2545, 2561 and 3048.

 1. Allow a parameter value to be selected from an interface port directly, rather than having to use a local parameter as an intermediate value.

This fixes Mantis 1419 and 2573.

 1. Allow a modport item to be another modport in the same interface or in a sub-interface.
<interface instance>.<modport name>
The effect is to in-line the list of modport items.

This makes it easier to use hierarchical interfaces and fixes the intent of Mantis 2870.

I have taken Shalom's list of interface issues emailed on September 27 and commented on them. I have kept his order, but only commented once on each Mantis item. Some issues appear in more than one category.

parameters
----------
0905 No way to use type from interface in ANSI-style port declaration
          Fixed by A.
2502 Cannot use parameterized interface in port declaration
Fixed by A.
1419 Interface param via interface-type port reference
          Fixed by D.
2573 Allow parameter selected from an interface port to be a constant
expression. Fixed by D.
0167 Interfaces: How to parameterize and synthesize
          Fixed by B.
0075 Allow imported functions/tasks to use names local to importing
module. Fixed by B.
2545 Avoid requiring needless interface parameters in virtual interface
declarations. Fixed by weak typing.

modports
--------
2114 Problems in definition of modports

The modport should only impart directional information and changes of names. The directional information is only for design rule checking. It appears that some tools may not reject designs that are not synthesizable.

1861 Suggestion for major enhancement of modports

A proposal in two parts: stand-alone modports, without an interface, and modport instances in modules.

1611 Referring into generate scope via interface port
          Fixed by B.

1635 function prototype return data type in modport

There is an inelegance in the language because functions default to returning a logic type, whereas function prototypes have no such default. However it affects more than just interfaces and modports. I think this is an unimportant language change but easy to make.

0387 Are interface identifiers required for exported tasks functions?

I would say "no". My interpretation of the LRM is that the interface identifiers are optional, to provide disambiguation where needed.

0343 Using modports inside generate loops inside interfaces
          Fixed by B.
0167 Interfaces: How to parameterize and synthesize
          Fixed by B.
0075 Allow imported functions/tasks to use names local to importing
module. Fixed by B.
2524 Task export in interface modports

I agree with Gord that the interface has a reference to an exported task which resides within the module.

2870 Is an interface a valid modport item?

I agree with Brad that it should not be a valid modport item, but the intent is fixed be E.

2975 Connecting arrays of interface instances using a modport -- slice syntax

I disagree with Brad. I think that since the servers are the array, the selection should go there.
servers[0].master, servers[1:7].slave

Language clarification needed.

tasks/functions
---------------
Most items already discussed.

2577 label after endfunction for out-of-scope function definition

I agree with Steven.

references into interfaces
--------------------------
0901 Localparam redefinition of interface type reference (BNF)

There is an inelegance in that local parameters of type "type" cannot be used but typedef can.

I think this is an unimportant language change but easy to make.

0905 No way to use type from interface in ANSI-style port declaration
          Fixed by A.
1419 Interface param via interface-type port reference
          Fixed by D.
1611 Referring into generate scope via interface port
          Fixed by B.
2573 Allow parameter selected from an interface port to be a constant
expression. Fixed by D.
3208 Clarify whether interface port references are hierarchical
References. Language clarification needed

port declarations of type interface
-----------------------------------
0905 No way to use type from interface in ANSI-style port declaration
          Fixed by A.
2502 Cannot use parameterized interface in port declaration
          Fixed by A.
3048 Binding of interface names in virtual interfaces and interface
ports. Fixed by C.

generates
---------
Items already discussed.

miscellaneous
-----------------
0902 Instantiating gates, primitives and modules in interfaces

I agree with Dave Rich that it is not prudent to complicate the hierarchy.

1470 Allow interconnect definitions in packages

There may be a case for allowing interfaces, modules and programs in packages but I do not consider it a specific interface issue.

minor editorial
---------------
0913 Local redefinition of interface type identifier -- confusing description

Relates to 0901

1506 extern interface is not described in text

Clarification similar to extern module is needed

2515 Several productions missing from Syntax 25-1-Interface syntax

Needs copying from Annex A

2534 Connecting generic interfaces

I agree with Shalom.

testbench
---------
2545 Avoid requiring needless interface parameters in virtual interface
declarations. Fixed by C.
1441 20.8 restriction on virtual interfaces in "sensitivity list" not
defined

I agree with Steven that this needs clarification.

1706 Meaning of static prefix for virtual interface assignments
          Fixed by C.
2561 virtual interface initialization at declaration with interface port
          Fixed by C.
3047 Issues with virtual interfaces as types

The clarification of the issues would be affected by the "weak typing" proposal.

3048 Binding of interface names in virtual interfaces and interface
ports. Fixed by C.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.