I apologise for not being clear.
Below is what I meant (modified from Andy's code):
==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;
type mode is (in,out,inout);
type mode_vector is array (natural range <>) of mode;
==Master Mode definition==
port mode m_master: mode_vector(0 to 6) := (0 to 3 => out, others => in);
==Slave Mode definition==
port mode m_slave: mode_vector(0 to 6) := (0 to 3 => in, others => out);
==Monitor Mode definition==
port mode m_monitor: mode_vector(0 to 6) := (others => in);
==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);
regards, daniel
On 13 July 2012 16:55, Daniel Kho <daniel.kho@gmail.com> wrote:
> Hi Olof,
> _Apart from resolution functions, signal/variable assignments is still
>
> a bit of a grey area. Only allowing it on individual record members
> would simplify things a bit, but would that be sufficient?_
>
> I was using the "signal" keyword, though I didn't mean to make any signal
> / variable assignments. So the usage of the signal notation could be
> inappropriate there.
> The intention is to have the same custom mode definitions as Andy's, in a
> more compact form.
>
> regards, daniel
>
>
> On 13 July 2012 15:54, Olof Kindgren <olof.kindgren@orsoc.se> wrote:
>
>> This sparked quite a discussion. Seems like I wasn't the only one with
>> this problem :)
>>
>> I think that Andy's custom modes are a great idea. An added benefit is
>> that this would allow grouping signals that have the same direction on
>> both master and slave ports, such a clock, reset and error signals.
>> It's also a cleaner syntax than introducing a new keyword such as
>> "rev" in my proposal. It would also be more in line with current VHDL
>> syntax compared to something like SV modports
>>
>> The blockInterfaces proposal
>> (http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/BlockInterfaces) was an
>> interesting read. That proposal covers a bit more, such as transaction
>> models, but the things we are outlining here at least doesn't seem to
>> clash with any of the potential requirements in ch 2 of the PDF.
>>
>> Apart from resolution functions, signal/variable assignments is still
>> a bit of a grey area. Only allowing it on individual record members
>> would simplify things a bit, but would that be sufficient?
>>
>> --
>> Olof Kindgren
>> ______________________________________________
>> ORSoC
>> Website: www.orsoc.se
>> Email: olof.kindgren@orsoc.se
>> ______________________________________________
>> FPGA, ASIC, DSP - embedded SoC design
>>
>> 2012/7/13 Daniel Kho <daniel.kho@gmail.com>:
>> > 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> 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> 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] On
>> Behalf
>> >>> Of Jones, Andy D
>> >>> Sent: Thursday, July 12, 2012 8:15 PM
>> >>> To: 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] On
>> Behalf
>> >>> Of ryan.w.hinton@L-3com.com
>> >>> Sent: Thursday, July 12, 2012 1:00 PM
>> >>> To: 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>.
>> >>>
>> >>> 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] On
>> Behalf
>> >>> Of Olof Kindgren
>> >>> Sent: Thursday, July 12, 2012 10:34 AM
>> >>> To: 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
>> >>> Email: olof.kindgren@orsoc.se
>> >>> ______________________________________________
>> >>> FPGA, ASIC, DSP - embedded SoC design
>> >>>
>> >
>>
>
Received on Fri Jul 13 02:12:53 2012
This archive was generated by hypermail 2.1.8 : Fri Jul 13 2012 - 02:13:05 PDT