Re: FW: [sv-bc] RE: [sv-ec] Are variable-width part selects already part of the SV language? (Mantis 2684)

I think 'N' in the requester's example is intended to be variable

    http://www.eda.org/sv-bc/hm/10195.html

-- Brad

On Fri, May 7, 2010 at 10:23 PM, John Michael Williams
<jwill@basicisp.net> wrote:
> Hi Dave.
>
> I'm very dubious about permitting variable part-select as an element in
> a concatenation, because each element in a concatenation should
> have a fixed width declared.
>
> If variable part-selects were constrained to take on a fixed width,
> I think it would be OK in a concatenation.  For example,
>
> for (...)
>  MyArray[j] <= {MyVar1[k:k-2], MyVar2, 2'b00};
>
> I don't see the point of concatenating something like,
>   {MyVar1[j:k], MyVar2, 2'b00}
>
> Does anyone have a real example of a concatenation in which
> a variable-width part-select would be essential?
>
> Why add anything to the language which can be worked-around easily
> by employing preexisting constructs?
>
> On 05/07/2010 02:15 PM, Rich, Dave wrote:
>>
>> John,
>>
>> I believe that most people on the committee seem to converging on
>> enhancement where a variable width part select would be OK in the
>> context of a cast, a concatenation, or streaming operator where the
>> resulting type is determined by the context of an assignment to the
>> destination type. So if you had
>>
>> bit [127:0] A,B;
>> int N;
>>
>> A = {A[127:N],B[N-1:0]}; // would be legal
>> A = {A[127:N],B[N-1:0]} + 1; // should never be legal
>> A =  type(A)'(A[127:N]) + 128'(B[N-1:0]); // would be legal
>>
>>
>> We'll need a few more rules about out-of-range and reverse index
>> ordering, but I'd wait until we get an actual proposal before spending
>> more time on this.
>>
>>
>> Dave
>>
>>> -----Original Message-----
>>> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
>>
>> John
>>>
>>> Michael Williams
>>> Sent: Friday, May 07, 2010 1:47 PM
>>> Cc: sv-bc@eda.org; SV_EC List
>>> Subject: Re: FW: [sv-bc] RE: [sv-ec] Are variable-width part selects
>>> already part of the SV language? (Mantis 2684)
>>>
>>> Hi.
>>>
>>> Maybe stating the obvious, assuming bitwise intent,
>>> an expression such as A[127:N]&   B[N-1:0]
>>> would depend on whether it was in an expression or
>>> part of the right-hand side of a statement.
>>>
>>> If in a statement, it would be evaluated first by
>>> adjusting the widths of the two operands to equal
>>> the width of the destination.
>>>
>>> Keep in mind that the "expressive power" of VHDL is far
>>> less than that of any modern general programming
>>> language such as C, and that SystemVerilog already has
>>> imported much of the "expressive power" of C++.
>>>
>>> Maybe the variable width part-selects might be limited to
>>> expressions within a class?
>>>
>>> Also, consistent with Jonathan's last point, maybe,
>>> sometimes, "expressive power" is another name for
>>> "diversity of gibberish" and "risk of failure"?
>>>
>>> On 05/07/2010 07:11 AM, Bresticker, Shalom wrote:
>>>>
>>>> ________________________________
>>>> From: Jonathan Bromley [mailto:jonathan.bromley@verilab.com]
>>>> Sent: Friday, May 07, 2010 5:10 PM
>>>> To: Bresticker, Shalom
>>>> Subject: Re: [sv-bc] RE: [sv-ec] Are variable-width part selects
>>>
>>> already part of the SV language? (Mantis 2684)
>>>>
>>>> Shalom,
>>>>
>>>> with apologies for sending this directly to you:
>>>> I still can't get mail to the reflector, thanks to some IT voodoo
>>>
>>> somewhere.
>>>>
>>>> [Paul Graham]
>>>>>
>>>>> For what it's worth, variable width and variable offset part
>>>>> selects have always been part of vhdl.  Vhdl has no special
>>>>> syntax to distinguish variable part selects from constant
>>>>> part selects, so a tool has to do some analysis to see which
>>>>> forms it can support and which it can't.
>>>>
>>>> But this reflects a completely different way of thinking about
>>
>> vector
>>>
>>> widths in VHDL
>>>>
>>>> than in Verilog.  A VHDL slice's type is a subtype of some base
>>
>> type,
>>>
>>> and
>>>>
>>>> its assignment-compatibility with some target is checked at runtime
>>
>> -
>>>
>>> types
>>>>
>>>> are checked at compile time, subtypes are checked at runtime.
>>>
>>> Synthesis
>>>>
>>>> is entitled to complain if the subtype of an expression is not
>>>
>>> statically
>>>>
>>>> determinable, but simulation must live with it and throw an error at
>>>> runtime if you attempt to use something in a way that's not
>>
>> appropriate
>>>>
>>>> to its subtype (such as copying it to a target of the same type but
>>>> different subtype).  And yes, of course, that does impose a runtime
>>>> cost in some situations.
>>>>
>>>> But it brings with it the wonderful power of unconstrained
>>
>> subprogram
>>>>
>>>> arguments.  So, for example, the concatenation
>>>>
>>>>     A(127 downto N)&   B(N-1 downto 0)
>>>>
>>>> is in fact a call to function "&", whose local variables, and return
>>>> "variable", are elaborated dynamically when the function is called.
>>>> The returned result will indeed have 128 bits (even if N is +128
>>>> or -1, making one of the operands be a null or zero-width slice).
>>>> It's a moot point whether synthesis can do enough algebra to
>>>> be able to work out that invariant for itself.
>>>>
>>>> I don't really see how anything like this could be grafted on to
>>>> Verilog at this stage without spectacular and wide-ranging fallout.
>>>> I sense that there is some frustration among the design community
>>>> that Verilog lacks the expressive power of VHDL when it comes
>>>> to writing general-purpose subprograms, but it would be a bad
>>>> mistake to try to adopt some half-baked form of dynamic subtype
>>>> as if this were a "feature" that could be added independently of
>>>> the rest of the language.
>>>>
>>>> Of course, queues and dynamic arrays make all this largely
>>>> irrelevant outside the world of RTL.
>>>>
>>>> Thanks
>>>>
>>>> Jonathan Bromley
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>
>>>> Intel Israel (74) Limited
>>>>
>>>> This e-mail and any attachments may contain confidential material
>>
>> for
>>>>
>>>> the sole use of the intended recipient(s). Any review or
>>
>> distribution
>>>>
>>>> by others is strictly prohibited. If you are not the intended
>>>> recipient, please contact the sender and delete all copies.
>>>>
>>>
>>> --
>>>       John Michael Williams
>>>       Senior Adjunct Faculty
>>> Silicon Valley Technical Institute
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>
>>
>
> --
>        John Michael Williams
>        jwill@BasicISP.net
>
>
> --
> 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.