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

From: <>
Date: Thu Mar 05 2015 - 00:21:40 PST
> The issue for me is that the whole discussion has focused entirely on
> signal ports of an entity/block. In my opinion two things are
> missing. First, it should be possible to abstract the parameters of
> subprograms in a similar way. The reason for this is the concurrent
> procedure call, whose signal parameters have similar requirements as
> entity/block ports. However, subprograms have interface objects
> other than signals, so a signal centric view is not sufficient, i.e.
> the object class would have to be another discriminator. And this
> brings me to the second issue. In VHDL-AMS the ports of an
> entity/block may be quantities or terminals, in addition to signals.
> Again the signal centric view is not sufficient here. In addition,
> while quantities have types and a mode, terminals have a nature
> instead of a type, so basing an interface concept on types will not
> scale to VHDL-AMS.

I really see and understand your point.  Clearly, the initial proposal
was only considering signal ports.

> It is certainly possible that I misunderstand the intent and scope of
> this discussion. To clarify, I think it would be helpful to write
> down the requirements to be addressed by a port abstraction in a
> neutral way, including aspects raised in the 6 proposals listed in
> John Aasen's email. The different ideas can then be assessed against
> these requirements.

It would also be nice if you could write an informal example of a syntax.
(this is far from a proposal but this still really helps the discussion).

I still fail to see how terminals and signals could be mixed together.
We could create a named interfaces list (the initial interface proposal),
but then creating objects from it won't be obvious (places where
you can declare signals are mutually exclusive with places where you
can declare variables).


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Mar 5 00:21:51 2015

This archive was generated by hypermail 2.1.8 : Thu Mar 05 2015 - 00:22:35 PST