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

From: Peter Flake <flake@elda.demon.co.uk>
Date: Sat Feb 21 2015 - 11:07:59 PST
If we make the interface a type, so that signals and variables can have that type, this proposal has similarities with a previous proposal for records with directional subtypes.
http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/BlockInterfaces

The directional subtypes are more flexible but more verbose than this proposal.

BTW An alternative word to "conjugated" is "mirrored".

Peter Flake

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of John.Aasen@kongsberg.com
Sent: 20 February 2015 09:41
To: vhdl-200x@eda.org
Subject: RE: AW: [vhdl-200x] Interfaces with normal, conjugated and monitor flavours

> > > Let's propose:
> > >        bus : interface i_cpu_bus'conjugated; or
> > >        bus : i_cpu_bus'conjugated; (I am not a native English 
> > >speaker, but there might be a better
> > >  word than conjugated.  Maybe reverse ?)
> >
> > The attribute syntax looks cleaner.
> > If you spare the interface keyword, can it conflict with the default 
> > direction of ports?
>
> Not really.  We know that i_cpu_bus is an interface, so having the 
> interface keyword before is simply redundant.
>
>
> > Using 'reverse (or 'reverse_interface) is like using 'reverse_range 
> > on arrays.
>
> What about 'opposite_mode / 'in_mode ?
>
Using attributes is a good idea. This also makes it clear that the monitor and conjugated interfaces are automatically generated by the language and avoids adding new reserved words.
I do not like using 'reverse since 'reverse is used for arrays and ranges. It is confusing using the same term for port directions.
I like conjugated, but then I am used to that term from the Systems Engineering world here it has just the meaning I have proposed here. It has connotations of two items that are related, but opposite.
'opposite_mode and 'in_mode is also a possibility instead of 'conjugated and 'monitor.

>
> > What about using the keyword bus instead of interface?
> > Pros:
> > - it's as short as in/out/inout in a port description
> > - 'reverse_bus looks more like 'reverse_range than 
> > 'reverse_interface
> > Cons:
> > - maybe it's a widely used signal name
>
> No, bus is already a reserved word in VHDL.  No possible conflict and 
> no extra reserved word.
>
> > - interface is better known from OOP
>
> Yes but this feature is not really about OOP, and an interface in 
> Java-like languages is not the same thing.  The advantage of 'interface'
> keyword (argh, the right words are reserved identifier) is similarity 
> with systemverilog.  But I am not sure that this is so important.
>
> > Additional attributes:
> > Shout there be a possibility to extract all in or out signals by 
> > using the attribute syntax? This could help to connect new entities 
> > with interfaces to legacy entities with one record per direction.
>
> Well, you can connect by association or write your interface using two 
> records.  Not sure it is worth an extra feature.
>
> As a language designer, I far more prefer to add features slowly.  It 
> is so easy to get screwed.  But maybe I am too prudent.
I agree with Tristan.

Should we support buffer mode in the interfaces?
I have never used buffer mode in any design. Instead I add a buffer signal in the architecture.
But to be consistent I think it should be supported. The conjugated of buffer is in.

John

________________________________

CONFIDENTIALITY
This e-mail and any attachment contain KONGSBERG information which may be proprietary, confidential or subject to export regulations, and is only meant for the intended recipient(s). Any disclosure, copying, distribution or use is prohibited, if not otherwise explicitly agreed with KONGSBERG. If received in error, please delete it immediately from your system and notify the sender properly.

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





-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sat Feb 21 11:08:16 2015

This archive was generated by hypermail 2.1.8 : Sat Feb 21 2015 - 11:08:38 PST