InterfaceSemanticsDiscussion < P1076

P1076 Web>Vhdl2019CollectedRequirements>InterfaceAndBundleEnhancements>InterfaceSemanticsDiscussion (2016-08-19, BrentHahoe) (raw view)EditAttach
---+!! Interface Semantics Discussion

%TOC%

Interface construction within VHDL is largely supported by 
<sticky><a href="../P1076/GlossaryVHDL2008#composite type">composite types</a></sticky>,
which include
<sticky><a href="../P1076/GlossaryVHDL2008#array type">array types</a></sticky>
and
<sticky><a href="../P1076/GlossaryVHDL2008#record type">record types</a></sticky>.

These allow multiple 
<sticky><a href="../P1076/GlossaryVHDL2008#element">elements</a></sticky>
to be grouped together  with either a common type (arrays) or different
types (records).

These types can be associated with 
<sticky><a href="../P1076/GlossaryVHDL2008#object">objects</a></sticky>,
of class 
<sticky><a href="../P1076/GlossaryVHDL2008#constant"><b>constant</b></a></sticky>,
<sticky><a href="../P1076/GlossaryVHDL2008#signal"><b>signal</b></a></sticky>,
or 
<sticky><a href="../P1076/GlossaryVHDL2008#variable"><b>variable</b></a></sticky>.

---++ Interface Requirements

   1. The ability to control directionality of <sticky><a href="../P1076/GlossaryVHDL2008#composite type">composite type</a></sticky> <sticky><a href="../P1076/GlossaryVHDL2008#object">objects</a></sticky> at interface boundaries.
   1. The ability to add into, or strip out from a <sticky><a href="../P1076/GlossaryVHDL2008#composite type">composite type</a></sticky> <sticky><a href="../P1076/GlossaryVHDL2008#object">object</a></sticky>, individual elements (e.g. clocks and resets) with zero <sticky><a href="../P1076/GlossaryVHDL2008#delta cycle">delta delays</a></sticky> incurred.
   1. The ability to group together <sticky><a href="../P1076/GlossaryVHDL2008#object">objects</a></sticky> of class <sticky><a href="../P1076/GlossaryVHDL2008#signal"><b>signal</b></a></sticky> and subclass <sticky><a href="../P1076/GlossaryVHDL2008#shared variable"><b>shared variable</b></a></sticky> as a named interface construct (heterogeneous interface).

---++ The Element Mode Problem

The main problem is encountered when the 
<sticky><a href="../P1076/GlossaryVHDL2008#object">objects</a></sticky>,
of class 
<sticky><a href="../P1076/GlossaryVHDL2008#signal"><b>signal</b></a></sticky>
and 
<sticky><a href="../P1076/GlossaryVHDL2008#variable"><b>variable</b></a></sticky>
are 
<sticky><a href="../P1076/GlossaryVHDL2008#declaration">declared</a></sticky>(
as a 
<sticky><a href="../P1076/GlossaryVHDL2008#composite type">composite type</a></sticky>)
at an *entity* or *procedure* 
<sticky><a href="../P1076/GlossaryVHDL2008#interface list">interface</a></sticky>
and this is the ability to assign different 
<sticky><a href="../P1076/GlossaryVHDL2008#mode">modes</a></sticky>
to each  
<sticky><a href="../P1076/GlossaryVHDL2008#element">element</a></sticky>
(or   
<sticky><a href="../P1076/GlossaryVHDL2008#subelement">subelement</a></sticky>).

Objects of class 
<sticky><a href="../P1076/GlossaryVHDL2008#variable"><b>variable</b></a></sticky>
are routeable within their *process* or subprogram environment through the
interfaces of other subprogram instantiations.

Objects of class 
<sticky><a href="../P1076/GlossaryVHDL2008#signal"><b>signal</b></a></sticky>
are also routeable hierarchically above these levels through the
interfaces of *entity* instantiations and *block* statements as well as
subprogram interfaces.

This problem can be addressed with the new (<b>port</b>) *view* construct concept.

---++ Access of Objects via Package Scope

However objects of class 
<sticky><a href="../P1076/GlossaryVHDL2008#signal"><b>signal</b></a></sticky>
can be declared within a *package* which can then be accessed globally via their 
<sticky><a href="../P1076/GlossaryVHDL2008#scope">scope</a></sticky>
alone, i.e. they  are not necessarily routed.

In this way they are similar to the 
<sticky><a href="../P1076/GlossaryVHDL2008#subclass">object subclass</a></sticky>
<sticky><a href="../P1076/GlossaryVHDL2008#shared variable"><b>shared variable</b></a></sticky>
which is only accessible via its 
<sticky><a href="../P1076/GlossaryVHDL2008#scope">scope</a></sticky>
and more specifically through the 
<sticky><a href="../P1076/GlossaryVHDL2008#method">methods</a></sticky>
declared by its associated 
<sticky><a href="../P1076/GlossaryVHDL2008#protected type"><b>protected
type</b></a></sticky>. They are not routeable.

For verification environments, a heterogenous mechanism to allow the
association of these objects could be something like the *group* construct. 
This is not viable as the *group* construct specifically precludes a 
*shared* *variable* from inclusion within a group.

A new similar heterogenous *interface* grouping construct could allow this function,
but it is probably sensible to limit this grouping to *shared variables* and 
*global signals* (and if required *signals* with *variables*). Is it worth adding
a new keyword to define a new subclass of *signal* declared in *package* as a
*global* *signal* ?



-- %USERSIG{BrentHayhoe - 2016-08-18}%
---++ Comments

%COMMENT%
Topic revision: r2 - 2016-08-19 - 12:18:10 - BrentHahoe
P1076