RE: [vhdl-200x] Requirements for Interfaces

>
> Kevin,
>
> Thanks for taking the time to provide more information. I'm understanding where people are coming from with the entity/architecture derivation for interfaces. I don't like that the architecture has no interface associated with it. In my view, this is similar to what I think is a mistake in SystemVerilog with generic interfaces: There's no contractual specification of what the architecture requires in an interface and no documentation in the entity/arch declaration of those requirements.
>

The architecture would be inaccessable without any interface. All I'm suggesting is that an architecture can have many (rather than just one) and there need not be a particular order to how they are declared. Also, that act of instantiation and the act of port-binding are seperated but aren't significantly sematically different - the port binding would be just as rigourous.

> But, I think that the entity interface can be specified and entity/arch model used for modeling interfaces. The key point is that the language needs a mechanism for connecting up an instantiated interface to all the users of the interface.

All you need is the ability to pass references to instantiated entities through the instantiation hierarchy as well as signals.

The only problem I see is that the hierarchical resolution scheme of VHDL doesn't work very well if there is no recognizable connection hierarchy. But that scheme doesn't model hardware properly, and is particularly bad if you want to do mixed analog/digital, so it might be an opprtunity to move to a flat resolution scheme.
  
> As far as not requiring a new name for the interface entity/arch, I think that there is a key difference. In the interface model, you would not want to specify the directionality of ports. The directionality would come from the "normal" entity/archs that are connected up to the instantiated interface.

I think one of the reasons for modports in SV is that different interfaces will have different directions, e.g. if the architecture in question is a bus arbiter and you want some clients to only read and others to only write to some shared wires. So I think being able to define directionality on a per entity basis is qute important.
  
> There are capabilities that are still missing from the approach of taking entity/archs as the starting point:
>
> - Cannot define a procedural interface to an entity. This can be viewed as a general enhancement to entity interfaces (useful for interface entities and "normal" entities).

I was only addressing the hardware modeling aspects, but I agree that it's not much of a stretch to add functions to entities. There isn't really any need to differentiate "interface" and "normal" entities introducing a semantic difference just makes things unnecessarily complicated.
  
> - Unless some capability for specifying directionality of elements of composite typed interface objects is provided, you still have interfaces that are blasted at the bit and vector levels. With high tens to hundreds of ports, port mapping is a nightmare.

As above, it's defined in the entity, and you just pass a reference to the entity.

> - Support for mulitple levels of abstraction is still not really supported. If we add inheritance to the VHDL type system and allow ports of class type or define inheritance for entity/archs, then we would cover this capability for interfaces as well.
>
> All of the missing capabilities are current language shortcomings anyway. Specifying directionality on an element level would be required for any reasonable use of interfaces. But, the other capabilities can be added later. Which means that it just might be possible to define an interface capability today that is a solid foundation that can be grown (not a deadend) and when these new capabilities are added for the language, in general, we can ensure that they also are exploited for interfaces.
>
>
> Again, thanks for the intellectual contribution.
>
> -Steve Bailey

Happy to contribute,
Kev.
 
