RE: EXTERNAL: Re: [vhdl-200x] Clocked Shorthand Proposal - Need Consensus

From: Jones, Andy D <andy.d.jones@lmco.com>
Date: Thu Mar 27 2014 - 15:50:30 PDT
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