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]On Behalf
>>Of vhdl-200x@grfx.com
>>Sent: Thursday, April 22, 2004 2:13 AM
>>To: 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
>>>303-775-1655 (mobile, preferred)
>>>720-494-1202 (office)
>>>www.model.com
>>>
>>>
>>>
>>>
>>>
>>>
>>--
>>http://www.grfx.com
>>mailto:dkc@grfx.com
>>
>>
>>
>>
>>
Received on Thu Apr 22 11:48:44 2004