Daniel:
You're right. My intention is to indicate that the result of the
existing function should be available after some number of clock cycles.
This fits well with some vendors' pipelining and retiming option. And I
often want to just delay a signal -- no processing at all. I agree this
doesn't allow for customized pipeline design. I do pipelined
subprograms with procedures: each call to the procedure indicates a new
clock cycle (i.e. it wouldn't work correctly in a concurrent context).
Then I can pipeline it exactly the way I want.
I also agree it has nothing to do with directional records.
Enjoy!
- Ryan
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Daniel Kho
Sent: Thursday, July 19, 2012 10:04 PM
To: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] Directional records proposal
Ryan,
Check out Syntax 3 of the "clocked shorthand" proposal.
http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ClockedShorthand
Say we need a pipelined divider in our design. We can use the "/"
function together with the "after 2 * rising_edge(clk)" clause.
One thing that wasn't clear to me was whether or not we need to change
anything in the way functions are currently being defined. Or perhaps no
change is needed at all, and the above syntax should suffice?
If no change is needed (i.e. we can use existing functions and clock
them with the above syntax - this means the compiler does all that
thinking), then we can't apply the concept of directional records here.
If the user takes away (or overrides) some of the compiler's thinking
process (i.e. we are allowed the flexibility to define our own clocked
functions, say an overloaded "/" with a clock input), then we _could_
possibly apply this concept here. In this case, I'm talking about
creating your own custom divider as a clocked function, and you have
more control over the architecture of the divider and pipelines.
Using Syntax 3 is a handy way to insert pipelines, but you don't have
much control over the architecture of the divider (or any other
function).
regards, daniel
On 20 July 2012 04:26, <ryan.w.hinton@l-3com.com> wrote:
Daniel:
The extension to directional parameter lists seems pretty
straightforward, and I see the same convenience there. In fact,
assuming we define custom port modes, I hope we can use the same "port
modes" for procedures as we do for entities.
I'm not sure I understand your "clocked functions" use case. Can you
elaborate?
- Ryan
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Daniel Kho
Sent: Thursday, July 19, 2012 1:28 PM
To: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] Directional records proposal
Ryan,
I'm fine with Andy's original proposal (or any simple variant). I agree
that implementing different alternatives that do the same thing would
increase the cost of implementation (especially tool vendors).
There are a couple other scenarios where I'd like to use directional
records: with procedures, and possibly also clocked functions (as was
proposed previously for pipelining).
regards, daniel
On 20 July 2012 02:23, <ryan.w.hinton@l-3com.com> wrote:
Brent:
This seems a complicated way to do something simple. By breaking the
signals out of the record, no new syntax is required. But I think the
point of your suggestion is to allow keeping all the signals in one
record.
We discussed this in the telecon this morning. For this particular use
case (system bus), consider the WISHBONE approach. They define signals
for a MASTER interface and signals for a SLAVE interface. Then any
complexity like multiple masters, multiple slaves, arbitration, etc.
they encapsulate in the INTERCON block. If used appropriately, this
encourages reuse: any master can connect to a compatible WISHBONE bus,
and any slave can connect to a compatible WISHBONE bus. They don't need
to worry about all the possible bus topology permutations.
In short, I'm asking for a more compelling use case. Directional
records, to me, are a convenient, "icing on the cake" type of language
feature. It makes sense to group related items in one record regardless
of whether they're inputs or outputs. It's a benefit, but not a huge
benefit. But the proposals have required increasingly heavy and
invasive language changes. I am inclined to vote against a feature with
a moderate benefit that requires significant changes to the language.
It's a cost-benefit thing.
So again, can someone provide a better use case (i.e. increase the
benefit)? If not, I want to decrease the cost by only implementing
something like Andy's original proposal.
Thanks!
- Ryan
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Brent Hayhoe
Sent: Tuesday, July 17, 2012 3:38 PM
To: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] Directional records proposal
Hi Guys,
I'd forgotten just how important having an 'unconnected' port mode is
until I
read Peter's post:
>
> From: Peter Flake <flake@elda.demon.co.uk>
<mailto:flake@elda.demon.co.uk>
> Date: Mon Jul 16 2012 - 03:59:03 PDT
>
> Hi Daniel,
>
> A bus master may have several slaves, each with a control signal back
to the
> master. To represent the bus with a single record, there must be an
array
> of control signals which are all connected to the master but not all
are
> connected to each slave. This has already been discussed earlier in
the
> thread.
>
> Brent Hayhoe's recent suggestion tackles this problem.
>
>
> Regards,
>
> Peter
>
So, let's re-define the record in a recursive manner:
type master_r is
record
adr_vl : std_logic_vector(15 downto 0); -- Address
dat_vl : std_logic_vector(15 downto 0); -- Data from master to
slave
we_l : std_logic; -- Write enable from
master
en_l : std_logic; -- Enable from master
end record master_r;
type slave_r is
record
sdt_vl : std_logic_vector(15 downto 0); -- Data from slave to
master
ack_l : std_logic; -- Acknowledge from
slave
err_l : std_logic; -- Error from slave
end record slave_r;
and we need a means of generically defining slave ports, so lets
have an array for 2 slaves:
subtype slave_jrt is natural range 2 downto 1;
type slave_at is array(slave_jrt) of slave_r;
to give us our overall record type of:
type cpu_bus_r is
record
master_rl : master_r; -- bus from master
slave_al : slave_at; -- buses from slaves
end record cpu_bus_r;
which now leads to a more compact entity declaration:
entity master is
port (
clk_i : in std_logic;
bus_rio : record (
master_rl : out master_r;
slave_al : in slave_at
) cpu_bus_r;
rst_i : in std_logic
);
end entity master;
and generically for the slaves:
entity slave is
generic (
inst_jg : slave_jrt
);
port (
clk_i : in std_logic;
bus_rio : record (
master_rl : in master_r;
slave_al : array (
inst_jg : out slave_r;
others : unconn slave_r
) slave_at;
) cpu_bus_r;
rst_i : in std_logic
);
end entity slave;
We have to have a new array element port mode assignment similar to the
record type's mode structure. This gives us the ability to generically
assign
the slave port. I think the compiler should know enough about the array
type's
structure to be able to build a template for instantiation at this
point.
which then leads to instantiations as shown:
signal clk_s : std_logic;
signal cpu_bus_rs : cpu_bus_r;
signal rst_s : std_logic;
master_inst : master
port map (
clk_i => clk_s,
bus_rio => cpu_bus_rs,
rst_i => rst_s
);
slave_inst1 : slave
generic map (
inst_jg => 1
)
port map (
clk_i => clk_s,
bus_rio => cpu_bus_rs,
rst_i => rst_s
);
slave_inst2 : slave
generic map (
inst_jg => 2
)
port map (
clk_i => clk_s,
bus_rio => cpu_bus_rs,
rst_i => rst_s
);
and this now looks quite compact and tidy.
Internally the slave's architecture would have to replicate the drive to
all
ports of the slave array I think.
Thoughts?
--
Regards,
Brent Hayhoe.
Aftonroy Limited Telephone: +44
(0)20-8449-1852 <tel:%2B44%20%280%2920-8449-1852>
135 Lancaster Road,
New Barnet, Mobile: +44
(0)79-6647-2574 <tel:%2B44%20%280%2979-6647-2574>
Herts., EN4 8AJ, U.K. Email:
Brent.Hayhoe@Aftonroy.com
Registered Number: 1744190 England.
Registered Office:
4th Floor, Imperial House,
15 Kingsway,
London, WC2B 6UN, U.K.
Received on Mon Jul 23 15:12:43 2012
This archive was generated by hypermail 2.1.8 : Mon Jul 23 2012 - 15:12:52 PDT