RE: [sv-bc] clarification request

One issue I just remembered while trying to fix another force/release
issue.

The LRM was never clear about overlapping force/releases and not
allowing bit or part selects simply avoids the issue,

module top;
logic [3:0] A;
initial begin
  $monitor("%t %b",$time, A);
  #1 A = 0;
  #1 force A[3:2] = 2'bx;
  #1 force A[2:1] = 2'bz; // does this replace the previous force?
  #1 A = '1; // Is A[3] still x?
  #1 release A[2:1]; // does A[2] go back to x?
end
endmodule

I can see that for wires it's easy to think of them as a collection of
independent bits driven by independent continuous assignments. You just
add a force element as part of the resolution of each bit. But for
variables that are procedurally assigned, you think in terms of an
entire expression as a whole.

Dave


> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Friday, October 05, 2007 12:39 PM
> To: sharp@cadence.com; sv-bc@eda.org; Rich, Dave
> Subject: RE: [sv-bc] clarification request
> 
> 
> >From: "Rich, Dave" <Dave_Rich@mentor.com>
> 
> >Regardless of the reasoning, my current interpretation of the LRM
> >remains, and you many not mix CAs and PAs to the same packed object.
You
> >would have to remove that text (as long as you still are not able to
mix
> >CAs and PAs to elements that share their longest static prefix). I
can
> >tell you at this point I really don't have a preference as this seems
to
> >be a stylistic restriction.
> 
> OK, I accept your statement as to the intent.
> 
> I will consider making a proposal to remove the restriction.
> 
> Steven Sharp
> sharp@cadence.com


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