Re: Binding Requirements: compatible types

Not sure I agree with you entirely on this. I'd make a distinction 
between constant types, shared data and signals. For constant types 
(enums etc.) I would leave it up to the user to develop a methodology to 
make sure the values match between languages. For directly shared data 
(i.e. shared memory) it is essential that the languages agree on the 
layout etc., but there is only a standard layout for C/C++ and C++ 
virtual function structures vary between compilers. For signals you want 
to interact at the driver/receiver level, and you should be able to 
support different driver/receiver types across the languages.

The approach I would take is to avoid any directly shared data that 
isn't just C formatted and commonly understood (i.e the linker will hook 
them up), and define methods for the other objects that can be mapped to 
each other across the languages, then combine that with a some external 
definition of type conversion (the XML/Database issue I referred to in a 
prior e-mail). E.g. if you have an signal of type MVL7 in VHDL and a SV 
driver of type bool then you need to find a conversion function for 
SV:bool to VHDL:MVL7 and possibly the reverse too. Since we are not 
discussing APIs it would be up to the vendor to implement the actual 
conversion call mechanism and standard calls, but the conversion could 
be defined by the user if the simulator vendor provides hooks for doing 
so and included in the IP. User's can build up more complex conversions 
on top of the commonly understood ones for user-defined types. The aim 
being that in the longer term when you ship a chunk of (compiled) IP you 
can include an XML description of any accessible interface/internal 
objects and the access methods (e.g. if it's a shared library what 
routines are named and how to call them).

Note: when converting types it is helpful to know whether the conversion 
is lossy or not, e.g. bool -> 4-state is a non-lossy conversion, but 
4-state -> bool is lossy (X & Z don't convert to 1 or 0). When trying to 
apply resolution functions automatically across types you want to use 
lossless conversions to convert drivers to the same type/domain.
Some type conversions require remembering state, which may require using 
a module rather than a function, e.g.: if you are doing a (lossy) 
4-state->bool conversion you might want to hold the last 0/1 value (for 
a while) when you see a Z and its compliment for X.

Kev.

John Shields wrote:
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean. 



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