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

From: Daniel Kho <daniel.kho@gmail.com>
Date: Thu Aug 23 2012 - 06:38:01 PDT

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.
Received on Thu Aug 23 06:38:59 2012

This archive was generated by hypermail 2.1.8 : Thu Aug 23 2012 - 06:39:30 PDT