1. If you don't like it, you don't have to use it. (I know this is a weak argument because you may have to deal with someone else's code who *did* use it.) 1a. I plan to use it when it most clearly expresses my design intent -- when it's better than an 'if' statement. 2. Like Andy's mom said, "Just because you can doesn't mean you should." I like the C++ FAQ's distinction between "legal" and "moral", often referring to certain constructs as "evil" (i.e. immoral): <http://www.parashift.com/c++-faq/defn-evil.html>. Although the Verilog/SystemVerilog constructions you described are legal, they may still be "evil". The C++ FAQ has an interesting entry on the ternary operator for that language: <http://www.parashift.com/c++-faq/ternary-op.html>. The author's conclusion is that the ternary operator is valuable when used correctly. This is my opinion exactly. 3. 'X' propagation is a problem for 'if' statements and all logical operators. Were you expecting ternary operators to magically side-step the problem? The Wikipedia link was lost. But that sounds like a fun idea. Enjoy! - Ryan -----Original Message----- From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Tim Schneider Sent: Thursday, April 04, 2013 10:44 AM To: vhdl-200x@eda.org Subject: RE: EXTERNAL: [vhdl-200x] VHDL ternary operation *** On Thursday, April 04, 2013 6:46 AM Jones, Andy D <andy.d.jones@lmco.com> writes:*** >> If we continue to "cryptify" the VHDL language, we are only >> accelerating its demise. One of VHDL's founding principles >> and best assets is readability, due in part to its verbosity. >> >> That said, is there a way we can make the "x when y else z" >> construct fill this ternary operator role in an unambiguous way? >> >>Thus if allowed, the expression "x when y else z" would satisfy the >> desire for an anonymous ternary operator expression with a syntax >> that is already very readable and well understood. Not a fan of the ternary operator except for usage in "I can write that code in one line" contests http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest I've seen it get ugly quickly in Verilog/System Verilog when combined with other logical operators, (a massive conditional statement for instance?) Then you have different results based on the '==' and '===' cases. The other one that sometimes trips users and EDA tools up? When one of the operators is an 'X' the whole expression returns 'X' http://en.wikipedia.org/wiki/%3F: The Fortan 98 version 'merge' ? Now throw that in with the ability to goto a variable.. now you're talking! :) -tim -----Original Message----- From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jones, Andy D Sent: Thursday, April 04, 2013 6:46 AM To: vhdl-200x@eda.org Subject: RE: EXTERNAL: [vhdl-200x] VHDL ternary operation If we continue to "cryptify" the VHDL language, we are only accelerating its demise. One of VHDL's founding principles and best assets is readability, due in part to its verbosity. That said, is there a way we can make the "x when y else z" construct fill this ternary operator role in an unambiguous way? Now that it is allowed as both sequential and concurrent assignments (and sequential variable assignments), on various forums I have seen requests/confusion for/about its use in several other places which resemble an assignment (e.g. initializations, associations, etc.). Part of the issue is that the assignment statements can be open-ended (no final else without when), which is not acceptable if the construct is used as an expression that MUST return a value. Perhaps if we limit use of this form as an expression to exactly one 'when' and exactly one 'else', and surround it in parentheses if used as an argument in a ternary expression (like we require with AND/OR) then "x when y else z", where x, y and z are themselves expressions, y is also a condition, and the type of x and z is the same, this would qualify as an unambiguous ternary operator expression? This would allow compound expressions like "(x when y else z) when a else b", or "x when y else (a when b else z)" or even "x when (y when a else b) else z". Yes, my mother told me many, many times, "Just because you can does not mean you should." Thus if allowed, the expression "x when y else z" would satisfy the desire for an anonymous ternary operator expression with a syntax that is already very readable and well understood. Andy D Jones Electrical Engineering Lockheed Martin Missiles and Fire Control Dallas TX -----Original Message----- From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Brent Hayhoe Sent: Wednesday, April 03, 2013 6:11 PM To: vhdl-200x@eda.org Subject: Re: EXTERNAL: [vhdl-200x] VHDL ternary operation At first I thought I knew what we were talking about, but then got confused and finally realized I was correct in my first thoughts. So, yes ternary operator(s) I now realize we don't have them in VHDL at the moment. And I agree with Daniel and Jim in that they would be a useful language addition (at least from my user perspective!) Now whilst I initially thought that the suggested versions of: ({cond} when {true} else {false}) or: ({cond} if {true} else {false}) were indeed very VHDL'y in their syntax, I can understand that they might incur ambiguities in their syntax implementation. So as we already have introduced the '?' character in many operators within VHDL, why not stick to the more standard: ({cond} ? {true} : {false}) I hadn't realised just how many languages use this ternary operator or where it originated from (according to Wikipedia) being CPL. The problem I see is this; how do we generate a syntax for writing the defining function? We already have for unary operators: function "??" (right : anonymous) return binary; and for binary operators: function "=" (left, right : anonymous) return binary; So extending to ternary operators should be easy except for the function name. The operator name/character is split and so we need a new syntax in order to handle this. I'll suggest one to start people thinking: function "?",":" (left : Boolean; middle, right : anonymous) return middle'subtype; where: left -> {condition} middle -> {value when true} right -> {value when false} and using Jim's proposed anonymous types (which I also like). Regards, Brent. On 28/03/2013 18:33, Jim Lewis wrote: > Daniel, > We talked about something for 2008, however, it evolved from: > ("pass" when fault else "fail") > > But this was problematic due to conditional assignment. > Then we considered: > ("pass" if fault else "fail") > > This was ok, but was rejected since some wanted "less" > typing, and hence, proposed: > ("pass" if fault, "fail") > > This turned out to have some ambiguity problems and was rejected. We > never did go back to considering "else". > > For the next revision, I am hoping to have functions that allow usage > of anonymous types. And hence, we could write something like: > > function cond ( > sel : boolean ; > A : anonymous ; > B : A'subtype > ) return A'subtype is > begin > if Sel then > return A ; > else > return B ; > end function cond ; > > Anonymous types would own a broad space of the overloading. > Hence, we could not write a function with the signature: > cond[boolean, std_logic, std_logic return std_logic] > > but we could write a function with the signature: > cond[std_logic, anonymous, anonymous return anonymous] > > For this particular issue we could of course also consider language > syntax. However, I like general features and subprograms as a little > gives us alot of capability. > > Best Regards, > Jim > > >> Daniel, >> >> /_"pass" when fault else "fail"_/is NOT an expression. It is the RHS >> of a conditional assignment statement. Such a RHS may contain >> expressions, but expressions may not contain a conditional assignment >> RHS. >> >> Since conditional assignments can be open-ended, in effect meaning >> that the assignment does not occur if no "when" expression evaluates >> as true, its use as an expression is not possible. >> >> To solve your immediate problem, you could write a function that >> takes a boolean argument and returns "pass" or "fail" strings, or you >> could create a constant array of two strings, indexed by boolean, >> e.g. (true => "fail", false => "pass"). Then you could include the >> function call or constant in your report expression. >> >> Andy >> >> *From:*owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On >> Behalf Of *Daniel Kho >> *Sent:* Thursday, March 28, 2013 4:19 AM >> *To:* vhdl-200x@eda.org >> *Subject:* EXTERNAL: [vhdl-200x] VHDL ternary operation >> >> Hi all, >> >> I'm wondering if the current revision supports something like the following? >> >> report to_hstring(index) & ", " & ("pass" when fault else "fail") & >> lf & nul; >> >> where "index" is an unsigned vector, and "fault" is a boolean. >> >> The expression ("pass" when fault else "fail") can already be used >> directly in clocked processes, but I'm not too sure if the standard >> allows this to be used within report statements. >> >> If there's a better way of writing which could produce the same >> effect, do share with me as well. >> >> regards, daniel >> >> >> -- >> 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* <http://www.mailscanner.info/>, and is believed to be >> clean. -- Regards, Brent Hayhoe. Aftonroy Limited Telephone: +44 (0)20-8449-1852 135 Lancaster Road, New Barnet, Mobile: +44 (0)79-6647-2574 Herts., EN4 8AJ, U.K. Email: Brent.Hayhoe@Aftonroy.com Registered Number: 1744190 England. Registered Office: 4th Floor, Imperial House, 15 Kingsway, London, WC2B 6UN, U.K. -- 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.Received on Thu Apr 4 10:00:46 2013
This archive was generated by hypermail 2.1.8 : Thu Apr 04 2013 - 10:00:53 PDT