more input for frameworks discussion

From: John Shields <John_Shields_at_.....>
Date: Wed Jan 10 2007 - 07:57:46 PST

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.

 The Runtime Model

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.

 Compliance

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 message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Wed Jan 10 07:58:18 2007

This archive was generated by hypermail 2.1.8 : Wed Jan 10 2007 - 07:58:19 PST