Re: Strong typing and shared packages

From: John Shields <John_Shields_at_.....>
Date: Tue Jun 12 2007 - 13:17:35 PDT

Hi Kevin,

I'm sorry, but I pretty much disagree with everything you've said.  First, strong typing has nothing to do with shared memory; they are completely orthogonal concepts.  Typing rules are semantic rules, they apply at analysis.  Your comments about this baffle me! As to the OO/methods/API stuff, it is interesting to discuss, but what does it have to do with the interoperability across these languages?  We are are not building APIs to allow stitching simulators that support different languages together.  If that is done, it will be entirely internal to a multi language product suite and it won't be specified for external use anyway.  I believe we must have an interoperability specification that products can be built to support and that accommodates a fair range of flows. It will not be based on some API specification. It will be expressed in terms of aspects of one language, how they may be referenced in another, and what it means to do so. Nothing or as close to nothing as possible will be said about "how" tools can be designed and implemented to achieve it.  I believe you just don't accept that.  Am I right?

Type compatibility is very important but if there is some priority to talking about requirements aspects of this specification, I am happy to proceed in a different order, but I don't see any reason to as yet. Regardless, I don't imagine talking about an object model at the design interface boundary as a way of defining simulation semantics and it has no priority in mind.  The conclusion I am coming to is that you want something from this standards effort that I believe it will never deliver and that is another basic disconnect. Am I missing your intention?

Kev, eventually we will get to consider PLI and how it might work in a multilingual environment, but IMHO, only after we are done with the foundation interoperability specification.  This committee will not specify a simulation backplane and API to interface simulators together.   If that is needed, it will need an umbrella group to be studied under and appropriate sponsorship.  If we need to argue this basic point and resolve it, then let's have at it so we can end up aiming in similar directions again.

There are plenty of interested parties following the discussion.  What you are saying and my reaction to it should not strike others ambivalently either.  I want to keep an open mind and give the greatest benefit of the doubt as to whether I understand the interactions, but this is a thread of thought expressed multiple times by you and I think I get it. We've been at this 6 months and I think we can clarify what we are and are not aiming it, can't we?

-John

K. Cameron [SV] wrote:

John Shields wrote:

Hi Kathy,

Sorry I was not able to participate last meeting, but I was on vacation.  My intent first is to define a conceptual model of the requirement for strong typing and gain a shared understanding of it and why it must be a requirement.  It is just wrong for one strongly typed language to subvert its own strong typing requirements by interoperability with another strongly typed language that shares the same rquirement!  It is correct to see strong typing as the requirement and interpret the shared package as an example of how this could be achieved.  If there was any concern that the strong typing concept did not have possible good approaches, the idea of shared packages should have clarified that.  I absolutely want us to consider and accept the requirement or argue its merits appropriately.  This is primary.

To be provocative, I do suggest the shared package concept is a very effective way of making an interoperable definition of strong typing.  There is plenty of room for a wide variation of tool flows to achieve practical implementations of this. It is consistent with the requirements we are building, particularly transparency. It doesn't present any flaws to me, though we are not debating details of it as a proposed solution. But, I insist that it is not necessary for us to debate this in order to accept the requirement of supporting strong typing.  Consider it an open invitation to anyone to propose other ways to specify how strong types may be used across language boundaries. Got any?

Strong typing is usually required where there is shared memory, and sharing memory between different simulation algorithms/threads is generally a good source of bugs. Personally I prefer a more object-oriented approach with methods and message-passing. Before arguing about the typing there should be a semantic model for the objects on the boundary and an understanding of the methods they should support for simulation to work. IMO typing has more to do with syntax than semantics and the semantics are more important.

For an example you can consider the 4-state logic type in Verilog: in VCS for DPI functions a 4-state vector (less than int size) is represented as 2 ints - the bits of one for 0/1 or Z/X the other indicating which (that's all type information), however semantically I prefer to look at it as an array of objects which have multiple dimensions i.e. value, strength and certainty. So I'd rather see an interface that provides methods (functions) for manipulating the value, strength and certainty than a way of directly sharing the 2 ints worth of memory.

Kev.

Regards, John


Kathy McKinley wrote:

I had an action item from last meeting to start an email discussion
about a point of confusion. We were discussing the binding requirements
type compatibility proposal (http://www.eda-stds.org/sv-xc/hm/0094.html), 
and confusion arose from this paragraph:

  

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.
    

Some interpreted this paragraph to describe a conceptual model and how
it might be applied, and others felt that this paragraph might propose
a specific definition of strong typing involving shared packages.

John, do you want to clarify your intent when you wrote it?

Does anyone have an opinion about either possible direction?

  

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Tue Jun 12 13:17:53 2007