Gordon,
I understand your reservations. I just do not see how virtual interfaces
work properly without more "interpretive" semantics, like Vera. The notion
of a module type is much weaker than that of a data type because of
defparams, configurations, binds etc., and I would apply this to interfaces
too. If you could work out which interface instances were likely to be
assigned to a virtual interface you could do the type checking at
elaboration time, as you do now. Maybe another mechanism, such as
configurations or attributes, could be used to combine flexibility with
elaboration type checking.
Peter.
From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: 25 October 2010 16:48
To: Peter Flake
Cc: sv-bc@eda.org
Subject: 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.
A. 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.
B. 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.
C. 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.
D. 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.
E. 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 <http://www.mailscanner.info/> MailScanner, 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.Received on Wed Oct 27 08:55:51 2010
This archive was generated by hypermail 2.1.8 : Wed Oct 27 2010 - 08:57:48 PDT