Hi,
We have a set of questions meant to define the problem of mixed
language
binding between SV, VHDL, and SC. We recently agreed that this is not
a
complete enough indication of the requirements to formulate a proposal.
We need additional general requirements and a discussion of the
questions and their implications. I agreed to start that discussion
and
offer my view of those requirements. It would be great if we had a
glossary of common terms, but I will borrow terminology and hope it
doesn't become confusing. An aspect of binding that needs a lot of
details to be defined is what types are compatible and how. It is
necessary to define some general requirements in this area and start
from a common vision.
Compatible Types
The term compatible types is used here in the context of mixed language
binding. For example, given a port of a particular type on a design
unit written in language A, what type or types of the actual object in
language B can be connected to it? The answer is the set of 1 or more
types that are compatible with the type of the formal port. One can
address what kinds of objects may be connected to via ports,i.e.,
variables, signals, etc., but that is a separate issue that is deferred
to focus on type compatibility.
SV, VHDL, and SC have rich type systems. Where Verilog had a limited,
fixed set of types, SV now supports user-defined types such as
enumerations, structures, and classes. What basis do you use for making
the detailed decisions about type compatiblity?
Required Support for Strong Typing
If the use of a type in one language must conform to strong typing
rules and its equivalent type in another language also must conform to
strong typing rules, strong typing rules are required at the mixed
language boundary.
What is strong typing? The basic idea is that languages with strong
typing rules impose restrictions on the operations possible between
objects of different types. It may mean rules enforced at analysis,
elaboration, or runtime. These rules may disallow implicit casting or
restrict what can be cast from one type to another. The general goal
is to prevent certain kinds of erroneous or unsafe programs from ever
being written. It may insure that objects do not take on values that
are illegal for its type, which can be the source of some pretty
insidious errors.
Typically, user-defined and abstract types in a language require strong
typing rules. In SV, enums, unpacked structs, unions, and classes (and
perhaps a few others) are strong types. In VHDL the entire language is
strongly typed. In SC, given its foundation in C++ and use of class
types, SC is also strongly typed. Perversly, given that C is the
poster child of weakly typed languages and is the underpinning of C++,
you are empowered in SC to violate strong typing, if you so choose.
Required Support for Weak Typing
If one of 2 languages treats a particular type with weak typing,
regardless if the other treats its equivalent type strongly, it should
be required that weak typing rules are applied at the mixed language
boundary.
Weak typing means little to no rules are applied to operations and, in
general, unsafe implicit casts are performed between types. It can be
very convenient and compact to write code in a weakly typed language.
C, being such a language, is a very effective implementation language
and a lot of C code relies on potentially unsafe operations. No need
to dwell on what bad things can happen if you make a mistake. Weak
typing in SV has its underpinning in the legacy Verilog fixed set of
types and the implicit conversion rules between them. It is very
valuable for types that represent real hardware in which the underlying
meaning is a set of wires and the implicit type conversions reflect the
structural equivalence of a set of wires, an array of wires, a integer
that implies a fixed number of bits, etc. Even in SV's abstract types
is the concept of packed data type and its equivalence to a set of bits.
Given that, the ability to flexibly make connections across mixed
language should recognize the same underlying meaning and implicitly
convert between such types at the mixed language interface. This is
not to say that implicit type conversion does not have its rules. For
example, it does not make sense to say that real or time types are the
same as a set of bits and should be implicitly converted to anything
that represents a set of bits.
Weak typing supports the flexible reuse of existing legacy design units
in Verilog and VHDL in today's mixed language designs. If there are
some necessary complications in the rules or the underlying
implementation mechanisms, they are ...well, necesssary.
Enforcing Typing Rules
It may be difficult to impossible to enforce all the desired type
rules across the mixed language boundary. (That can certainly be true
even within a single language.) We must consider whether the
implication of enforcing a rule means proposing a change to one or more
of the languages. The right approach is to define the rules and where
it is impossible to enforce, to declare the programs that violate the
rules are erroneous. The wrong approach is to discard the rule or
remain silent about it and create ambiguous specification.
For example, SC certainly has strong requirements for matching class
types at its interface. Defining, generating, and using equivalent
derived declarations to do type checking between SV or VHDL and SC
should be part of the specification and implementation. There is a
reality that one can get around any such rules by separate compilation
and linking of SV models and the power of "C" to let to any type-unsafe
operation you desire. Even if some things are just the "power of C",
subverting the declarations in the header is erroneous and may lead to
disaster.
Implications of Typing Rules
One of the ways in which strong typing is defined and enforced is to
say a given type is unique and the only way to declare objects of that
type is to reference that specific type in the declaration of an
object. Kind of obvious really, but there is no other structurally
equivalent type. What does it mean to support strong typing in a mixed
language environment? The same idea applies. The conceptual model
that the user should have is that the "same" type should be used to
declare objects in each language. The practical model is that a single
description of the strong type is declared by the user and it implies a
single equivalent type in the other languages. The
general requirement for transparency suggests that it should not matter
which language is used for that description. A unified and practical
way to specify this is to support the abstraction of shared packages.
Such a package contains types which can be referenced in any of the
languages. The implementation model is also practical, deriving an
equivalent package or header file with a namespace. For now,
regardless of how it is specified or implemented, one has to accomplish
this in order to properly support strong typing.
Supporting weak typing implies a lot of details to define the
acceptable mapping of types. This provides a framework for structural
type equivalence across the languages. Implementation can certainly
take advantage of implicit and explicit casting mechanisms in the
languages. It must be recognized however that there are cases where a
type in one language may be connected to more than one type in another
language that enforces strong typing. For example, If a Verilog
register array can be connected to a VHDL bit_vector or std_logic
vector, there is a point where VHDL analysis will require a component
declaration with a specific type to be chosen for a particular port.
That component declaration is the equivalent to the Verilog module
declaration that is being instantiated. It requires a different
component declaration to connect to bit vectors from the one to connect
to std_logic vectors. This is an implementation problem and
it should
not be a specification problem. The specification should be
defined to allow a Verilog register array port to be connected to a
VHDL bit_vector or std_logic vector.
Regards, John
--
This message has been scanned for viruses and
dangerous content by
MailScanner, and is
believed to be clean.
Received on Thu Apr 26 11:21:07 2007