Re: [vhdl-200x] Interfaces with normal, conjugated and monitor flavours

As the author of one of the proposals, I thought that I'd post some of my
thoughts and in particular comment on the rationale behind them.

It is good that this is being discussed actively again, as I think, specifically
with records being one of the more advanced concepts in VHDL available from the
beginning, they have been restricted by port interconnectivity making them very
cumbersome in use.


1. I do like the idea of specifying an inverse/opposite of a particular 
interface instance. However, 'conjugate' speaks to me more of a joining type of 
function and the obvious choices possibly have other implications. So, my 
suggestion for an attribute name is "converse". (Yes I know in English it can 
mean 'to talk', but as a noun it also means 'opposite' or 'contrary' - that's 
English for you!)

It would give an attribute <interface_name>'converse which to me reads well.


2. Although a lot of interfaces fall into the master/slave concept, there are
cases when more than one kind or instance of the interface port is required.

Hence in my proposal (Interface Construct and Port Mode Configurations) I
started with a simple processor master/multi-slave interface. But it is quite
common now to require multi-master capable buses and this has the first
implication of requiring the master instance to include a slave instance (for
when it's not an active master).

Next an arbiter instance is required to handle the bus request/grant control to
each master capable instance and grant control, or demand relinquish for the 
bus. An example could be a system with a processor core and separate DMA controller.

So, we could have a 'converse' attribute for simple interfaces, but we should
also cater for more complex interface architectures as well.


3. As David has pointed out, types are not modes and modes are not types. They
are constructs fulfilling different necessary requirements in the language.

This was the reason I proposed a new 'interface construct', the purpose of which
was to link modes with a composite type (record or array).

Given that I wanted to provide for more complex interfaces (i.e. not just
master/slave) I needed a mechanism to handle more than one mapping and so I
proposed a 'port configuration construct' within the 'interface construct'.

I suggested some new modes to extend the functionality; 'composite' which may
be redundant if we use an interface.port_construct name mechanism.

I also suggested a 'null' mode to be used to terminate an interface element in
the structural mapping, but would be open circuit through the port, i.e. inside
the entity it would be unavailable for reading or writing, non-existent.

All existing modes would be supported, especially the 'buffer' mode. I use
this extensively in my FPGA designs and it has advantages. However, this
complicates the use of the 'converse' attribute.


4. Generics on interfaces sounds not only good but very necessary in order to
complement the rest of the language.


5. Object-orientation is not an area that I am experienced in, but I do see it
as an added advantage. The inheritance concept sounds good, but as stated we
need to think about adding these globally to those constructs that are able to
use it.


6. My proposal quickly became quite complex. I don't think that complexity is
bad, but it does mean that we need to be careful with new objects and syntax
in order to keep the complexity manageable, and this requirement is
complicated.

-- 

Regards,

Brent Hayhoe.

Aftonroy Limited

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.