Hi Jonathan/Shalom, I am still not clear about the problem we are having with the streaming unpack case. I am attaching the text from one of my previous mails. Could you please confirm if what I am concluding is correct? > 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 ________________________________ From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Kapil Kaushik Sent: Tuesday, March 11, 2008 1:16 PM To: Surya Pratik Saha Cc: Jonathan Bromley; Bresticker, Shalom; sv-ec@eda.org; sv-bc@eda.org Subject: [sv-bc] RE: [sv-ec] streaming operator unpack operation Hi Surya, 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'. The above is true if we start streaming from the right (which we normally do for a left streaming operator), but in this case if we truncate the bits before we start streaming, then we may get different results. Even I am not absolutely sure about this, and that is why I wrote the example, so as to have a feedback from Jonathan/Shalom. Thanks, Kapil -----Original Message----- From: Surya Pratik Saha [mailto:spsaha@cal.interrasystems.com] Sent: Tuesday, March 11, 2008 1:04 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 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 <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Mar 12 22:32:12 2008
This archive was generated by hypermail 2.1.8 : Wed Mar 12 2008 - 22:34:14 PDT