I agree with Jim (why do we need this?), especially if it will be restricted to a synchronous context (of which vhdl simulators know nothing). If not restricted to synchronous contexts, I abhor the thought of defining standard attributes for clock, reset, etc. for an implicit register for a signal (note that current attribute semantics would not allow such a use model anyway). If I wanted that, I'd still be using Abel. I believe there may be other means of achieving similar conciseness with current capabilities, while preserving the existing sequential statement semantics: A procedure with an inout array parameter for the pipeline (you have to declare the array, but once done, its use is concise.) A protected type package implementation with a pipe() function method, using a package generic for the arg/result data type (from which it builds the hidden, static array). Anonymous types could help these a lot. Most of the proponents have exclusively mentioned the synthesis aspects of this proposal. What about the language/simulation aspects? The last thing I want to add to VHDL is a new gee-whiz feature that is difficult to integrate consistently into the rest of the language. 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 Jim Lewis Sent: Thursday, March 27, 2014 3:27 PM To: vhdl-200x@eda.org Subject: EXTERNAL: Re: [vhdl-200x] Clocked Shorthand Proposal - Need Consensus Hi All, @ comes from PSL. Quoting IEEE 1850-2010: 6.2.1.2 Clocked FL properties The FL clock operator operator(@), shown in Syntax 6-18, provides a way to clock an FL Property. FL_Property ::= FL_Property @ Clock_Expression The first operand is the FL Property to be clocked. The second operand is a Boolean expression with which to clock the FL Property. The @ operator specifies that the clock expression that is its right operand defines the clock context of its left operand. Hence with '@', we are not introducing a new operator, just recycling the one from PSL. Personally I prefer expressive code and am not fond of either '@' or "after" since they do not mention Clk. Who knows though, if the "C/C++" style behavioral synthesis takes hold, maybe we no longer need to specify clock in our designs. Just waiting for someone to do a decent VHDL behavioral synthesis tool. OTOH, I am not convinced we need any syntax for this. When you start looking at adding reset, we do not have anything that is all that much better than: Q <= D when rising_edge(Clk) ; Q <= '0' when not nReset else D when rising_edge(Clk) ; Q <= '0' when not nReset and rising_edge(Clk) else D when rising_edge(Clk) ; Ok, so you loose the pipelining, however, maybe that is what we need the operator for. If I want more concise, but less expressive code, I can always switch to using a procedure: Reg(Clk, D, Q) ; RegAr(Clk, not nReset, D, Q) ; RegSr(Clk, not nReset, D, Q) ; RegR(Clk, not nReset, D, Q) ; -- default reset style choosen by selecting/compiling a particular package body. RegPipe(Clk, D, Q, 5) ; Some of the reset issues would be simplified if synthesis tools provided a mechanism for shifting reset styles. Jim -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis VHDL Training Expert, SynthWorks IEEE 1076 VHDL Working Group Chair Open Source VHDL Verification Methodology (OSVVM), Chief Architect and Co-founder 1-503-320-0782 Jim@SynthWorks.com<mailto:Jim@SynthWorks.com> http://www.SynthWorks.com VHDL Training on leading-edge, best coding practices for hardware design and verification. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- 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 Thu Mar 27 15:50:53 2014
This archive was generated by hypermail 2.1.8 : Thu Mar 27 2014 - 15:51:18 PDT