errata/198: Re: errata/198: 12.3.9.2: sinks should allow only constant part-selects

From: Shalom.Bresticker@motorola.com
Date: Fri Nov 14 2003 - 02:30:00 PST

  • Next message: Michael McNamara: "Proposed Errata document for debate and acceptance"

    The following reply was made to PR errata/198; it has been noted by GNATS.

    From: Shalom.Bresticker@motorola.com
    To: Steven Sharp <sharp@cadence.com>
    Cc: etf-bugs@boyd.com
    Subject: Re: errata/198: 12.3.9.2: sinks should allow only constant part-selects
    Date: Fri, 14 Nov 2003 12:33:51 +0200 (IST)

    > If I understand you correctly, you are talking about the syntax where the
    > user declares
    >
    > module foo (.bar(fubar[0]));
    > input fubar; // or is that input fubar[0];
     
     Yes, that's what I meant.
     More specifically, let's assume that fubar is a vector.
     Then we can write
     
     module foo (.bar(fubar[0]));
     input [3:0] fubar ;
     
     or
     
     module foo (fubar[0]);
     input [3:0] fubar ;
     
     That is, in the port_declaration (input, output, or inout),
     you declare the net or variable completely with its entire range if it is a
     vector. Remember that you cannot write a port and net declarations with
     different ranges, like
     
     input [3:0] fubar ;
     wire [7:0] fubar ;
     
     Even though you declare the entire net in the port declaration, it may be
     that only part of it is connected externally.
     
     This also means you cannot declare part of a net vector with one direction
     and another part with a different port direction.
     
     Extending that idea, if fubar were a net array, and I wanted to declare it
     as a port, I would have to write it as
     
     input [3:0] fubar [7:0] [7:0] ;
     
     but that is not legal today. Today fubar can only be a scalar or a vector,
     not an array. Remember that I cannot today pass an array as a single port,
     like
     
     module foo (fubar);
     input [3:0] fubar [7:0] [7:0] ;
     
     In principle, there is no obstacle though to writing something like
     
     module foo (foobar[0][0]) ;
     input [3:0] fubar [7:0] [7:0] ;
     
     such that the port is still only a single vector or scalar. However, as I said,
     I would still not be able to write
     
     module foo (fubar);
     
     That is, until we decide to allow arrays as ports and define how to do it.
     
     
    > Except that here, you want to connect the port that is bar externally to
    > one element of fubar internally, and there is no way to declare one element
    > of an array as a port.
    >
    > The basic flaw was introduced way back when it was decided that the internal
    > name would be declared as the port, instead of the external name. If it had
    > been defined so that you declared the port direction for bar, this wouldn't
    > be an issue. You could connect any port expression you wanted on the inside,
    > just like on the outside. There also wouldn't be mixed-direction ports. It
    > is possible that there was a good reason for making it the way it is, but
    > I haven't thought about it much.
     
     One possible reason for doing it that way is that it prevents duplicate and
     contradictory declarations.
     
     
    > At any rate, you are right and there is no good way to declare this. On
    > the other hand, this style of port declaration is very rare. Most users
    > don't even know that it exists.
     
     I remember how surprised I was to learn about it.
     And not all tools support it either.
     
     
    > It isn't possible with ANSI-C style port declarations. That implies an
    > acceptance that it won't necessarily be supported for new extensions.
    > Arrays of nets are a new extension.
    >
    > It also doesn't appear to be essential functionality. Connecting an element
    > of an array to a port of an instance is important, since instantiation can
    > be done with a generate-for, and there needs to be an algorithmic way of
    > connecting each one up. But there is no algorithmic way to specify a module
    > port list with some kind of loop. Each port must be explicitly listed. So
    > there is minimal value to being able to connect the ports to array elements.
     
     I don't agree, but I won't argue about it now.
     
      
    > As a result, I would suggest not trying to extend module declarations to
    > handle this.
     
     Unfortunately, this breaks the symmetry between external and internal port
     sinks, and being internal port sinks and continuous assignments. It means
     that internal port sinks (port_references) will be more restricted than
     net_lvalues. And that is how I got into this issue.
     
     If that is the sense of the ETF, then I will continue in that direction.
     
     --
     Shalom Bresticker Shalom.Bresticker@motorola.com
     Design & Reuse Methodology Tel: +972 9 9522268
     Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
     POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
     
     

    This archive was generated by hypermail 2.1.4 : Fri Nov 14 2003 - 02:30:04 PST and
    sponsored by Boyd Technology, Inc.