Daniel:
I don't think this works for several reasons.
* The syntax rule for a port interface item is basically
identifier : [mode] subtype_indication ;
If you make the mode token a value from an enumerated type, you're
limited to a value from the current type. In short, VHDL doesn't allow
you to extend an enumerated type.
* Records and arrays are different in significant ways. It doesn't
work to use an array to describe the modes of record elements. (I can
elaborate if desired.)
I like Andy's syntax better so far. If we want to make it shorter, I
would do something like the following.
port mode m_master of t_cpu_bus is
adr, dat, we, en : out;
sdt, ack, err : in;
end port mode m_master;
I also want a "reversed" syntax similar to Olof's original suggestion,
something like one of the following.
port mode m_slave of t_cpu_bus is reversed m_master;
port mode m_slave of t_cpu_bus : reversed m_master;
I don't think the first syntax will work without adding REVERSED as a
VHDL reserved word. So I don't like it. The second syntax looks more
like an object (constant, variable, signal) declaration -- different
from Andy's type declaration-like syntax. So I don't really like it,
either. :-) But for this very common case it would be silly not include
a shorthand to reverse the directions.
- Ryan
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Daniel Kho
Sent: Thursday, July 12, 2012 11:27 PM
To: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] Directional records proposal
I was thinking that the "port modes" definitions could be further
simplified to contain only a list of modes:
type mode is (in,out,inout); -- not too sure if there is already
an existing definition for this in the standard.
type mode_vector is array (natural range <>) of mode;
signal m_master: mode_vector(0 to 6) := (0 to 3 => out, others => in);
signal m_slave: mode_vector(0 to 6) := (0 to 3 => in, others => out);
signal m_monitor: mode_vector(0 to 6) := (others => in);
where "mode_vector" is the data structure for holding the list of
directions, and the signal definitions are similar to the concept of
"port modes" by Andy.
I'm not sure if the use of "signals" is appropriate here. Perhaps
another keyword (such as "port mode") may be more appropriate. Anyway,
it's good to explore a compact notation such as the one given above.
Modifying the above to use the "port mode" notation, we could have
something like this:
port mode m_master: mode_vector(0 to 6) := (0 to 3 => out, others =>
in);
port mode m_slave: mode_vector(0 to 6) := (0 to 3 => in, others => out);
port mode m_monitor: mode_vector(0 to 6) := (others => in);
The rest of the code remains unchanged from Andy's.
Comments are welcome.
regards, daniel
On 13 July 2012 11:59, Daniel Kho <daniel.kho@gmail.com
<mailto:daniel.kho@gmail.com> > wrote:
Hi Andy,
Yes.
bus : m_master t_cpu_bus
bus : m_slave t_cpu_bus
bus : m_monitor t_cpu_bus
I especially like the fact that you could define your own custom
direction for the ports, using what you call port modes. :)
regards, daniel
On 13 July 2012 10:40, <ryan.w.hinton@l-3com.com
<mailto:ryan.w.hinton@l-3com.com> > wrote:
That's the cleanest, most general solution I've seen for this problem so
far. Naturally, if a record signal element is connected to multiple
user-defined ports with OUT modes for that element, the resolution
function for that (sub)type is invoked. What happens to the role of
resolution functions on the composite type? I'm not too clear on how
these rules work currently, so I'll study up and provide further
analysis later.
Great idea!
- Ryan
-----Original Message-----
From: owner-vhdl-200x@eda.org <mailto:owner-vhdl-200x@eda.org>
[mailto:owner-vhdl-200x@eda.org <mailto:owner-vhdl-200x@eda.org> ] On
Behalf
Of Jones, Andy D
Sent: Thursday, July 12, 2012 8:15 PM
To: vhdl-200x@eda.org <mailto:vhdl-200x@eda.org>
Subject: RE: [vhdl-200x] Directional records proposal
The only change I would recommend, to allow more flexibility than just
forward and reverse mode variants (all-input monitors, etc.), would be
to create user-defined modes for a record type. This keeps the current
record declaration unchanged.
User defined modes could be nested as well. If a record contains an
element that is another record, then the defined modes for the parent
record would specify one of the defined modes for the child record.
The same modes could be used for procedures as well.
For a multi-slave bus, you could either rely upon resolved data types
for the slave-driven record elements, or you could code up a bus switch
with one slave port and N master ports.
Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control Dallas TX
Modifying Olof's example, the syntax for mode declarations is open for
debate. If we used '=>' instead of ':', then you could use "others =>
in", etc.
Example with a simple cpu bus:
==Type definition==
type t_cpu_bus is record
adr : std_logic_vector(15 downto 0); --Address
dat : std_logic_vector(15 downto 0); --Data from master to slave
we : std_logic; --Write enable from master
en : std_logic; --Enable from master
sdt : std_logic_vector(15 downto 0); --Data from slave to master
ack : std_logic; --Acknowledge from slave
err : std_logic; --Error from slave
end record;
==Master Mode definition==
port mode m_master of t_cpu_bus is
adr : out; --Address
dat : out; --Data from master to slave
we : out; --Write enable from master
en : out; --Enable from master
sdt : in ; --Data from slave to master
ack : in ; --Acknowledge from slave
err : in ; --Error from slave
end port mode m_master;
==Slave Mode definition==
port mode m_slave of t_cpu_bus is
adr : in ; --Address
dat : in ; --Data from master to slave
we : in ; --Write enable from master
en : in ; --Enable from master
sdt : out; --Data from slave to master
ack : out; --Acknowledge from slave
err : out; --Error from slave
end port mode m_slave;
==Monitor Mode definition==
port mode m_monitor of t_cpu_bus is
adr : in ; --Address
dat : in ; --Data from master to slave
we : in ; --Write enable from master
en : in ; --Enable from master
sdt : in ; --Data from slave to master
ack : in ; --Acknowledge from slave
err : in ; --Error from slave
end port mode m_monitor;
==Master entity==
entity master is
port (
clk : in std_logic;
bus : m_master t_cpu_bus);
end entity;
==Slave entity==
entity slave is
port (
clk : in std_logic;
bus : m_slave t_cpu_bus);
end entity;
==Monitor entity==
entity monitor is
port (
clk : in std_logic;
bus : m_monitor t_cpu_bus);
end entity;
==Top level==
signal cpu_bus : t_cpu_bus;
i_master : master
port map (
clk => clk,
bus => cpu_bus);
i_slave : slave
port map (
clk => clk,
bus => cpu_bus);
i_monitor : monitor
port map (
clk => clk,
bus => cpu_bus);
-----Original Message-----
From: owner-vhdl-200x@eda.org <mailto:owner-vhdl-200x@eda.org>
[mailto:owner-vhdl-200x@eda.org <mailto:owner-vhdl-200x@eda.org> ] On
Behalf
Of ryan.w.hinton@L-3com.com
Sent: Thursday, July 12, 2012 1:00 PM
To: vhdl-200x@eda.org <mailto:vhdl-200x@eda.org>
Subject: EXTERNAL: RE: [vhdl-200x] Directional records proposal
Olof:
You're on the right track -- this idea has come up before! If you want
more history, you can take a look at the mail and document archives for
the VHDL-200x effort. For a good summary of the current problem
concept, see "Jim's old proposal for interfaces" at
<http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/BlockInterfaces
<http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/BlockInterfaces> >.
Personally, I think this is a great idea. But I haven't come up with
any good resolution to the points you bring up and the other
"implementation details" you allude to (e.g. those in Jim's proposal).
I would be very happy for you to help this proposal progress by digging
into the detailed issues and proposing solutions.
Enjoy!
- Ryan
-----Original Message-----
From: owner-vhdl-200x@eda.org <mailto:owner-vhdl-200x@eda.org>
[mailto:owner-vhdl-200x@eda.org <mailto:owner-vhdl-200x@eda.org> ] On
Behalf
Of Olof Kindgren
Sent: Thursday, July 12, 2012 10:34 AM
To: vhdl-200x@eda.org <mailto:vhdl-200x@eda.org>
Subject: [vhdl-200x] Directional records proposal
Hi,
I recently found this list and the proposed additions to the next VHDL
revision. There seem to be plenty of interesting features, but I'm
missing one feature that irritates me on a daily basis.
VHDL allows us to group signals together with records, but when these
are passed through entity ports, they need to be unidirectional. Many
protocols uses a return-channel - in communication interfaces it can be
some sort of flow-control, and a CPU bus usually has a data/ack/error
combination.
This requires me to separate my logical bus into two records (unless I
use inout ports and resolve functions, which is a bit messy)
My proposal is to add an optional directional statement to records to
allow grouping related bidirectional signals
Example with a simple cpu bus:
==Type definition==
type t_cpu_bus is record
adr : std_logic_vector(15 downto 0); --Address
dat : std_logic_vector(15 downto 0); --Data from master to slave
we : std_logic; --Write enable from master
en : std_logic; --Enable from master
sdt : rev std_logic_vector(15 downto 0); --Data from slave to master
ack : rev std_logic; --Acknowledge from slave
err : rev std_logic; --Error from slave
end record;
==Master entity==
entity master is
port (
clk : in std_logic;
bus : out t_cpu_bus);
end entity;
==Slave entity==
entity slave is
port (
clk : in std_logic;
bus : in t_cpu_bus);
==Top level==
signal cpu_bus : t_cpu_bus;
i_master : master
port map (
clk => clk,
bus => cpu_bus);
i_slave : slave
port map (
clk => clk,
bus => cpu_bus);
Using "rev" for reverse would reverse the direction of the signal
compared to what's defined in the entity port.There should also be a
"bidir" for inout ports.
There are some details that need would need to be worked out for this to
work.
1. This would probably work fine for point-to-point connections, but
what would happen if the bus is connected to more than one in/out pair?
Will the normal resolving rules take care of that?
2. Would it be legal to declare these as inout, or are just in and out
valid?
3. Can assignments only be done on individual members of the struct,
i.e. what would happen with cpu_bus := (x"0000", x"0000", '0', '0',
x"0000", '0', '0')?
I'm sure there are other implementation details that I haven't thought
about. but I'm interested in your opinions
Best Regards,
Olof Kindgren
______________________________________________
ORSoC
Website: www.orsoc.se <http://www.orsoc.se>
Email: olof.kindgren@orsoc.se <mailto:olof.kindgren@orsoc.se>
______________________________________________
FPGA, ASIC, DSP - embedded SoC design
Received on Fri Jul 13 11:58:52 2012
This archive was generated by hypermail 2.1.8 : Fri Jul 13 2012 - 11:59:21 PDT