[sv-bc] Re: [sv-ec] streaming operator unpack operation

Hi Kapil,
Thanks for pointing out.
However, whatever I can understand then, by the following assignment:

{<<{ a, b, c }} = 100'b1;

'a' will have '1' at bit 31, and all other bits will have value '0'.


Regards
Surya



-------- Original Message --------
Subject: Re:[sv-ec] streaming operator unpack operation
From: Kapil Kaushik <kkapil@Magma-DA.COM>
To: Surya Pratik Saha <spsaha@cal.interrasystems.com>
Cc: "Jonathan Bromley" <jonathan.bromley@doulos.com>, "Bresticker, 
Shalom" <shalom.bresticker@intel.com>, sv-ec@eda.org, sv-bc@eda.org
Date: Tuesday, March 11, 2008 12:52:53 PM
>
> Hi Surya,
>
> "*If the left-hand side represents a fixed-size variable and the 
> stream is larger than the variable, an error will be generated."*
>
> This statement is made w.r.t. the “pack operation”, while the example 
> you refer to is that of “unpack operation”. So I guess you are mixing 
> up two different things. There is another example in the LRM which 
> corresponds to this statement:
>
> *int *j = {>>{ a, b, c }}; // error: j is 32 bits < 96 bits
>
> Thanks,
>
> Kapil
>
> ------------------------------------------------------------------------
>
> *From:* Surya Pratik Saha [mailto:spsaha@cal.interrasystems.com]
> *Sent:* Tuesday, March 11, 2008 12:42 PM
> *To:* Kapil Kaushik
> *Cc:* Jonathan Bromley; Bresticker, Shalom; sv-ec@eda.org; sv-bc@eda.org
> *Subject:* Re: [sv-ec] streaming operator unpack operation
>
> Hi,
> LRM once states:
> "*If the left-hand side represents a fixed-size variable and the 
> stream is larger than the variable, an error will be generated."*
>
> And then there is an e.g:
>
> *{>>{ a, b, c }} = 100'b1;*
> * *
> If we go by the text, then the e.g. is wrong.
>  
> They are contradictory to each other. Either of them has to be fixed.
> Regards
> Surya
>
>
>
> -------- Original Message --------
> Subject: Re:[sv-ec] streaming operator unpack operation
> From: Kapil Kaushik <kkapil@magma-da.com> <mailto:kkapil@magma-da.com>
> To: Jonathan Bromley <jonathan.bromley@doulos.com> 
> <mailto:jonathan.bromley@doulos.com>, Bresticker, Shalom 
> <shalom.bresticker@intel.com> <mailto:shalom.bresticker@intel.com>, 
> sv-ec@eda.org <mailto:sv-ec@eda.org>
> Date: Tuesday, March 11, 2008 12:17:57 PM
>
> Hi Jonathan/Shalom,
>  
> Thanks for your detailed explanation of the things. 
>  
> I am just restating what you said for my own clarity. Please point me
> out if I am wrong.
> {(operator){a, b, c}} = 100'b1, where "operator" = ">>" or "<<"
> is equivalent to taking the left 96 bits and streaming them according to
> the normal streaming rules, and it does not depend upon the "operator"
> as to which bits of RHS will be truncated.
>  
> So for both the cases below:
> {>>{ a, b, c }} = 100'b1;
> {<<{ a, b, c }} = 100'b1;
>  
> We will have a = 0, b = 0, and c = 0.
>  
> Thanks,
> Kapil
>  
> -----Original Message-----
> From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] 
> Sent: Tuesday, March 11, 2008 11:17 AM
> To: Bresticker, Shalom; Kapil Kaushik; sv-ec@eda.org <mailto:sv-ec@eda.org>
> Subject: RE: [sv-ec] streaming operator unpack operation
>  
> First, my apologies to Kapil for the original very
> brief reply - I was very short of time then.
>  
>   
>> I assume you refer to the following sentence:
>>  
>> "If the source expression contains more bits than are
>> needed, the appropriate number of bits shall be consumed
>> from its left (most significant) end."
>>     
>  
> That's exactly what I meant.
>  
>   
>> Then I think the example is misleading:
>>  
>>  {>>{ a, b, c }} = 96'b1; // OK: unpack a = 0, b = 0, c = 1
>>  {>>{ a, b, c }} = 100'b1; // OK: unpack as above (4 bits unread)
>>  
>> "unpack as above" implies that a, b, and c receive the
>> same values as in the previous example. If the unpacking
>> is from the left end, that will not be true.
>> c will get 0, not 1.
>>     
>  
> You are of course correct.  I obviously missed this when
> writing 1707, and so did we all when reviewing it.
>  
> I know that the left-justify specification is strange, but
> it is already mandated for packing in the existing Draft 4
> text:
>  
>    The result of the pack operation can be assigned 
>    directly to any bit-stream type variable. If the 
>    left-hand side represents a fixed-size variable 
>    and the stream is larger than the variable, an 
>    error will be generated. If the variable is larger 
>    than the stream, the stream is left-justified 
>    and zero-filled on the right.
>  
> And it seems absurd for packing and unpacking not to
> be symmetrical in this respect.  If you pack 
> something and then immediately unpack it again with
> the complementary assignment (or vice versa) you 
> surely should expect bits to end up in the same
> places they originally were.
>  
> Personally I think the left-justify semantics is bizarre,
> but I didn't want to change what was already there.
>  
> I'll raise a Mantis to change the example.
>   
>





-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.