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

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.