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

Peter,

  My biggest concern on (C) is tied to philosophical issues and
"slippery slope" concerns. Your suggestion on weak typing pokes a huge
hole in the assumption that type checking is done by the end of
elaboration (with the exception of some OO related casting issues that
are explicit). With the suggested approach, there now becomes a very
complex run-time type check that could fail at very inopportune times.
Imagine, for example, a multi-week simulation that fails with such an error.

The slippery slope concern lies in how far we want to go with more
"interpretive" semantics in SV. For example, a whole bunch of pending
discussion regarding AOP models and possibly other things becomes
"simple" if you are prepared to embed an interpretive model for some
parts of the HDL behavior. But we've tried very hard to avoid going
that direction due to concerns about long-term scalability and performance.

So I'm concerned about opening this door and if we do so, I think there
needs to be very careful consideration of the precedent and long-term
directions in which we're heading. It isn't clear to me how to have
that discussion in an effective manner.

Gord.

On 10/25/2010 5:04 AM, Peter Flake wrote:
>
> 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.
>
> 2. 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.
>
> 3. 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.
>
> 4. 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.
>
> 5. 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.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.