[vhdl-200x] Re: Requirements for Interfaces, Part 2

From: Jim Lewis <Jim@synthworks.com>
Date: Thu Apr 22 2004 - 11:50:34 PDT

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

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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:50:37 2004

This archive was generated by hypermail 2.1.8 : Thu Apr 22 2004 - 11:52:10 PDT