Subject: [sv-bc] description and begging of proposal for SV-BC-19-60.
From: Jacobi, Dan (dan.jacobi@intel.com)
Date: Wed Feb 26 2003 - 21:27:21 PST
SV-BC listing
==========
This E-mail deals with the issue labeled as SV-BC-19-60
Motivation
========
The origin of the problem :
The problem orients from the fact that the keyword 'interface' is used for
both:
1. Declaring a System-Verilog interface (that can also be nested under
another interface)
Such as the following RTL :
interface myinterface(...);
...
endinterface
2. Declaring a generic interface port used for creating a module (or an
interface with ports) with an unspecified interface
instantiation as a place-holder for an interface to be selected when the
module itself is instantiated.
Such as shown in the following RTL.
module mymodule(interface b);
or
module mymodule(b);
interface b;
Now lets look at some RTL examples that get things a complicated:
An interface (a) using a generic interface (b) as a port
interface a (interface b);
...
endinterface : a
Lets get rid of the optional label and use the Verilog 95 style
interface a (b);
interface b;
...
endinterface
Don't be mistaken the endinterface belongs to the first line not the second.
Now lest nest another portless interface (c) within interface a
interface a (b);
interface b;
interface c;
...
endinterface
endinterface
start connecting the 'endinterface' keywords to the matching 'interface'
keywords ...
And finally lets add in some more interfaces
interface a ( b );
interface b ;
interface c;
interface d( e,f );
interface e ;
interface f ;
endinterface
endinterface
endinterface
Not that I recommend such coding style (Actually I think it is kind of
sick), but it is legal System-Verilog.
Now try to look at the same example in the eyes of a simple LR1 parser that
doesn't have any hacks and dynamic time name
binding. This compiler does not give any meaning to the identifiers name,
therefore we will mark all the identifiers as xx.
interface xx ( xx );
interface xx ;
interface xx;
interface xx( xx,xx );
interface xx ;
interface xx ;
endinterface
endinterface
endinterface
In this case the parser can not match the 'endinterface' keywords to the
matching 'interface' keywords. In this case there are at least three
solutions for the matching problem.
Another problematic example (in this case the generic bundle is a module
port and not an interface port)
module a (b);
interface b;
interface c;
...
endinterface
endmodule
In this case our parser needs to do some complicated parse time name binding
and then parse a line such as
'interface xx;' in a different way depending of the type bound to xx (pre
defined port or new defined interface).
This will cause a slowdown in all parsers and complicate the writing of
parsers.
I did not check what happens with these examples when parsing them using
SystemSim (According to the presentations in DVCon this is a simulator that
should simulate SuperLog ...).
Possible Solutions
==============
1. Ignore the problem, declare it to be an implementation problem (which it
really is) and let the
EDA companies deal with it. This is not my preferred solution, hopefully
I hope other people object to this
solution.
2. Permitting the use of generic bundles only in ANSI style port lists.
Meaning the following examples will be illegal
interface myint(a)
interface a;
module mymodule(b);
interface b;
However these examples will still be legal
module mtint(interface a);
interface mymodule(interface b);
This can be done by changing the BNF and adding some language of the
interface chapter.
This is my preferred solution and the only one I can think of that can
really solve the problem.
What Next
========
If most of the SV-BC members agree with my second proposal, I will prepare a
proposal with the needed changes needed in the BNF and in the language
chapter.
Please send me or the whole SV-BC group your opinion regarding the second
solution. Also if you have any other solution that solves the problem for
all the presented examples please send them as well.
Thanks
Dan Jacobi
Phone : (972)-4-8655855
Intel
This archive was generated by hypermail 2b28 : Wed Feb 26 2003 - 21:27:56 PST