Add Proposal | Add Analysis | Edit Class, Environment, or Release |
Number | 318
|
Category | errata
|
Synopsis | Table 30, 9.3.2, procedural assign to nonconstant part select and force of nonconstant bit-select
|
State | open
|
Class | errata-simple
|
Arrival-Date | Apr 01 2003
|
Originator | "Brad Pierce" <Brad.Pierce@synopsys.com>
|
Release | 2001b: 9.3.2
|
Environment |
|
Description |
In Table 30, why can the left-hand side of a procedural assignment use a nonconstant bit-select or a nonconstant indexed part-select, but only a constant part-select? In 9.3.2 why can the left-hand side of a force be a nonconstant part-select, but only a constant bit-select? -- Brad |
Fix |
|
Audit-Trail |
From: Dennis Marsa <drm@xilinx.com> To: Brad Pierce <Brad.Pierce@synopsys.com> Cc: etf-bugs@boyd.com Subject: Re: errata/318: Table 30, 9.3.2,procedural assign to nonconstant part select and force of nonconstantbit-select Date: Tue, 01 Apr 2003 13:07:26 -0700 Brad Pierce wrote: > > Precedence: bulk > > >Number: 318 > >Category: errata > >Originator: "Brad Pierce" <Brad.Pierce@synopsys.com> > >Environment: > >Description: > > In Table 30, why can the left-hand side of a procedural > assignment use a nonconstant bit-select or a nonconstant > indexed part-select, but only a constant part-select? > > In 9.3.2 why can the left-hand side of a force be a nonconstant > part-select, but only a constant bit-select? > > -- Brad A part-select is by definition constant. That is, the msb and lsb expressions are required to be constant expressions in all contexts. See BNF rule range_expression in A.8.3. In Table 30, where the term "constant part-select" is used, the "constant" is redundant. In 9.3.2, where just the term "part-select" is used, the fact that it is constant is implicit in the definition of a part-select. Note the word "nonconstant" is not used in 9.3.2. For bit-selects and indexed part-selects, it makes sense to distinguish between constant and non-constant forms. But not for part-selects, they are always constant. Dennis From: Shalom.Bresticker@motorola.com To: Brad Pierce <Brad.Pierce@synopsys.com> Cc: etf-bugs@boyd.com Subject: Re: errata/318: Table 30, 9.3.2, procedural assign to nonconstant part select and force of nonconstant bit-select Date: Wed, 2 Apr 2003 11:04:06 +0300 (IDT) > In Table 30, why can the left-hand side of a procedural > assignment use a nonconstant bit-select or a nonconstant > indexed part-select, but only a constant part-select? > > In 9.3.2 why can the left-hand side of a force be a nonconstant > part-select, but only a constant bit-select? Dennis has the right idea, but I don't completely agree. 4.2.1, para. 2, says, "There are two types of part-selects, a constant part-select and an indexed part-select." A "constant part-select" has the form vect[msb:lsb]. An "indexed part-select" has the form vect[base +: width] or vect[base -: width]. "width" is always constant. "base" may be constant or not. If "base" is constant, then it is a "constant indexed part-select". So Table 30 is precise: The LHS of a procedural assignment may be a "constant part-select". It may also be an "indexed part-select", constant or not. On the other hand, the LHS of a continuous assignment may be a "constant part-select" or a "constant indexed part-select". Re 9.3.2 and "force": There the term "part-select" remains from 1364-1995, where there was only one type of part-select. Presumably it should be like the LHS of a continuous assignment (both are "net_lvalue"). So probably "part_select of a vector net" should be changed to "constant part-select or constant indexed part-select of a vector net". Also, in accordance with a previous issue, I think #75, "concatenation" should maybe be "concatenation or nested concatenation". And the same changes should probably be made in 12.3.2 in the list following para. 1, where it says, "The port reference ... can be ...". Also see related issue #198. |
Unformatted |
|
Hosted by Boyd Technology