Subject: Fitz's Action Items for 7/22 Meeting
From: Tom Fitzpatrick (fitz@co-design.com)
Date: Fri Jul 19 2002 - 07:52:43 PDT
Here are my action items for Monday's meeting.
-Tom
------------------------------------------------------
Tom Fitzpatrick
Director of Technical Marketing
Co-Design Automation, Inc.
------------------------------------------------------
Email: fitz@co-design.com Mobile: (978)337-7641
Tel: (978)448-8797 Fax: (561)594-3946
Web: www.co-design.com
www.superlog.org
------------------------------------------------------
SUPERLOG = Faster, Smarter Verilog
------------------------------------------------------
-----------------------------------------------
> * AI - Tom to provide clarification
>
> -Cadence issues w/ Section 3
> Steve Sharp
>
> * AI - Tom to add description of %s
> * AI - Tom to provide some pitfalls of combining modules & interfaces
Here goes:
> ======================================================================
> Section 3 - Issues with new data types and keywords
> (Steve/Cadence) [Basic]
> - actual utility of char, shortint, longint, byte, shortreal
While it's true that there is no interface to C defined in SystemVerilog,
these datatypes were added to SUPERLOG because it does have an interface to
C. Before we decide to remove or alter these datatypes and keywords, we
should wait and see what the SV-CC does in this area.
> c. The int type seems reasonable as a general purpose 2-state
> variable, similar
> to the Verilog integer. However, one would expect orthogonality
> between the
> 2-state and 4-state types. The int type is exactly 32 bits, while
> the integer
> type is 32 bits or more.
Again, I believe this orthogonality may or may not be affected by the SV-CC
discussions.
The types really should be orthogonal,
> rather than an
> ad hoc collection.
> d. The longint type probably has more utility than shortint,
> since it can't
> always be replaced with an int. However, it doesn't correspond to
> a commonly
> used C type except with a C compiler that is compiling for
> 64-bit. The need for
> a 64-bit integer type in Verilog is limited, and can be declared
> as a packed
> array of bit if necessary. It doesn't appear to justify the addition of a
> reserved word.
> e. The byte type could be justified by a desire to conveniently
> declare 2-state
> strings. However, it does not appear that they can be used for
> this. String
> literals can be assigned to arrays of char, but not to arrays of
> byte. Nor can
> arrays of byte be used with string I/O or manipulated with
> Verilog operators or
> in combination with other strings, which are packed vectors. This actually
> makes the byte type less useful than an array of bits. And since
> "byte" is more
> likely to be used as an identifier name in existing designs than
> most of the
> other new types, it creates a more serious backward compatibility
> issue. The
> limited utility does not appear to justify the addition of a
> reserved word that
> is likely to match existing identifiers.
> j. The void type is unnecessary. It was added to C because C only has
> functions, and void allows declaring a subroutine without a return value.
> Verilog already has tasks, so it doesn't need void. There is
> nothing that can
> be done with a void function that cannot already be done with a
> task. There is
> no need to copy this type from C.
There are certain things that are allowed in a task that are not allowed in
a function. It is useful to be able to preserve this distinction even if the
function does not return a value.
> ======================================================================
> Section 3.6 - Implications of Enum type I/O (Steve/Cadence) [Basic]
> - need to detail what is expected of Verilog I/O routines to support this
> - [also vcd enhancements]
> In section 3.6, it is stated that enumerated types can be
> displayed using the
> enumerated names. Is this supposed to imply some capability of
> the Verilog I/O
> routines? If so, these capabilities need to be defined. If it is just a
> speculation about what the user interface to some tool might allow during
> debugging, then this should be made plain.
When printed in string format ("%s"), the enum value identifier shall be
printed as a string. I do not believe that this implies any additional
requirements on I/O routines.
> ======================================================================
> Section 3.7 - Passing large structs/arrays (Stuart/Cadence)
> [Basic, System]
> - can this be done by reference instead of value (which would be
> inefficient)?
> Is there a way to pass large structs or arrays to functions/tasks
> by pointer or
> as const references, rather than by value? If not, this can be extremely
> inefficient for large structs or arrays.
The addition of pointers is a good idea. It should probably be discussed in
the SV-EC.
> ======================================================================
> Section 13 - Interfaces vs. Modules (Stuart/Cadence) [Basic, System]
> - interfaces and modules are almost the same
> - should make them so and simplify definition
> I see no reason why "interfaces" and "modules" aren't exactly the
> same thing.
> Both can have ports, both can export tasks, both can be
> parameterized, both
> represent hierarchical structures, both can have "always" blocks
> and processes,
> etc. Making "interfaces" and "modules" be exactly equivalent would go a
> long way
> towards simplifying SystemVerilog.
I disagree. There is inherent value in having a separate interface construct
to represent the communication between modules. This is why SystemC has
channels and interfaces.
In fact, interfaces and modules do not both represent hierarchical
structures, because interfaces actually cross levels of hierarchy, the same
way that nets do, so there can be multiple different hierarchical names for
the same interface instance.
Once one agrees that having a separate interface construct, then the
addition of always blocks and tasks and functions become useful enhancements
to provide functionality in support of the interface as a communication
construct. Always blocks allow interfaces to contain assertions and
tasks/functions allow interfaces to model abstract communication, for
example.
interface my_intf(input bit clk);
logic a,b;
endinterface;
module top;
bit clk;
my_intf m_i(clk);
mid m1(m_i);
mid m2(m_i);
endmodule
module mid(interface i);
bot b1(i);
endmodule
module bot(interface i);
always @(posedge i.clk)
i.a <= i.b;
endmodule
top.m_i.a
top.m1.i.a
top.m2.i.a
top.m1.b1.i.a
top.m2.b1.i.a
are all the same actual signal.
If we instead tried to make my_intf a module, you would now have a case
where different rules apply based on whether a module is simply instantiated
or whether it is passed through a port as an interface. Do you restrict the
use of module as an interface if it's already used as a module (ie. I can't
pass module "mid" through a port list)? I personally believe that having
multiple sets of rules for things, especially if one set of rules is a
completely new addition to a construct with which everyone is already
familiar, to be much more confusing than adding a new construct. This is, I
believe, a logical extension of the difference between gates and wires,
which is fundamental to the Verilog language.
This may unfortunately come down to a philosophical battle, and I may not be
able to convince you (I hope I have). I would hope, however, that the
feedback we've gotten from our users on the utility of interfaces is enough
to convince the committee that they are a significant addition to
SystemVerilog.
> ======================================================================
> Section 13.1 - Interfaces restrictions (Stuart/Cadence) [Basic, System]
> - should allow an interface to contain other modules
> - would allow wrapping of a module with an interface
> Why can't an interface contain other modules? This would allow
> existing module
> implementations to be "wrapped" within an interface
> implementation and then
> instantiated just like any other interface. For example, I might
> have an RTL
> implementation of a FIFO. I might want to embed this within an interface
> implementation that implements write() and read() tasks.
This is an interesting suggestion. From a hierarchy standpoint, the module
would have to "live" in the parent module that instantiates the interface
(consider drawing it in a schematic). I'm not sure that this is necessary,
however, because the scenario you're describing really splits the interface
anyway. Once you start instantiating modules in the interface, you're really
getting into implementation anyway. If the master module and slave module
communicate through an interface, then breaking the interface in the parent
and putting a fifo module in the middle doesn't affect the modules on either
side.
interface bus;
...
endinterface
module master (interface i);
...
endmodule
module slave (interface i);
...
endmodule
module top;
bus b_i;
master m(b_i);
slave s(b_i);
endmodule
vs.
interface mbus;
...
endinterface
interface sbus;
...
endinterface;
module top;
mbus m_i;
sbus s_i;
fifo f(m_i,s_i);
master m(m_i);
slave s(s_i);
endmodule
The instantiations of master and slave change, but that is to be expected as
you modify the abstraction level of the interface and the parent. Note that,
since they each use a generic interface, their definitions don't have to
change. This makes it much more explicit that you are changing abstraction
and getting into the physical instantiation of a fifo module, but the
presence of interfaces still allows you to isolate these abstraction changes
from the modules connected via the interfaces, which is one of their major
benefits.
This is certainly an area that can be discussed more, since we may want to
allow OVL modules to be instantiated in interfaces, for example. There may
be a way to define what a "passive" module is in this case, and only allow
passive modules to be instantiated in interfaces. Let's discuss.
> ======================================================================
> Section 13.2.3 - Interface usage issues (Stuart/Cadence) [Basic, System]
> - need to be able to specify and enforce rules about interface usage
> - e.g., use of either Read or Write operation but not both
This is part of what modports do.
> - e.g., limits on number of modules/processes invoking a given interface
> operation
I don't see why this is needed.
> - should be possible to define such rules in the interface itself without
> changing other code
> - need to check rules in a way that allows for separate compilation
We should add this to the general separate compilation discussion.
> - need to be able to specify that some tasks/members of an interface are
> private
modports do this.
> "Generic" interfaces allow a module to be attached to different
> interfaces, but
> they do not convey to the reader or allow tools to enforce that
> the module must
> be connected to an interface that implements a specific set of
> tasks or has
> specific members.
Isn't that a parser/linter check?
> As a simple example, there may be several
> different interface
> implementations of a FIFO -- one might gather statistics, another
> might not. In
> both cases modules that might be connected to such FIFOs should have an
> interface declaration that clearly specifies the set of FIFO
> operations that
> must be supported. E.g. write() but NOT read(), or vice-versa. Given the
> current proposed scheme, it can only be determined at
> elaboration-time whether
> an interface binding in a particular case is legal or not.
> Instead I believe it
> ought to be possible to determine this legality at the time a
> single module or
> interface is compiled.
> It should be possible to do port registration checks for interfaces. For
> example, a user might want to implement a FIFO interface that
> enforces that it
> has exactly one module or process that writes to it, and exactly
> one module or
> process that reads from it. It should be possible for the
> designer to create
> such checks only within the interface, without forcing the code
> within modules
> attached to the interface to be modified.
> In SystemVerilog today all tasks and members of an interface are
> available
> to be
> used by modules attached to the interface. This will inevitably
> lead to designs
> or models that use tasks or members of an interface that were
> never intended to
> be used externally. Therefore I believe that it should be possible to make
> certain tasks and members private so that they cannot be accessed
> externally.
Please review the section on modports, because they do allow (at least some
of) what you are proposing. It sounds like you are proposing some new
language features to aid in modular compilation that do not directly impact
the behavior of the model. Perhaps these are better left as attributes or
compiler directives, or maybe they can be included in configurations.
> ======================================================================
I think that this next section really deserves a live conversation at a
future committee meeting.
> Section 13.4 - Modports issues (Stuart/Cadence) [Basic, System]
> - allow modports to be declared outside of interface/module, for reuse
> - allow (modules and) interfaces to specify which modport(s) they
> implement
> - import/export is confusing and unnecessary
> It appears that Modports can only be declared within an interface. Why not
> allow modports to be declared outside of interfaces and modules,
> so that more
> than one interface implementation can implement the same modport?
> This would be
> a less error-prone solution than "generic interfaces".
> The use of "import/export" within Modports is confusing and unnecessary.
> Instead
> I believe that modports should be declared separately from
> interfaces, and the
> tasks that a modport makes available should be declared within
> the modport.
> Then when an interface is to implement the tasks of a modport, it
> explicitly
> indicates this via a "implements mod_port_name" construct.
> Similarly, since I
> believe that modules and interfaces should be equivalent, a
> module that wishes
> to make tasks available to other modules or interfaces will
> simply specify that
> it "implements some_mod_port_name".
> Modules and interfaces should be able to implement multiple modports.
> ======================================================================
> Section 13.5.4 - Issue with extern forkjoin task (Stuart/Cadence) [Basic,
> System]
> - not necessary (at least for the example)
> - unnecessarily inefficient - there are better methods
> "Extern forkjoin tasks" capability is highly specialized and unnecessarily
> inefficient. A much better approach to modeling the example
> within this section
> is to have the simple_bus be aware of the address map for the slaves
> attached to
> the bus -- then only the slave responsible for a particular
> address needs to be
> activated for any request. This would allow us to get rid of the "extern
> forkjoin task" construct altogether and have a much more
> straightforward and
> efficient solution.
>
This archive was generated by hypermail 2b28 : Fri Jul 19 2002 - 07:54:29 PDT