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
>303-775-1655 (mobile, preferred)
>720-494-1202 (office)
>www.model.com
>
>
>
>

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