Re: [sv-bc] 4-state or 2-state expression types

Oops, thanks. Too much haste, too little attention.

Jonathan

----- Original Message ----
> From: "Bresticker, Shalom" <shalom.bresticker@intel.com>

> "Part-selects that are partially out of range shall, when read, return x for
>the bits that are out of range and shall, when written, only affect the bits
>that are in range."
>
> Shalom
>
>
> > -----Original Message-----
> > From: Jonathan Bromley [mailto:jonathanbromley@ymail.com]
> > Sent: Wednesday, March 23, 2011 2:48 PM
> > To: Bresticker, Shalom; Steven Sharp; Gordon Vreugdenhil; sv-bc
> > Subject: Re: [sv-bc] 4-state or 2-state expression types
> >
> > It seems, then, that we can make the problem go away - and completely
> > answer
> > Gord's question that started this thread - by specifying that the
> > result of an
> > out-of-range access on a 2-state packed object is a 2-state '0. That's
> > compatible with the de facto behaviour of three major tools, with the
> > exception
> > of one rather obscure corner case (the tool that treats statically-
> > known
> > out-of-range accesses differently). It would be a straightforward
> > update of the
> > text in 11.5.
> >
> > Any strong objections?
> >
> > One final wrinkle: Suppose I do an invalid part-select that overlaps
> > the valid
> > range. Should the entire result be '0/'x, as the LRM suggests? Or
> > should the
> > bits that are within range be given their "correct" value, as if they
> > had been
> > picked one-by-one using a 'for' loop? Example:
> >
> > logic [7:0] B = 'h55;
> > logic [7:0] Slice = B[11:4]; // Should Slice be 8'hx5 or 8'hxx?
> >
> > Thanks
> >
> > Jonathan
> >
> >
> >
> > ----- Original Message ----
> > > From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> > > To: Jonathan Bromley <jonathanbromley@ymail.com>; Steven Sharp
> > ><sharp@cadence.com>; Gordon Vreugdenhil <gordonv@model.com>; sv-bc
> > ><sv-bc@eda.org>
> > > Sent: Wed, 23 March, 2011 12:19:56
> > > Subject: RE: [sv-bc] 4-state or 2-state expression types
> > >
> > > Also, Table 7-1, which specifies values to be returned from a non-
> > existent
> > >array entry, already specifies that reading a non-existent 2-state
> > element
> > >returns '0. More generally, a value is always returned that is in the
> > value set
> > >of the corresponding data type. I find it questionable that 2-state
> > integral
> > >types should be exceptions.
> > >
> > > Shalom
> > >
> > > > -----Original Message-----
> > > > From: Jonathan Bromley [mailto:jonathanbromley@ymail.com]
> > > > Sent: Wednesday, March 23, 2011 1:46 PM
> > > > To: Bresticker, Shalom; Steven Sharp; Gordon Vreugdenhil; sv-bc
> > > > Subject: Re: [sv-bc] 4-state or 2-state expression types
> > > >
> > > > I spoke a little too soon...
> > > >
> > > >
> > > >
> > > > > The two simulators I can try right now disagree about this.
> > Doing
> > > > an
> > > > > out-of-range select on a 2-state vector, one yields 4-state
> > 1'bx,
> > > > the other
> > > > > 2-state 1'b0.
> > > >
> > > > The third big-name simulator also yields a 2-state result.
> > > >
> > > > In fact the simulator that yielded 4-state 1'bx did so only when
> > the
> > > > subscript
> > > > was statically known to be out of bounds (and it gave me an
> > > > elaboration-time
> > > > warning for that too). An out-of-bounds subscript computed at
> > runtime
> > > > gave
> > > > 2-state 1'b0, just like the other simulator. I don't know whether
> > that
> > > > should
> > > > affect BC's thinking...
> > > >
> > > > 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.
>
> --
> 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.