Re: enhancement/409: lists in part-selects

From: Shalom.Bresticker@motorola.com
Date: Sun Aug 17 2003 - 07:40:03 PDT

  • Next message: Shalom Bresticker: "Re: [sv-ec] ERR-4"

    Precedence: bulk

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

    From: Shalom.Bresticker@motorola.com
    To: Jay Lawrence <lawrence@cadence.com>
    Cc: etf-bugs@boyd.com
    Subject: Re: enhancement/409: lists in part-selects
    Date: Sun, 17 Aug 2003 17:28:57 +0300 (IDT)

     Coincidentally, I just saw the following on comp.lang.verilog:
     
     =========================================================================
     Subject: syntax question
            Date: Fri, 15 Aug 2003 14:37:20 -0700
            From: Ron Smith <rdNOsmith@sedSPAMona.intel.com>
      Newsgroups: comp.lang.verilog
     
     Why does this work:
     
     wire [1:0] foo,bar;
     
     assign {foo,bar}=4'b1000;
     
     at setting foo to 2'b10 and bar to 2'b00, but this gives a syntax error:
     
     wire [1:0] foo,bar;
     
     assign {foo,bar}=4'b0000;
     assign {foo,bar}[3]=1'b1;
     
     but this also works:
     
     wire [3:0] foobar;
     
     assign foobar=4'b0000;
     assign foobar[3]=1'b1;
     
     Please note that I'm not trying to argue over the finer points of style,
     the above is simply a trivial and overly simplistic example of something
     I tried that I thought "should" work, but of course it didn't.
     
     =========================================================================
     
     Shalom
     
     
     On Sun, 3 Aug 2003, Shalom Bresticker wrote:
     
    > Date: Sun, 03 Aug 2003 12:19:52 +0300
    > From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
    > To: Jay Lawrence <lawrence@cadence.com>
    > Cc: etf-bugs@boyd.com
    > Subject: Re: enhancement/409: lists in part-selects
    >
    > Hi, Jay.
    >
    > That's a very interesting and elegant idea.
    >
    > I actually had to think about how indexing is defined in the Verilog language
    > when I was looking at 3.9.1, bullet 2, which seems to relate to indexing as an
    > operator, since the title of 3.9.1 is "Operators and real numbers".
    >
    > I don't think it was deliberate there, just not very precise wording and
    > organization, but it got me to thinking about it.
    >
    > I understand what you wrote and I think it is worth further work.
    > I am not sure it would simplify the LRM, though.
    >
    > You wrote that "Most other languages treat subscripting as a general
    > operator. " Could you give a couple of references?
    > My first mental association when I read that was the APL language,
    > but I am not familiar with how languages like C and PERL relate to it.
    >
    > I like the idea of being able to write (r1 & r2)[3].
    > One other feature which would be occasionally useful is subscripting of
    > constants.
    >
    > Thanks and regards,
    > Shalom
    >
    >
    > Jay Lawrence wrote:
    >
    > > Shalom,
    > >
    > > I think this is an interesting enhancement that makes currently
    > > expressible things more succinct and clear. As long as the user
    > > community does not confuse succinctness with performance this is OK.
    > >
    > > This enhancement is closely related to another concept we've been
    > > discussing internally here at Cadence related to bit-selects,
    > > part-selects, and data types.
    > >
    > > Bit-selects and part-selects are currently defined as operands, not as
    > > an operator. Most other languages treat subscripting as a general
    > > operator. This allows things like subscripting to participated in
    > > precendence relationships and arbitrary expressions. Once the language
    > > has things like structs you get (for some struct s) expressions like:
    > >
    > > s.x[2]
    > >
    > > Now you need to define structure references as an operand as well or
    > > define precedence of '.' and '[]'.
    > >
    > > One advantage of treating subscripting as an operator would be
    > > simplifying the LRM signficantly. Currently anywhere operands are
    > > discussed there is are special rules about bit-selects and part-selects.
    > > If we just made them operators and defined what objects they were
    > > allowed to operate on all this special purpose text goes away.
    > >
    > > It appears your enhancments request here would fit into this concept
    > > nicely. The [] operator would be defined to be able to contain a list of
    > > either integers or ranges.
    > >
    > > There are some difficult cases like:
    > >
    > > reg [10:0] r1;
    > > reg [20:10] r2;
    > > reg r;
    > >
    > > r = (r1 & r2)[3];
    > >
    > > What is the range of the expression (r1 & r2)? Is [3] a legal subscript
    > > in this range?
    > >
    > > Either by defining such a range, or by disallowing subscripting on
    > > expressions with a self-determined width, but no defined range these
    > > could be handled.
    > >
    > > As someone who has invested a huge amount of time in clarifying the LRM,
    > > I'ld love to hear your opinion on whether this change from operand to
    > > operator would significantly simplify the LRM.
    > >
    > > Jay
    > >
    > > ===================================
    > > Jay Lawrence
    > > Senior Architect
    > > Functional Verification
    > > Cadence Design Systems, Inc.
    > > (978) 262-6294
    > > lawrence@cadence.com
    > > ===================================
    > >
    > > > -----Original Message-----
    > > > From: Shalom.Bresticker@motorola.com
    > > > [mailto:Shalom.Bresticker@motorola.com]
    > > > Sent: Friday, August 01, 2003 3:40 AM
    > > > To: etf-bugs@boyd.com
    > > > Subject: Re: enhancement/409: lists in part-selects
    > > >
    > > >
    > > > Precedence: bulk
    > > >
    > > > The following reply was made to PR enhancement/409; it has
    > > > been noted by GNATS.
    > > >
    > > > From: Shalom.Bresticker@motorola.com
    > > > To: Steven Sharp <sharp@cadence.com>
    > > > Cc: etf-bugs@boyd.com
    > > > Subject: Re: enhancement/409: lists in part-selects
    > > > Date: Fri, 1 Aug 2003 10:30:48 +0300 (IDT)
    > > >
    > > > > I would also like to point out that this is not a
    > > > customer-vendor situation;
    > > > > this is a standardization effort. As an individual
    > > > representative, I feel
    > > > > a responsibility to the long-term quality of the language
    > > > and the interests
    > > > > of the entire industry, not just the short-term goal of
    > > > making a sale.
    > > >
    > > > I am also trying to consider "the interests of the entire
    > > > industry" by looking
    > > > at what designers actually need on a day-to-day basis.
    > > >
    > > > Sometimes people get so caught up in big revolutionary
    > > > changes that they
    > > > forget the little things which make a big difference in how good a
    > > > tool really is.
    > > >
    > > > --
    > > > 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
    > > >
    > > >
    >
    > --
    > 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
    >
    >
     
     --
     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 : Sun Aug 17 2003 - 07:41:40 PDT and
    sponsored by Boyd Technology, Inc.