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.
 
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.
 
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.
 
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).
 
  - 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 tenst to hundreds of ports, port mapping is a nightmare.
 
  - 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

-----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

ModelSim Verification TME

Mentor Graphics

sbailey@model.com <mailto:sbailey@model.com>

303-775-1655 (mobile, preferred)

720-494-1202 (office)

www.model.com <http://www.model.com>

--
http://www.grfx.com <http://www.grfx.com> 
mailto:dkc@grfx.com <mailto:dkc@grfx.com>