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

One more comment, will having a "port" to indicate direction inside the
entity declaration cause any complication to the parser?

entity slave is port(
    clk: in std_ulogic;
    bus : t_slave0 port(adr, dat, we, en(array <>) : in; sdt, ack, err :
out ; en(others) : open; others : open );
);

Here, you have a port within a port.

Would it be better to place the port(...) preceding the type/subtype, so it
is consistent with how ports are currently being defined?
    -- entity port with directional subtype.
    bus : port(adr, dat, we, en(array <>) : in; sdt, ack, err : out ;
en(others) : open; others : open ) t_slave0;

    -- resolved directional subtype
    subtype t_slave3 is resolve port(adr, dat, we, en(array <>) : in; sdt,
ack, err : out ; en(others) : open; others : open ) t_cpu_bus;

regards, daniel

On 23 August 2012 21:38, Daniel Kho <daniel.kho@gmail.com> wrote:

> 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, and is
believed to be clean.