As Evan noted, this is a double-edged sword. Bringing synthesis aspects into the same standard that defines the language is likely begging for more “I need a short-hand syntax to specify a <insert widget here>” proposals for the language. Unfortunately, too many university curriculums start out (and worse, end) with “this is a register, and this is combinatorial logic” templates, along with similarly simple-minded approaches to latch avoidance, etc., rather than focusing on the behavioral differences between sequential and combinatorial logic (including latch behavior), and how to describe those differences in a way that is understood by compliant tools The original 1076.6 was somewhat to blame for this. However, the 2004 version takes the more behavioral approach. I believe that the state of the art in synthesizable coding would benefit if students were initially taught to use variables exclusively for internal process data, and reserve the use of signals only for communication between processes. Learning how to use variables for both sequential and combinatorial logic descriptions reinforces the understanding of how you get a latch from an otherwise combinatorial, and therefore how to avoid the same. But I digress… Since 1076.6 has been withdrawn, if we want to keep it (and I think we should) one of the few options available is to merge it into the main standard. In that vein, I am in favor of inclusion of 1076.6 as a normative annex to the main 1076 standard. By keeping them in the same document, we encourage more improvement suggestions like “why are protected type methods not synthesizable?” Andy D Jones Electrical Engineering Lockheed Martin Missiles and Fire Control Dallas TX From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Daniel Kho Sent: Friday, May 16, 2014 5:19 AM To: vhdl-200x@eda.org Subject: EXTERNAL: Re: [vhdl-200x] Request for Opinion: Should 1076.6 be subsumed into the main 1076 standard? The 1076.6 VHDL subset _was_ expected to be handled by vendors in a consistent way, but no longer after the standard was withdrawn. I've talked to at least one major FPGA vendor who refuses to support some of the things in 1076.6 simply because the standard has been "withdrawn". I would support the idea of having 1076.6 subsumed into the main 1076 standard, so vendors have no excuses not to support any feature mentioned in 1076.6. Best regards, Daniel On 16 May 2014 17:22, Evan Lavelle <eml-vhdl-200x@cyconix.com<mailto:eml-vhdl-200x@cyconix.com>> wrote: No. 1076.6 isn't "VHDL"; it's simply a subset of VHDL which synthesis vendors are expected to handle in a consistent way. It reflects the lowest common subset of functionality that was expected from synthesis tools at the specific time that the standard was written. In my opinion, it would be a major mistake to cast this in stone as part of "VHDL". It is domain-specific implementation, not language, and is not related to the core language and its definition. This would be rather like changing the C or C++ standards to show what Microsoft had achieved in Visual C++ 6.0, for example. We'd also have issues with people believing that VHDL defined concepts such as "flip flops", clocks, resets, and so on, because "it's in the LRM". Finally, some of us will remember that there was a certain amount of politics in the original 1076.6. With hindsight, this was probably the start of a very long and slippery path, which has ended with the IEEE rubber-stamping vendor-defined standards. This is itself, IMO, reason enough to keep 1076.6 at arm's length from the core language. -- 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<http://www.mailscanner.info/>, 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 Mon May 19 13:00:23 2014
This archive was generated by hypermail 2.1.8 : Mon May 19 2014 - 13:03:51 PDT