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

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<mailto:Martin.J.Thompson@trw.com>> wrote:
>>> On 22 August 2012 at 20:11, Brent Hayhoe <Brent.Hayhoe@Aftonroy.com<mailto: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<tel:%2B44%20%280%29121-627-3569> : martin.j.thompson@trw.com<mailto: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, and is
believed to be clean.