Re: EXTERNAL: Re: [vhdl-200x] Records with diectional subtypes

Andy,
< When a port is declared with an explicit mode and a directional subtype,
the explicit mode wins. />

Okay, this means all of the elements of the directional subtype will be
overridden to the explicit mode? This sounds a little error prone to me.
It would usually be a mistake created from the user to explicitly define a
mode and also use it with directional subtypes. I suggest such use be
illegal.

Anyway, it's the parsing of
    entity slave is port(
        bus : differentResolve t_slave0 port(...)
    );
    end entity slave;

that I was concerned with.

I agree that if it we use normal (non-directional) subtypes without
explicitly writing the mode, then the mode should default to "in" for all
elements of the subtype, like in the following case:
    entity slave is port(
        bus : differentResolve t_slave0
    );
    end entity slave;

Here, all of the elements of bus should default to the IN mode. But if we
were to declare "bus" to have a mode and also a directional subtype, then
the expression is ambiguous and should be disallowed IMHO.

    entity slave is port(
        bus0 : buffer differentResolve t_slave0; -- legal,
all bus0 elements uses buffer mode. If mode not specified, defaults to IN.
        bus1 : t_slave2_resolved; -- legal,
defaults to IN.
        bus2 : buffer differentResolve t_slave0 port(...) -- illegal,
directional subtypes cannot be used with modes.
    );
    end entity slave;

-daniel

On 23 August 2012 22:16, Jones, Andy D <andy.d.jones@lmco.com> wrote:

