Hi,
There are questions about library organization and binding syntax to be
considered and I would like to shed light on some issues. Libraries
have different conceptual models in SV and VHDL.
In the abstract sense, they are repositories for design data to allow
organization for understanding and reuse. We have to reconcile how
libraries are used and how design units are referenced in SV and VHDL.
We need not change the library model defined in these languages
for interoperability. There are many ways in which language specific
tools might implement libraries and some implementations lend
themselves to cross-language interoperability more than others. How
libraries are implemented is the domain of the tool providers and the
LRMs have little to say about it for good reason. Our mixed language
specs have to focus on the semantics of how to reference design units
from a different language, not how tools implement it including what
library management features they provide. In fact, we have to be
careful not to create unnecessary boundaries on what can be provided so
that different tool architectures can address the mixed language
referencing problems their own way.
Some Verilog Background
In SV and Verilog, the LRM treats libraries as certain structure in a
file system, e.g., a directory of files, where the content is HDL
source
code. There is no strong concept in SV of analysis producing a result
that is placed in a library to be referenced. One can reference a
design unit in module instantiation without a definition ; such a
reference is initially unresolved. The Verilog library is used to
search for definitions in source code that satisfy those references.
They must be satisfied when the final design is elaborated and, in
general, all unresolved references must be satisfied by that time.
This library model arose historically from the first Verilog
simulator implementations that were load and go architectures. The
analysis and
elaboration into a runtime model directly from source code found the
need
to organize source code in libraries. Rather than require all the
files needed for the design to be supplied directly to the simulator at
invocation, you could provide libraries to search for source code that
matched a reference to a module in an instantiation. You could
organize
the source for many modules in a single file and call it a library or
you organize in a directory of files, suitably named to match the
module
reference and call it a library. With a need to search multiple
libraries, rules for search order were a necessary feature of Verilog
tools. Virtually nothing is said about a library concept in the early
LRM revisions ; tools provided fairly simple controls to support this
library model.
As tools evolved to support compilation of models the library model
could now become persistent. Linking pre-compiled modules from a
persistent library and managing consistency with
changes to source code becomes a new concern of library management.
From the point of view of the language, one still can refer to modules
that have not been defined yet, search for them and load them on demand
from source code, or load them from pre-compiled libraries. Search
order still matters. The LRM didn't need to change to accommodate a
new tool architecture and neither did the library model. Tool
implementations did and the library implementation was extended
accordingly.
Verilog evolved to support design configuration. This feature enables
more precise control over what design unit (module) from what library
is used to satisfy a particular module reference in an instantiation.
Searching libraries in some order and taking the first match for all
references to a module has its limitations. You can't always organize
libraries the way you want without creating search conflicts for
modules with the same name in different libraries. You certainly can't
elaborate a design and have different instances of a module use
different representations. Configurations address these needs. They
describe the means to specify the exact source code you require and
bind it to
specific instances.
Verilog's library model is formalized into a library with a logical
name that contains a set of design units (verilog uses the term cells)
that may be modules, primitives, or configurations. The conceptual
model of
the configuration is a set of rules that more precisely control the
search of a particular library or libraries to satisfy particular
instances. In the limit, one can map a specific instance to a specific
module in a particular library. The language needs a way to directly
reference a design unit from a library in a configuration and such
references look like <library-name>.<cell-name>. (there is
more detail to quibble about, but not now).
References to an instance take the form of a Verilog hierarchical
identifier, topmod_identifier{.instance_identifier} The need to
reference libraries in the language led to the need to use a simple
identifier for the library name (dare I say, a logical library name ;)
and a requirement for specifying a logical to physical pathname mapping
separately. There is even the concept of the default or work library
as the place where anything not targeted to a specifically named
library will go.
Because of the historical perspective and the desire for backward
compatibility, the Verilog specs mention that the simple library search
model should apply in the absence of configurations and even suggest a
specific command line option for identifying libraries and search order.
SV added a number of kinds of design units that may be in a library,
namely, packages, interfaces, programs, and macromodules. Having added
the package, it is possible to use items in package by importing from
the
package, either everything or a specific item. You can in fact
reference a specific item from a package directly at a point of use. It
is now a requirement that a
package must exist before it is used in SV.
This is the history, but the idea of viewing a library as collections
of source code is outdated and arguably broken. The use model for
separate compilation, the presence of types in packages, and the
requirement for strong typing in the language are difficult to
conceptualize and reason about when a library is viewed this way. No
important, modern implementations appear to be built this way either,
even if they have backward compatible operational modes for legacy
Verilog. On the other hand, a library as a logical container of
design units that were analyzed from source code, whether persistent or
not, is a conceptual model that does work.
Some VHDL Background
It is a little easier to talk about the library model in VHDL
because it did not evolve organically. The VHDL library model has been
part of the language from day 1.
It is a repository for independently compiled design units. A design
unit must be analyzed into a library before it can be
used/referenced. While one can directly instantiate a design unit,
the original language design allowed for the definition of a component.
You may conceptualize it as a virtual design unit that will be
eventually bound to a real design unit. Components would then be
configured,i.e., its binding to specific design described. There are
multiple language mechanisms for doing this, but there is a specific
design unit kind, the configuration declaration that allows
configuration of instances in a design unit (or for the complete design
hierarchy) at
elaboration.
Libraries are referred to in VHDL source code by logical name and there
is a tool specific mapping mechanism required to associate that name to
a physical path. The implementation of a library is tool specific.
There is a default library called work, which is the target for a VHDL
analyzer(compiler) to put its compiled design units. There is a
concept in VHDL design unit construction of separating interface from
implementation. This facilitates having an interface with more than
one implementation and making changes while keeping the interface
unchanged. To relate VHDL design units to SV terminology and
concepts, an entity is the interface of a module, and an associated
architecture is the rest of its body. An entity may have multiple
architectures associated with it. A specific entity/architecture pair
corresponds to a module definition. A VHDL package is also separated
into two parts, its package header and its package body. The pair
taken together correspond to a SV package. Architectures and package
bodies cannot
exist without their correspond entity and package header being defined
first. As such they are referred to as secondary design units and they
do not share the same namespace with primary design units in a
library.
In the final elaborated design, a instance of a design unit must
include its
implementation. If I instantiate a component in VHDL and configure
that component instance, I need to refer to design unit in the library,
a specific entity/architecture pair. The syntax is
<logical_lib_name>.<entity_name>[(arch_name)] If I
wish, I can omit the architecture name and the language states that
the last compiled architecture is implied. In general, I refer to
design units in the library as
<logical_lib_name>.<design_unit_name>, where design unit an
entity, package, or configuration. In a direct instantiation
statement, I can specifically instantiate an entity/arch pair or a
configuration. The latter represents a specific entity/arch pair with
whatever details I wish about configuring child instances in its design
hierarchy. For packages, if I wish to use them, I refer to them in a
use clause. I can refer to the entire package or
to specific declarations in the package by name. (There is equally a
lot more VHDL language detail to quibble about, but not now)
VHDL does not search for a design unit in a library like SV. It either
has a direct reference
to a specific design unit in a specific library or it has a reference
to a
design unit and an unambiguous set of design units that are visible.
I can make
all the declarations in a VHDL library visible with a use clause. I
can in fact make all the declarations in multiple libraries visible.
What happens if that creates ambiguity, i.e., 2 design units from
different libraries with the same name being made visible at the same
time? The answer for
the language is that neither will be directly visible, the names hide
each other, and the only way to reference one of them is via an
explicit reference.
Summary Background
The general abstraction for a library between VHDL and SV is
compatible. Both see a logical library of design units. The
languages and tools use libraries differently, of course.
SV tools searches libraries to find references and does not need all
references defined before use for analysis of source code. Order of
search matters and first one found wins. SV packages must be defined
before they are used; that is a key example of an order of compilation
rule for SV. Other design unit references in SV code may be unresolved
at src code analysis but must be resolved at final
elaboration. VHDL requires design units to be defined before they are
used; all design unit references in VHDL must be defined before they
are used. There is no search, any reference to a design unit in VHDL
src code, if found, was a unique reference to that design unit in a
specific library.
The way that the individual languages use libraries is what it is and
should not be changed for SV-XC. What can be unified for mixed language
is
being able to adequately reference design units in a library and
instantiations in the design hierarchy. In like manner, the
requirements for definition before use, i.e., order of compilation
rules is also fixed in the individual languages and should not be
changed.
One must respect those requirements and derive their implications for
mixed
language.
Requirements
1) It is a tool issue to determine what kind of design units may be
placed in the
same library
Because the implementation of a library is a tool issue, tools designed
for different languages may have different library architectures.
The SV-XC has no need to require that library architectures be
unified in mixed language solutions. A tool should be free to require
a given library to contain only SV or only VHDL design units.
2) The LRM should enable library architectures that allow design
units from different languages to coexist
This is in part a corollary of 1), but it is stronger than that.
In general, enabling a wide variety of tool implementation approaches
allows for the
best functionality, performance, and usability. A library that can
contain SV, VHDL, or SC design units enables a higher degree of
transparency for users. It keeps functionality for handling libraries
orthogonal to the compilers/analyzers that construct those design
units. SV-XC should consider the namespace of a library and identify
name
conflicts arising from mixed language and rules for disambiguating them
where possible. The goal is to maximize transparency and identify
pathological conflicts. While it may end up as just a consequence of
defining how identifiers are mapped and references to design units are
made, it should be a consideration in those decisions.
3) The LRM should provide rules for referencing design units that
maximize
transparency (BTW, principle applies to all identifiers that must be
referenced cross language)
While there are differing rules for identifiers in SV and VHDL, there
are escaped identifier mechanisms to preserve names that would
otherwise be illegal in both languages, too. The ideal mapping is to
use names that do not need to be escaped to be legal and do not cause
name conflicts with other identifiers. The result is cross languages
references that are transparent. The worst mapping is to take all
names
in one language and require that they be referred to with escaped name
syntax in the other language. It would be mostly a needless burden for
users and a loss of
transparency. The trick is to be minimalist in the application of
escaped names and place the burden appropriately. For example, a
tradeoff may exist where adding a name to a
namespace creates a conflict that differs only in case. Where that is
intentionally done, the burden of escaped names and loss of
transparency is a cost to be paid. It should be paid by those who
choose it, whether the choice was made by forcing the issue with
available tool controls,
or by rules that automatically recognize conflicts. The same
identifiers that are
otherwise legal should not gratuitously escaped because it is easy to
implement.
4) Ditto 3) for identifiers in instance names,
parameter(generic names), port names
This is a foundation for defining the necessary cross language
references for binding. The syntax for binding in language A to
reference design units and connections to formals in language B begins
with rules for mapping these identifiers.
5) The LRM should reconcile VHDL architecture references with
language changes
One references a specific module in SV by module_name whereas in VHDL
one specifies an entity/arch pair. The latter has syntax is
"entity_name( arch_name )" which does not fit neatly into the grammar
of SV where such references are used, e.g., in module instantiation
stmts and configurations. A simple, transparent answer is to use the
VHDL convention of "last compiled architecture" and leave off the
arch_name. This works, but limits some use cases. One can encapsulate
the binding in a simple vhdl configuration and then in sv, bind the
instance to that VHDL configuration. The will work better
syntactically, right? It does not have ideal transparency. Another
alternative is
to propose a change to SV grammar to allow arch_name to be conveyed.
Making grammar changes to
SV is "higher bar" than defining cross language semantics using the
existing grammar, but at least this is an SV standards effort.
Implications
With this kind of referencing as a foundation, the other
considerations of binding syntax in specific language constructs can be
examined. Hopefully, they remain orthogonal. This is a good partition
of the concerns.
It is tempting to discuss how one implements solutions. In general,
these should be private concerns. The important belief is that good
solutions are feasible. For example, if I reference an SV module that
I wish to instantiate in a VHDL architecture, and I have followed good
practices consistent with the SV-XC spec, mixed language tool
implementations should be able to support that transparently. One tool
that is analyzing VHDL may be able to directly load a design unit that
is written in SV. Another may generate a VHDL artifact for that SV
module when the SV model is compiled and refer to it transparently.
Another may require the user to run a utility to generate the interface
from the SV source code (or pre-compiled design unit in the library), a
final tool may require the user to hand code some VHDL to conform to
the SV-XC specs for what the SV module means in a VHDL context. I
purposely described tools with a wide range
functionality and usability, and the LRM can validly allow for a wide
range
of solutions including ideal ones. They all end up allowing the same
final design to be composed from the same mixed language set of design
units.
There is an important implication we should anticipate that affects
solutions. There should be some additional order of compilation rules
when a design in language A will make references to design units
written on language B. Some are obvious, though they need to be
stated. If you wish to compile VHDL with references to design units
from another language, it is required that those design units exist in
a library. In looking at SV, does that mean that the source code for
the design unit needs to exist or that it needs to be compiled by an SV
analyzer? In other words, how strongly do we need to state the
requirement in the SV-XC spec and still enable the widest range of
implementations?
Because the VHDL analyzer requires that a design be analyzed and
exist in a library before it can be referenced, there should be
a requirement that a VHDL analyzer can find some analyzed artifact
that represents an SV design unit before referencing it. It would
be unrealistic to require that a VHDL analyzer would need to find
and analyze SV code from source as part of the VHDL analysis. The
LRM should not however specify the nature of the SV design unit
artifact, merely that one should exist in the VHDL library.
Conversely, a VHDL "compile before reference" requirement should
not apply to a reference from SV to VHDL with the exception of
package references if such references would be legal. However,
as with normal SV to SV references, referenced design units would
have to exist for elaboration to succeed.
In either case, the foreign language design units have a "first class"
status in the other language -- the requirements regarding the
existence of foreign design units are defined by the referencing
language semantics and are neither stronger nor weaker than the
requirements for a same language reference.
There are some other namespace anomolies to consider and they will
play a role in library organization. In SV, there are some defined
name spaces that allow the same name to be used for different kind of
things without conflict. The same is true of VHDL, but they are
different of course. However, libraries should be
allowed to independently define their namespace requirements as
repositories of design units. For example, even if SV allows
modules and packages to have the same name, a library that is a
directory of files cannot allow multiple files with the same name in
the same directory. This applies to a library that supports design
units from different languages to coexist. The implication for SV-XC
is that rules for cross language references to design units in a
library will imply the introduction of one or more names to a library
that contains mixed language design units. The underlying requirement
is that the design unit can be referenced from all supported
languages. SV-XC should state such implications and preserve tool
freedom to define a library's namespace to allow or disallow such
additions. Really not a big deal, this is just proper handling of
pathological cases. A highly interoperable, transparent solution
should
still be enabled.
Regards, John
--
This message has been scanned for viruses and
dangerous content by
MailScanner, and is
believed to be clean.
Received on Fri, 04 May 2007 15:41:02 -0700