RE: [sv-bc] Mantis 2097

This was Steven's position also.

Although I agree with Stu in principle as to what I would ideally like,
my intent in Mantis 2097 is not to change that. So I will repeat my
question: Should 

"A single force or release statement shall not be applied to a whole or
part of a variable that is being assigned by a mixture of continuous and
procedural assignments."

be reworded as 

"A force or release statement shall not be applied to a variable that is
being assigned by a mixture of continuous and procedural assignments." ?

Thanks,
Shalom
 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil
> Sent: Thursday, December 06, 2007 6:28 PM
> To: stuart@sutherland-hdl.com
> Cc: 'sv-bc'
> Subject: Re: [sv-bc] Mantis 2097
> 
> I disagree.  There are issues where overgeneralizing a 
> construct will in fact cause wide-spread issues for vendors 
> and for which implementations will necessarily slow down.  
> Unless there is a truly compelling need for introducing such 
> generalizations, I would not suggest doing so.
> In practice it matters a great deal how one handles "bits" of 
> a variable; similar reasons come into play in terms of why 
> selects of packed elements are not legal as actuals for "ref" 
> formals.  Of course an implementation
> *could* do it, but how much are you willing to pay in 
> performance for such a feature?  Vendors do not oppose things 
> like this just to be difficult -- there are real issues 
> involved with both the complexity of implementation and 
> overall performance that are not nearly as simple as you may think.
> 
> I would oppose any generalization of forces which would 
> require bit-level behavior into packed variables.
> 
> Gord.
> 
> Stuart Sutherland wrote:
> > Why restrict force/release at all?  The ability to inject 
> errors using 
> > force and release is one of the strengths of Verilog.  From 
> my user's 
> > point of view, it should not matter how the variable, or 
> parts of it, 
> > are normally assigned values.  I can accept a tool requiring I turn 
> > off some level of optimization in order to use 
> force/release, just as 
> > tools do with many of the VPI constructs, but the standard should 
> > allow unconditional force/release.  Such optimization 
> control does not 
> > need to be specified in the standard, again just as with the VPI.
> > 
> > Stu
> > ~~~~~~~~~~~~~~~~~~~~~~~~~
> > Stuart Sutherland
> > Sutherland HDL, Inc.
> > stuart@sutherland-hdl.com
> > 503-692-0898
> >  
> > 
> >> -----Original Message-----
> >> From: owner-sv-bc@server.eda.org
> >> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom
> >> Sent: Thursday, December 06, 2007 6:56 AM
> >> To: sv-bc
> >> Subject: [sv-bc] Mantis 2097
> >>
> >> Steven Sharp pointed out that the proposal says,
> >>
> >> "A single force or release statement shall not be applied to the 
> >> whole or the selected part of a variable that is being 
> assigned by a 
> >> mixture of continuous and procedural assignments."
> >>
> >> This is a minor rewording of the existing text,
> >>
> >> "A single force or release statement shall not be applied 
> to a whole 
> >> or part of a variable that is being assigned by a mixture of 
> >> continuous and procedural assignments."
> >>
> >> The problem is that a force is not allowed to part of a variable. 
> >> This looks like an error in 1800-2005. I think it should just be,
> >>
> >> "A force or release statement shall not be applied to a 
> variable that 
> >> is being assigned by a mixture of continuous and procedural 
> >> assignments."
> >>
> >> Comments? 
> >>
> >> Thanks,
> >> Shalom
> >>
> >> Shalom Bresticker
> >> Intel Jerusalem LAD DA
> >> +972 2 589-6582
> >> +972 54 721-1033
> >>
> >> 
> ---------------------------------------------------------------------
> >> 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 <http://www.mailscanner.info/> , and is believed to be 
> >> clean.
> >>
> > 
> > 
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
---------------------------------------------------------------------
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.