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

Correction:
Would it be better to place the port(...) preceding the type/subtype, so it
is consistent with how __modes__ are currently being defined?

Since the purpose of having that port(.) in the first place is to define
the modes.

-daniel

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

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