Re: [vhdl-200x] Directional records proposal

From: Daniel Kho <daniel.kho@gmail.com>
Date: Thu Aug 16 2012 - 19:37:56 PDT

Hi Jim,
Great.

Apart from simulation, yes, you're right about my intention to use this for
synthesis. Some FPGA synthesis tools have a reputation of not supporting
resolution functions very well, even for standardised types.
You are right about the intention of getting the tool to convert tristates
to muxes (or better, get the tool to interpret resolution functions
directly as muxes).

regards, daniel

On 17 August 2012 03:49, Jim Lewis <Jim@synthworks.com> wrote:

> Hi Daniel,
> The proposal does not restrict the usage of resolution functions.
> Records allow elements to be resolved, so so does the proposal.
>
> Generally in RTL design a resolution function implies a tristate.
> Are you using a chip that supports internal tristates or a tool that
> converts from tristates to multiplexors (and supports custom
> resolution functions)?
>
> Best,
> Jim
>
>
>
> 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 <mailto:
>> ryan.w.hinton@l-3com.**com <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<owner-vhdl-200x@eda.org>>
>> [mailto:owner-vhdl-200x@eda.**org <owner-vhdl-200x@eda.org> <mailto:
>> owner-vhdl-200x@eda.**org <owner-vhdl-200x@eda.org>>] *On Behalf Of
>> *Daniel Kho
>> *Sent:* Thursday, July 19, 2012 10:04 PM
>>
>>
>> *To:* vhdl-200x@eda.org <mailto: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<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 <mailto:
>> ryan.w.hinton@l-3com.**com <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<owner-vhdl-200x@eda.org>>
>> [mailto:owner-vhdl-200x@eda.**org <owner-vhdl-200x@eda.org> <mailto:
>> owner-vhdl-200x@eda.**org <owner-vhdl-200x@eda.org>>] *On Behalf Of
>> *Daniel Kho
>> *Sent:* Thursday, July 19, 2012 1:28 PM____
>>
>>
>> *To:* vhdl-200x@eda.org <mailto: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 <mailto:
>> ryan.w.hinton@l-3com.**com <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<owner-vhdl-200x@eda.org>>
>> [mailto:owner-vhdl-200x@eda.**org <owner-vhdl-200x@eda.org> <mailto:
>> owner-vhdl-200x@eda.**org <owner-vhdl-200x@eda.org>>] *On Behalf Of
>> *Brent Hayhoe
>> *Sent:* Tuesday, July 17, 2012 3:38 PM
>> *To:* vhdl-200x@eda.org <mailto: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 <mailto:Brent.Hayhoe@Aftonroy.**com<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* <http://www.mailscanner.info/>**, and
>> is
>> believed to be clean.
>>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~**~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~**~
> Jim Lewis
> Director of Training mailto:Jim@SynthWorks.com
> SynthWorks Design Inc. http://www.SynthWorks.com
> 1-503-590-4787
>
> Expert VHDL Training for Hardware Design and Verification
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~**~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~**~
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Aug 16 19:38:50 2012

This archive was generated by hypermail 2.1.8 : Thu Aug 16 2012 - 19:39:22 PDT