Hi,
First, my thanks to Logie
for setting up the email
reflector. It will make it easier to offer and review inputs. Second,
I want to offer some additional thoughts on the framework,
particularly with regard to SV and VHDL. This is not the subject of
today's meeting, but something to consider going forward.
The Elaboration Model
I think it is important
to remain grounded in the existing
models of elaboration for both languages. VHDL prescribes a top-down,
one pass
elaboration model. Parameterization flows strictly downward. As we
look to enable mixed language interoperability, we may desire features
which
will require fundamental changes to the elaboration model, but I expect
this will be a constraint that we live within. A
reasonable way to think about it is to require the same restrictions
for
instantiation as a Verilog generate scope with respect to parameter
propagation, whether it is Verilog instantiating VHDL or VHDL
instantiating
Verilog. We will find an impact on extending the concept of
hierarchical
references across languages as well. Even if we wish to propose change
in the elaboration model, we must separate interoperability that
works within it from aspects that require significant change.
I regard the
non-determinism in event ordering to be an
equally strong constraint in Verilog. Compromises to it will affect
performance and existing implementations that exploit that degree of
freedom. Attempting to define delta cycle behavior in a mixed VHDL
environment such as when events propagate across language boundaries
should not lead to
changes in defined simulation cycle for either language. The focus
should be clarification of what should happen as a result of those
constraints.
Transparent Extension to
Core Languages
If it is the case that a
desired interoperability will only
be feasible with language changes to one of the Core languages, we may
be at
liberty to expect it of SV, subject to normal consensus process. If it
is a change to
VHDL( or SystemC, Verilog-AMS,..), we can only make that as a request
to
another standards committee, the stewards of the particular language.
We need to be careful to separate our
interoperability features to aspects that do not depend on core changes
from
those that do, and define and cross-reference the dependencies
explicitly.
In the details, there is an approved IEEE 1076 standard and there is a
recent
Accellera approved revision “1076 D3.0”. We should treat D3.0
dependencies in the same manner. A couple of examples to consider:
Because of the extensive
type system in SV, one extension to
consider is the concept of an abstract (opaque, or foreign) type to be
added to
all the languages under consideration. It would allow declaration of
parameters and ports of such a type, the ability to connect any object
to such
a typed object, and pass it through the instantiation hierarchy to
instances that understand the actual type of the object. One might
even provision access methods,e.g., a cast kind of operation to a
native type. How important this may be and
what additional features are required is can be determined. I use it
to
illustrate a realistic extension quite out of our full control.
Package interoperability
between VHDL and SV is similar
extension. Given some restrictions, it would be possible to declare a
package in one language and reference types and objects in that package
in
either language. It certainly has some nice characteristics in terms
of
type safety that both SV and VHDL have. Yet another illustration of an
extension out of our control?
Perhaps. This one also might be handled in terms of an equivalent
package
declaration implied from one language to the other and not require
extensions
to the core language, but a definition of the equivalence.
Our final results may
define mixed language interoperability
with multiple levels of compliance. We should certainly have a
successful
1st level that builds upon the capabilities for mixed
language in
existing products today. It is because these have proven production
worthy use models that we should codify them. If we extend them
carefully, we can maximize the speed at which sv-xc specs are approved
and
embraced in the market.
Regards,
John Shields
Mentor Graphics
This archive was generated by hypermail 2.1.8 : Wed Jan 10 2007 - 07:58:19 PST