| Number | 71
|
| Category | errata
|
| Synopsis | 26.6.26: Indexed part-selects (+: and -:) do not have
|
| State | lrmdraft
|
| Class | errata-ptf
|
| Arrival-Date | Jul 07 2002
|
| Originator | Dennis Marsa (drm@xilinx.com)
|
| Release | 2001b: 26.6.26
|
| Environment |
|
| Description |
Indexed part-selects (+: and -:) do not seem to have a representation in VPI. Is the vpiConstantSelect property of vpiPartSelect objects relevant? That is, vpiConstantSelect == false ==> indexed part-select vpiConstantSelect == true ==> regular part-select But, how does one distinguish +: from -:? ============================================================ Steven Sharp wrote: |
| Fix |
Modify the section 26.6.26 as per the diagram http://www.verilog-2001.com/pli_errata/ See vpi_expressions1.pdf Also add the following to annex G: 1) Immediately after the define for vpiNamedEventArray (line 177): #define vpiIndexedPartSelect 130 /* Indexed part-select object */ 2) Immediately after the define for vpiTaskFunc (line 239): #define vpiBaseExpr 131 /* Indexed Part Select's base expression */ #define vpiWidthExpr 132 /* Indexed Part Select's width expression */ 3) Immediately after the define for vpiModPathHasIfNone (line 482): #define vpiIndexedPartSelectType 72 /* Index part-select type */ #define vpiPosIndexed 1 /* +: */ #define vpiNegIndexed 2 /* -: */ |
| Audit-Trail |
From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: ptf-bugs@boyd.com Cc: Subject: Re: errata/71: PROPOSAL - 26.6.26: Indexed part-selects (+: and -:) do not have Date: Tue, 17 Jun 2003 16:29:53 +0300 I am not very familiar with the conventions of section 26.6, but shouldn't 26.6.26 contain an explanation of the meaning of vpiIndexedPartSelectType ? Shalom > Modify the section 26.6.26 as per the diagram > http://www.verilog-2001.com/pli_errata/ > See vpi_expressions1.pdf > > Also add the following to annex G: > > 1) Immediately after the define for vpiNamedEventArray (line 177): > > #define vpiIndexedPartSelect 130 /* Indexed part-select object */ > > 2) Immediately after the define for vpiTaskFunc (line 239): > > #define vpiBaseExpr 131 /* Indexed Part Select's base expression */ > #define vpiWidthExpr 132 /* Indexed Part Select's width expression */ > > 3) Immediately after the define for vpiModPathHasIfNone (line 482): > > #define vpiIndexedPartSelectType 72 /* Index part-select type */ > #define vpiPosIndexed 1 /* +: */ > #define vpiNegIndexed 2 /* -: */ > > http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&pr=71 From: Shalom.Bresticker@motorola.com To: ptf-bugs@boyd.com Cc: 1364@accellera.org Subject: Re: errata/71: PROPOSAL - 26.6.26: Indexed part-selects (+: and -:) do not have VPI representation Date: Wed, 26 Nov 2003 16:18:50 +0200 (IST) With respect to the diagram, the arrow from "operation" to "expr" and tagged "vpiOperand" has a multiple tip in the original (-->>), but only a single tip in the proposal (-->). This looks like a typo? Similarly, "expr" in the original are italicized, but non-italicized in the proposal. What is correct? Thanks, Shalom On Mon, 16 Jun 2003 etf@boyd.com wrote: > Modify the section 26.6.26 as per the diagram > http://www.verilog-2001.com/pli_errata/ > See vpi_expressions1.pdf > > http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&pr=71 -- 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 |
| Unformatted |
a representation in VPI From: Shalom.Bresticker@motorola.com Reply-To: Shalom.Bresticker@motorola.com X-Send-Pr-Version: gnatsweb-2.5 (1.2) X-GNATS-Notify: a representation in VPI >Is the vpiConstantSelect property of vpiPartSelect objects >relevant? That is, > > vpiConstantSelect == false ==> indexed part-select > vpiConstantSelect == true ==> regular part-select Apparently this is the case. >But, how does one distinguish +: from -:? Well, it shouldn't have mattered the way I thought it was supposed to work, but somebody added extra flexibility that causes problems. I thought that the base expression was always supposed to be the left index, since it appears at the left position. Then the direction would be determined by the direction of the declaration, and the choice of +: or -: would have to be consistent with that. However, it looks like the spec allows the base to be either the left or right index, based on the direction of the select versus the direction of the declaration. So now you can't tell what is going on from VPI unless you can determine the direction of the select. So we need to either eliminate this extra flexibility (which isn't really needed), or add another attribute to part selects in VPI. ============================================================ Dennis Marsa wrote: > >Is the vpiConstantSelect property of vpiPartSelect objects > >relevant? That is, > > > > vpiConstantSelect == false ==> indexed part-select > > vpiConstantSelect == true ==> regular part-select > > Apparently this is the case. Actually, this doesn't seem sufficient when the base expression is actually constant, i.e. reg [31:0] vector; vector[31-:8] // both base and width are constant, thus vpiConstantSelect == true, // but this is not a regular part-select > >But, how does one distinguish +: from -:? > > Well, it shouldn't have mattered the way I thought it was supposed to work, > but somebody added extra flexibility that causes problems. I thought > that the base expression was always supposed to be the left index, since > it appears at the left position. Then the direction would be determined > by the direction of the declaration, and the choice of +: or -: would have > to be consistent with that. That makes sense to me. > However, it looks like the spec allows the > base to be either the left or right index, based on the direction of the > select versus the direction of the declaration. So now you can't tell what > is going on from VPI unless you can determine the direction of the select. > > So we need to either eliminate this extra flexibility (which isn't really > needed), or add another attribute to part selects in VPI. Given the counterexample above, it would seem a new property (properties??) of part selects is needed at the very least to determine whether a part select is an index part select, and which type of indexed part-select. Or, alternatively, entirely new VPI objects to represent +: and -: could be defined. ============================================================ Michael McNamara (mac@verisity.com) wrote: I suggest that we add an errata that 'corrects' the specification of vpiConstantSelect to be an integer, and the possible values of vpiConstantSelect to be from the set: { VPI_POSITIVE_INDEXED_PARTSELECT, VPI_NEGATIVE_INDEXED_PARTSELECT, VPI_CONSTANT_PARTSELECT }; ============================================================ Steven Sharp (sharp@cadence.com) wrote: >Actually, this doesn't seem sufficient when the base expression >is actually constant, i.e. > > reg [31:0] vector; > > vector[31-:8] // both base and width are constant, thus vpiConstantSelect == true, > // but this is not a regular part-select I think it is time to let Charles answer this, instead of me trying to recall what he said. Either vpiConstantSelect was supposed to be false in this case (making it a poor choice of names for the property), or VPI was supposed to convert the constant case into an equivalent non-indexed part select and return the range values for that, or something else that I didn't understand at the time. >Given the counterexample above, it would seem a new property (properties??) >of part selects is needed at the very least to determine whether a part select >is an index part select, and which type of indexed part-select. > >Or, alternatively, entirely new VPI objects to represent +: and -: could be >defined. This may have been another situation where the extension was changed after the PLI task force had dealt with it, and they didn't compensate for the change. The original proposal didn't have two variations (though it had other more serious problems). |
Hosted by Boyd Technology