> Daniel,****
>
> ** **
>
> In your second example:****
>
> ** **
>
> -- Subtypes capturing direction information
> port (
> portName : SubTypeName ;
> />
>
> ****
>
> ** **
>
> This is no different from an un-specified, default mode (current language
> defaults to IN). By defining a directional subtype, we are simply defining
> the default mode to be used for a port of that subtype, in the absence of
> an explicit mode specification. ****
>
> ** **
>
> Therefore, compliant parsers have to deal with an unspecified mode
> already! So the parsing is already in place, just the process of
> determining the default mode is changing. ****
>
> ** **
>
> When a port is declared with an explicit mode and a directional subtype,
> the explicit mode wins.****
>
> ** **
>
> I’m not sure what the subtype syntax would look like, but we could use
> this mechanism to override the default mode for any kind of data type
> (scalar or composite). ****
>
> ** **
>
> *Andy D Jones
> *Electrical Engineering****
>
> Lockheed Martin Missiles and Fire Control
> Dallas TX****
>
> ** **
>
> ** **
>
> *From:* owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On
> Behalf Of *Daniel Kho
> *Sent:* Thursday, August 23, 2012 8:38 AM
>
> *To:* vhdl-200x@eda.org
> *Subject:* EXTERNAL: Re: [vhdl-200x] Records with diectional subtypes****
>
> ** **
>
> Martin,
> I agree with you on this one. Having a reusable data structure for
> directional ports that we can store in a package and use for multiple
> entities seem to be an appealing concept.
>
> <
> I don't necessarily agree or disagree. One thing Peter is
> concerned about is the parsing of:
> -- Named Modes
> port (
> portName : ModeName TypeName ;
>
> vs.
> -- Subtypes capturing direction information
> port (
> portName : SubTypeName ;
> />
>
> Yes. This could get a bit tricky for the compiler. More so if we have
> inline resolution functions:
> portName: rsltnFunc SubTypeName ;
>
> How do we distinguish between resolved subtypes and non-resolved
> directional subtypes? And how do we write resolved directional subtypes?
> And can we declare a non-resolved directional subtype, but make it
> resolved in the entity declaration?
>
> How about the following:
>
> -- non-resolved subtype
> subtype t_slave0 is t_cpu_bus;
>
> -- non-resolved directional subtype
> subtype t_slave1 is t_cpu_bus port(adr, dat, we, en(array <>) : in; sdt,
> ack, err : out ; en(others) : open; others : open );
>
> -- resolved subtype
> subtype t_slave2 is resolve t_cpu_bus;
>
> -- resolved directional subtype
> subtype t_slave3 is resolve t_cpu_bus port(adr, dat, we, en(array <>) :
> in; sdt, ack, err : out ; en(others) : open; others : open );
>
> And for the entity declaration:
> --Slave entity
> entity slave is
> port (
> clk : in std_logic;
> bus0 : inout t_slave0; -- non-resolved
> bus1 : t_slave1; -- non-resolved directional
> bus2 : inout t_slave2; -- resolved
> bus3 : t_slave3; -- resolved directional
> bus4 : resolve t_slave1; -- resolved directional
> );
>
> What happens if someone wrote any of the following:
> bus : inout t_slave1; -- perhaps this is already illegal
> bus : differentResolve t_slave2; -- this should be illegal
>
> bus : t_slave0 port(adr, dat, we, en(array <>) : in; sdt, ack, err :
> out ; en(others) : open; others : open );
> ** bus : differentResolve t_slave0 port(adr, dat, we, en(array <>) :
> in; sdt, ack, err : out ; en(others) : open; others : open );
>
> For the last scenario (marked **), will this create a problem to the
> parser in prioritizing which to parse first (functions or types/subtypes)?
>
> Of course, that port(...) definition is still in discussion, but I've just
> written it down so to pose those questions.
>
>
> Anyway, a little more on the sidelines. Since we would want to be able to
> use the same directional subtypes for subprograms as well, I guess we have
> to be concerned about some of the restrictions in the current language with
> respect to modes used for subprograms. Is this proposal restricting itself
> to IN, OUT, and INOUT as well? Other than the OPEN suggestion, would it
> support BUFFER too?
>
> Are there any implications if we relax the restriction of having only IN,
> OUT, and INOUT for subprogram modes? I find Section 4.2.2.1 a bit too
> limiting, as I would like to use the buffer mode for subprogram parameters.
> Here's an example where I would want to be able to readback whatever I've
> written in my procedure.
>
> procedure busWrite(
> signal busOut:buffer busCtrlRecord_out; -- illegal as of
> current language. Forced to use inout, but that's not the behavior I wanted.
> busIn:in busCtrlRecord_in
> ) is begin
> busOut.address<=address;
> busOut.info<=data;
> busOut.trigger<=not busOut.trigger; -- here, we are reading
> back the trigger, so I prefer if request supports the buffer mode instead
> of inout (I'm not going to read from external)
> end procedure busWrite;
>
> Well, my simulator didn't think that I was doing a readback (it did not
> give me an error when I have "out" as the mode for busOut), and it
> simulated just fine.
> However, my synthesis tool told me that I was doing a readback (here, I'm
> trusting my synthesis tool in this case).
> Strangely, my synthesis tool supports "buffer" for busOut though my
> simulator told me it was illegal (here, I'm trusting my simulator).
>
> I know this is a little off-topic; just wondering if anyone has seen this
> problem?
>
> regards, daniel
>
> ****
>
> On 23 August 2012 15:59, Martin.J Thompson <Martin.J.Thompson@trw.com>
> wrote:****
>
> >>> On 22 August 2012 at 20:11, Brent Hayhoe <Brent.Hayhoe@Aftonroy.com>
> wrote:
> > --Slave entity
> > use work.cpu_bus_pkg.all
> > entity slave is****
>
> ....****
>
> > bus : comp ( --hierarchical composite port
> > adr, dat, we, en(id) : in;
> > sdt, ack, err : out;
> > en(others) : null
> > ) t_cpu_bus
> > );****
>
> I then have to repeat that on all my slaves. The subtype idea means that
> the entity doesn't have to know anything about the contents of the "bus" in
> order to have a pin for it (which is as it should be IMHO).
>
> I'm with Ryan on the "extracting a single bit" functionality. Is there a
> real-world use-case where this is useful? As far as I know, Avalon, AXI
> and Wishbone have their masters connected to their slaves through a block
> of interconnect logic which means that only a single 'en' signal makes it
> through to the slave anyway. Are there other on-chip buses extant which
> could make use of this kind of "bus-ripping" feature?
>
> Cheers,
> Martin
>
>
> --
> Martin Thompson CEng MIET
> TRW Conekt, Stratford Road, Solihull, B90 4GW. UK
> +44 (0)121-627-3569 : martin.j.thompson@trw.com
> http://www.conekt.co.uk/
>
> Conekt is a trading division of TRW Limited
> Registered in England, No. 872948
> Registered Office Address: Stratford Road, Solihull B90 4AX****
>
>
> --
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean. ****
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

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