RE: [sv-ac] Checker construct proposal: any comments yet?

Hi,

I'd also rather have a meaningful name rather than a symbol. 
nondet, one of, select, ...

ed

 

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> Behalf Of Korchemny, Dmitry
> Sent: Wednesday, July 04, 2007 2:52 AM
> To: Seligman, Erik; Brad Pierce; sv-ac@eda-stds.org
> Subject: RE: [sv-ac] Checker construct proposal: any comments yet?
> 
> Hi,
> 
> One could introduce a new operator as well, instead of a new system
> function. Note that this operator will have variable arity, such as a
> concatenation operator {} or operators "inside" or "dist". If 
> to use an
> operator construct, then it is more intuitive to introduce an operator
> having a meaningful name like undet. This is very similar to a system
> function, but requires adding one more keyword.
> 
> Thanks,
> Dmitry
> 
> -----Original Message-----
> From: owner-sv-ac@server.eda.org 
> [mailto:owner-sv-ac@server.eda.org] On
> Behalf Of Seligman, Erik
> Sent: Monday, July 02, 2007 8:03 PM
> To: Brad Pierce; sv-ac@server.eda-stds.org
> Subject: RE: [sv-ac] Checker construct proposal: any comments yet?
> 
> 
> Hi Brad--  Thanks for taking a look.
> 
> Yes, you're correct that it's not a formal proposal that 
> could be added
> to the LRM yet.  Because this is a relatively complex new feature, we
> wanted to start with a basic document that describes the 
> concept, so we
> could begin gathering comments. 
> 
> Dmitry, Ed-- comments on the operator idea mentioned below 
> for $nondet?
> 
> 
> 
> -----Original Message-----
> From: owner-sv-ac@server.eda.org 
> [mailto:owner-sv-ac@server.eda.org] On
> Behalf Of Brad Pierce
> Sent: Monday, July 02, 2007 9:06 AM
> To: sv-ac@server.eda-stds.org
> Subject: Re: [sv-ac] Checker construct proposal: any comments yet?
> 
> Erik,
> 
> An enhancement proposal will usually get more feedback if it is also
> distributed on the reflector, instead of just uploaded to Mantis, so
> I've attached a copy of your current version.
> 
> Your document is not in the form of a formal proposal, but 
> apparently it
> would add new keywords 'checker' and 'endchecker', plus a new system
> function $notdet() for making a nondeterminstic choice between
> arguments.
> 
> Is a system function the best syntax for the latter 
> capability?  Why not
> add a true operator like |~| for internal choice?
> 
> Also, I don't think it would be a good idea to add comments like the
> following to the LRM
> 
>   "A free variable appears only in checkers, and thus should never be
> synthesized into silicon."
> 
> -- Brad
> 
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Seligman, Erik
> Sent: Monday, July 02, 2007 8:17 AM
> To: sv-ac@eda-stds.org
> Subject: [sv-ac] Checker construct proposal: any comments yet?
> 
> 
> Hi all--
> 
> Just wanted to send a reminder to take a look at this new proposal, on
> 'checker' constructs, when you get the chance:
> 	http://www.verilog.org/mantis/view.php?id=1900
> 
> This is a relatively major language enhancement, so it might 
> be good to
> start discussion going so we can begin revising it & converge in a
> reasonable time frame.  I suspect there will be many questions and
> issues.
> 
> Thanks!
> 
> --
> 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.
> 
> -- 
> 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.
> 
> 
> 

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