> -----Original Message-----
> From: Kevin Cameron [mailto:vhdl-200x@grfx.com]
> Sent: Thursday, April 22, 2004 12:49 PM
> To: vhdl-200x@eda.org
> Cc: Bailey, Stephen
> Subject: Re: [vhdl-200x] Requirements for Interfaces
>
>
> Steve Bailey wrote :
>
>
> Kevin,
>
>
>
> I'm only partially appreciating your ideas here. But, enough to think that there is some possibility for a solution and that it could be an elegant solution. Do you have time to write this up in more detail and perhaps with an example of how it might be used?
>
>
>
> -Steve Bailey
>
> Not sure I have time to write a whole lot on this, so I'll just try to make a couple of points...
>
> Verilog and VHDL are based on software programming languages, so module (entity/architecture) definitions are syntactically similar to routine call definitions. However languages like ADA and C are designed for execution on stack machines where it doesn't make much sense to have more than one interface to a routine since it only exists dynamically on the stack, whereas HDLs statically instantiate modules so the interface objects (signals etc.) are permanent - which is more like a class instance in (say) C++, and like C++ it should be possible to have multiple methods of accessing the object.
>
> An alternative way of looking at it is that Verilog and VHDL overloaded the instantiation mechanism (which is hierarchical and routine-call like) with the connectivity mechanism (port binding) , and have therefore acquired unnecessary restrictions on the connectivity. Verilog gets out of this problem by providing cross-module referencing, SystemVerilog just formalizes/simplifies the use cross module referencing by adding modports etc. to handle complex cases more elegantly.
>
> So for VHDL I'd suggest some inversion of the relationship between entities and architectures, so that you can instantiate an architecture without using an entity and you can connect to architecture instance through different entities at the same time. E.g.
>
>
> architecture foo is
> ....
> end
> entity bar of foo is
> port (A,B);
> end
> entity pwr of foo is
> port (VSS,VDD);
> end
>
>
> [NB: my VHDL is very rusty so please excuse syntactic lapses :-)]
>
> 'foo' can be instantiated without binding ports, and then other instances can bind to its different entities e.g.:
>
>
> foo : foo1; // instantiate a foo (foo1)
> // bind power rails to foo
> pwr_rails : pwr1 port map(foo1.pwr);
> // connect an ab_arch to foo1's bar entity/interface
> ab_arch : ab1 port map(foo1.bar);
>
>
> You could use "interface <name> of <architecture>" rather than "entity <name> of <architecture>", but I don't think there's enough semantic/syntactic difference to make the addition worthwhile.
>
> Note: this ties into the discussion previously about the scoping relationship between entities and architecture, i.e. for the enitity-of declaration you probably want to be able to access all the items in the architecture and be able to promote architecture items to ports.
>
> Kev.
>
>
>
> -----Original Message-----
>
> From: owner-vhdl-200x@eda.org <mailto:owner-vhdl-200x@eda.org>
>
> [ mailto:owner-vhdl-200x@eda.org <mailto:owner-vhdl-200x@eda.org> ]On Behalf
>
> Of vhdl-200x@grfx.com <mailto:vhdl-200x@grfx.com>
>
> Sent: Thursday, April 22, 2004 2:13 AM
>
> To: vhdl-200x@eda.org <mailto:vhdl-200x@eda.org>
>
> Cc: Bailey, Stephen
>
> Subject: Re: [vhdl-200x] Requirements for Interfaces
>
>
>
>
>
>
>
> IMO a mistake in SystemVerilog was creating interfaces as seperate
>
> objects. The functionality in interfaces could have been included in
>
> modules, and adding a "connect by module reference" mechanism
>
> in module
>
> port syntax would have done the rest. The split module/interface
>
> approach does not work well with design decomposition in a
>
> top-down/bottom-up design flow. The concept of interfaces in
>
> SV seems to
>
> be targetted mostly at bus-ripping, which is fine except that
>
> busses are
>
> often much more complicated than bundles of wires these days and SV
>
> interfaces don't really cater for that. Also, there was very little
>
> consideration of how the mechanisms would work with back-annotation.
>
>
>
> If you consider VHDL entities is being similar to an SV modport and
>
> allow an architecture to be associated with more than one
>
> entity, and
>
> allowed instance/entity references to be passed through
>
> ports, I think
>
> you would get most of the functionality needed.
>
>
>
> Kev.
>
>
>
> Bailey, Stephen wrote:
>
>
>
>
>
> I had the action item of documenting (at least starting a
>
>
>
> list of) requirements for interfaces.
>
>
>
> Before setting out the requirements a couple of
>
>
>
> comments/observations:
>
>
>
> - I believe that there are shortcomings in the
>
>
>
> SystemVerilog specification of interfaces. I hope we can
>
> learn from them and provide a better solution.
>
>
>
> - When we discussed interfaces in the meeting, I noted
>
>
>
> that there were at least 3 different starting points that
>
> people used when thinking about possible solutions:
>
>
>
> - Based on records
>
> - Based on protected types (with inheritance
>
>
>
> added for fuller OO-type capabilities)
>
>
>
> - Based on entity/architectures
>
>
>
> To me, this indicates that some characteristics of a
>
>
>
> solution to providing Interfaces in VHDL resides in all 3,
>
> but that none of the 3 are sufficient.
>
>
>
> 1. The general need is for packaging together related data
>
>
>
> items but allowing specific data items to flow in different
>
> directions across a port interface. Records serve the former
>
> purpose, but the port mode applies to the entire record.
>
> There's no mechanism for specifying the mode on an individual
>
> element basis.
>
>
>
> 2. Another general need is to define complex interfaces
>
>
>
> (busses are the obvious example) once and then pass them
>
> around the design.
>
>
>
> 3. The interface needs to support multiple levels of
>
>
>
> abstraction. Signals can be thought of as relatively low
>
> level. Even with signals, the need to support all data types
>
> at least partially satisfies the need but not completely.
>
> There is also a need to allow a procedural interface as well.
>
> For example, that a bus supports read and write operations
>
> without specifying how that is implemented (serial or
>
> parallel, what control, address, data, etc. signals are
>
> necessary and the specifics of the protocol).
>
>
>
> 4. The interface needs to be able to encapsulate the
>
>
>
> abstraction level such that users of the interface are not
>
> dependent on how the interface is implemented.
>
>
>
> 5. Once you define a procedural interface, there is a need
>
>
>
> to maintain concurrency. That is, a call to an interface
>
> routine does not block the caller. The interface can do its
>
> data transfer job while the caller goes about doing any other
>
> business.
>
>
>
> 6. When an entity is defined to require an interface, there
>
>
>
> needs to be some contract that the interface will provide
>
> capabilities that the architecture implementation of the
>
> entity requires and depends on. One way to look at this is
>
> via an object-oriented analogy. A base class defines that
>
> all derived classes must provide read and write operations.
>
> The entity interface would be declared to be of the base
>
> class. The actual associated could be a serial or parallel
>
> implementation derived from the base class. (Note: The OO
>
> analogy is provided only to help explain the requirement. It
>
> is not a specific proposal for how interfaces should be implemented.)
>
>
>
> 7. Of course, entities must be able to be connected
>
>
>
> hierarchically with interfaces.
>
>
>
> 8. It should be possible to define generic, reusable
>
>
>
> interfaces. For example, parameterizing interfaces via
>
> generics. Easy extensability, etc.
>
>
>
> 9. It would be nice to be able to add delay at the
>
>
>
> interface. Currently, delays can only be specified at the
>
> driver. If the interface can add a delay in transport, then
>
> it makes it easier to model certain timing-sensitive situations.
>
>
>
> If anyone has additional requirements or examples of
>
>
>
> expected use, please forward them to me.
>
>
>
> ------------
>
> Stephen Bailey
Received on Tue Apr 27 01:23:50 2004