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 accomodate 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
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Bailey, Stephen wrote: > Is there a requirement here that you think I haven't captured? I did address the need for concurrency. > > -Steve Bailey > > >>-----Original Message----- >>From: Jim Lewis [mailto:Jim@SynthWorks.com] >>Sent: Thursday, April 22, 2004 8:24 AM >>To: Bailey, Stephen >>Cc: 'vhdl-200x@eda.org' >>Subject: Re: [vhdl-200x] Requirements for Interfaces >> >> >>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. >> >> >> >>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 >>> >>> >>> >> >>-- >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>Jim Lewis >>Director of Training mailto:Jim@SynthWorks.com >>SynthWorks Design Inc. http://www.SynthWorks.com >>1-503-590-4787 >> >>Expert VHDL Training for Hardware Design and Verification >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > > >Received on Thu Apr 22 11:08:37 2004
This archive was generated by hypermail 2.1.8 : Thu Apr 22 2004 - 11:09:54 PDT