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> <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****
>
> 135 Lancaster Road,****
>
> New Barnet, Mobile: +44 (0)79-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 Thu Jul 19 21:04:15 2012