Re: [vhdl-200x] Directional records proposal

Ryan,
Sorry I missed the last telecon. Something popped up at work that needed my
attention.

Peter / Jim,
I was reading the Block Interfaces proposal (Interfaces / Record IO in
Collected Requirements) and saw Peter proposed to use subtypes to define
the modes (Candidate #2: Records with directional subtypes).
subtype t_master is t_cpu_bus port(adr, dat, we, en : out; sdt, ack, err :
in);

I feel this could serve our purpose as well. However, I have a question
relating to Candidate #2:

For the t_cpu_bus record, can we still define custom resolution functions
for some of the elements of the record? This has been mentioned for
Candidate #1 (resolved records) as well, but I'm not sure if you mean to
restrict its usage to only unresolved types and standardised resolved types
(as defined in IEEE packages). Or could we also still use our own
user-defined custom resolution functions?

In a design I'm currently doing, I felt the need to have a few elements of
the record type to use custom resolution functions, so I can drive only
these ports from multiple processes in an architecture:
type t_cpu_bus is record
    cs: resolved boolean; -- chip select (uses custom resolution
function)
    adr : resolved std_ulogic_vector(15 downto 0); --Address (uses custom
resolution function)
    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;

I'm fine with the rest of the proposal, including using directional
subtypes (slightly modified to include CS to illustrate that I need this
port to be resolved between multiple processes):
subtype t_master is t_cpu_bus port(cs, adr, dat, we, en : out; sdt, ack,
err : in);

cs and adr will be driven by two separate statemachines. Both statemachine
signals will drive the ADR bus and CS at different times, depending on
whether WE (write-enable) is asserted or not.

I believe this proposal does not place any restrictions on resolution
functions?

regards, daniel

On 24 July 2012 06:12, <ryan.w.hinton@l-3com.com> wrote:

> 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> <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.****
>
>
>
>

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