I understand the desire to maintain the integrity of the LRM as defining the language itself. However, we already include a number of standard package specifications which are really application specific rather than pure language definition. The whole issue of specifying delta cycle implementation defines simulation implementation and could be considered out of scope, but has been defined in the LRM for some time. I am proposing that we enable a method to standardize design requirements from the language through to the tools of both simulation and synthesis. Maybe we should consider revising the acronym to "VHSIC Hardware Design Language" instead of its original "Description" requirement. Cheers, Brent. On 19/05/2014 20:59, Jones, Andy D wrote: > > 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. > -- 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.Received on Fri May 30 02:32:40 2014
This archive was generated by hypermail 2.1.8 : Fri May 30 2014 - 02:33:07 PDT