7. Historical Discussion

7.1. Phone Discussion with Cliff

Notes from Cliff on SV Interfaces

Interfaces are good but often overhyped.

Testbench ip developer can describe pins and IO interface of device.

Interfaces for RTL: now someone owns the bus. Now someone uses sender mod ports and other receiver mod ports.

Implement entire bus within the interface.

Write (value), Write (address, value), serial, bytewise, …Read …

Test Interface with itself before attaching it to something else. Use interface for block testing. Use interface for testbench, use interface, queues between blocks implemented in interface

Downside (cliff)

7.2. From Stephen Bailey Email dated 4/21/04:

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.

7.3. From Kevin Cameron Email dated 4/22/04:

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.

7.4. From Kevin C. Email dated 4/22/04 as a follow-up to the above

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

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

7.5. From Steve B. Email dated 4/22/04:

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

7.6. From Kevin C. Email dated 4/26/04:

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

7.7. From Jim Lewis Email dated 4/22/04:

If the interface feature/modeling methodology is going to encapsulate the behavior of an interface, then it needs to support concurrency. Simple interface behavioral statemachines can be implemented with sequential code, however, many models are much easier to implement with concurrency. For example, a UART receiver can be implemented in a sequential manner, however, it is easier when the start-bit detection counter and data bit receive counter are external from the statemachine code.

7.8. From Jim Lewis Email also dated 4/22/04:

Steve and All,

I think our first goal is to define the requirements of an interface methodology and then we can talk about features we need to implement the interface methodology in VHDL. It is confusing as there are already implementations out there that have different perspectives as to what an interface is.

Pictorially, here is the problem I think the interface methodology is trying to solve:

------------                            -------------

           |                           |

 User     | <===> Procedural <===> | Interface

 Model    | <===> Interface  <===> | Personality

           |                           | Model

           |                           |

------------                            -------------

Here a User Model talks to an Interface Personality Model through a standardized Procedural Interface. The procedures provide a standard abstract interface to the model. As such the procedures exchange parameters (address, data, mode values) between the user model and the Interface Personality Model The Interface Personality Model provides the implementation. Different implementations can be provided without changing the procedural interface to the Interface Personality Model.

The reason I think there is some confusion as to the implementation of interfaces is because a language feature only needs to facilitate the interface methodology and perhaps may combine with other structures, such as an entity and/or package to provide the entire solution. So as we start to discuss addition of language features, I think we also need to identify what part of the interface methodology the feature is intended to address. In addition, we need to address where the other pieces of the interface methodology come from.

The SV implementation of interfaces seems to combine both the Procedural Interface and the Interface Personality

Model into one design unit. Keep in mind that this is an implementation of requirements and not a requirement itself.

I think the Interface Requirement list as a place to specify requirements that apply to the big picture of the interface methodology and not just a particular implementation.

Based on my experience in following this type of modeling for testbenches, the Interface Personality Model must have concurrency - or multiple independently executing pieces. The rationale is in the following quote from my previous post:

>> Simple interface behavioral statemachines can be implemented with sequential code,

>> however, many models are much easier to implement with

>> concurrency. For example, a UART receiver can be

>> implemented in a sequential manner, however, it is easier

>> when the start-bit detection counter and data bit receive

>> counter are external from the statemachine code.

The Interface Personality Model is also a nice place to put things like protocol checkers and assertions.

Currently in the requirement list the only thing that I find that addresses concurrency is:

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

This does not address the concurrency requirements of the Interface Personality Model.

Going further, It is my opinion that these procedures can and do block until the parameters are exchanged between the User Model and the Interface Personality Model. Whether the procedures block or not really depends on the nature of the Interface Personality Model. An abstract Interface Personality Model may have an infinitely sized input FIFO, but real hardware will have a limit. As a result, what happens here will need to be flexible to accommodate what the real hardware does. Real hardware will have some policy such as block until the fifo has space or accept the data and throw out old (or new) data.

From a testbench point of view, it is good that the procedural interface can block. Otherwise, how would I set up a sequence of interface operations? Just hand them off and the model infinitely buffers them? For some models, this would just be additional overhead (memory consuming), that is not really necessary.

I think VHDL is very close to being able to do interfaces. I think the big missing piece is the communication

mechanism of the procedural interfaces.

More on this in Part 2

Comments welcome. Since I am not familar with any naming methodology relating to interfaces, I used my own. If

anyone knows a standard naming methodology that would apply here, it would be better to get that part straightened

out sooner than later.

Cheers,

Jim

7.9. From Jim L. Email dated 4/22/04:

All,

In the last email, I presented what I thought is a pictorial representation of the interface methodology:

------------                            -------------

           |                           |

 User     | <===> Procedural <===> | Interface

 Model    | <===> Interface  <===> | Personality

           |                           | Model

           |                           |

------------                            -------------

I think VHDL is very close to being able to do interfaces in this manner. I think the big missing piece is the communication mechanism of the procedural interfaces.

Using only VHDL-93, I have used a form the interface methodology pictured above using records as the communication mechanism. The procedure calls look like the following:

 CpuWrite(CpuRec, ADDR0, X"A5A5");

 CpuRead (CpuRec, ADDR0, DataO);

Parameters plus the record (CpuRec) are passed to the procedure. This approach has proven very powerful.

It also has a big limitation, all objects in the record must have tristate resolution, hence it is limited to the std_logic family.

In fast track proposal, FT17, I proposed a method to give individual record elements a separate in, out, inout, ... (left out open, but we probably need that too). When combined with entities and packages, FT17 would give us a very simplistic interface capability that is similar to SV's modports. Details on the proposal are at:

http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/ft17_composite_interface_mode.txt

Currently FT17 has been deferred to give VHDL-200X a chance to consider other proposals for interfaces

- such as protected types.

I have some reluctancy to defer it as this is a simple, yet powerful extension of an interface methodology that I have been using for around 10 years.

If we go forward with the record IO ala FT17, we have the advantage of being similar to the SystemVerilog extension. In addition, from a user perspective, it seems easy to implement.

The downside is that if we implement this feature, will it prevent us from implementing another, perhaps better language feature?

Protected types has been brought up as a potential alternate solution. This does sound like a promising

potential solution. However, it seems like it is going to take a significant amount of technical work to get it to work across entity interfaces and to allow either signals or named events to be included in the protected type. So from a time perspective, how long will it take to architect a good solution, how long will it take to get it into a language rev, and then how long to get EDA vendors to implement it?

In the SUAVE proposal, Peter has done some work on another communication interface called Channels, is this another possibility?

Cheers,

Jim

7.10. From Tim S. Email dated 4/22/04:

ftp://ftp.synopsys.com/pub/OpenVera_LRM_T_v2.3.pdf/OpenVera_LRM_T_v2.3.pdf

chapter 9 deals with how interfaces are done in OpenVera

the concepts here are more with how the language connects

to the HDL, but there might be some more ideas here of what to

include/not include in an interface. I had to register at the site

before it would let me have the LRM

so do we define an interface in VHDL to be a collection of

ports, signals, variables, enums? is it a standalone

thing? or required to go along with an existing VHDL

construct?

-tim