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

If your goal is to minimize code size for an asynchronously reset register that can store an anonymous data type, I (re)nominate the following EXISTING VHDL code (fully synthesizable):

Q <= INIT when RST = '1' 
   else D when rising_edge(CLK); 

INIT, D and Q can be of any type, but must be of the same type.

For a synchronously reset register:

Q <= INIT when rising_edge(CLK) and (RST = '1')
  else D when rising_edge(CLK);

I don't know if any synthesis tools support the latter.

Regarding option 4:

The difficulty with function calls in sensitivity lists (if allowed) is that they represent an implicit signal (the result of the function), which updates a delta cycle AFTER the actual clock edge. Therefore the process would trigger a delta cycle after the actual rising edge of the signal (and again a delta cycle later when rising_edge(clk) goes false). The former is bad, the latter leads to additional code anyway.

We could look at defining new attributes, 'rising & 'falling, which like 'event, do not exhibit a delta delay. 

How would we define 'rising for an arbitrary scalar data type? Enum_type'pos(S) > enum_type'pos(S'last), or S > S'last? Ugh...

Nevertheless, when a reset is used, there is an alternative condition (and maybe sensitivity), which still requires if-then-else code to sort out, so what's the relative expense of "elsif rising_edge(clk) then"? (Didn't Jim mention something about this?)

In abstraction, shouldn't we be thinking more about clock cycle delays, and how the code behaves in terms of function and latency anyway, rather than about registers? Most SP&R tools replicate, consolidate and retime registers anyway. What remains faithful to the RTL code is the behavior (the function and latency).
		
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 Nick Gasson
Sent: Tuesday, April 01, 2014 3:35 AM
To: vhdl-200x@eda.org
Cc: ryan.w.hinton@L-3com.com
Subject: RE: EXTERNAL: Re: [vhdl-200x] Clocked Shorthand Proposal - Need Consensus

On 31/03/14 18:43, ryan.w.hinton@L-3com.com wrote:
>
> I'm coming at this from the perspective of, "What might we be able to improve in VHDL?"  I am most productive when the language I'm using supports more direct ways to express the algorithm/block diagram in my head.  That's why I got involved with the last VHDL revision: the unconstrained array elements and fixed-point library significantly improve my ability to express my design intent.  So I asked the question, "What is a VHDL-like way to intentionally create a clocked process?"  Syntax option 3 [http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ClockedShorthand#Syntax_Option_3] is my best answer.  This is a hardware question, so it's valid to ask of a hardware language.
>

Hi Ryan,

Of the options listed on that page I actually find option 4 is more in keeping with the existing language. E.g. contrast this, using the option
3 syntax:

     process rising clock(clk) is
     synchronous reset(rst)
         q <= '0';
     begin
         q <= d;
     end process;

With this, using the option 4 syntax allowing functions in sensitivity
lists:

     process (rising_edge(clk)) is
     begin
         if rst = '1' then
             q <= '0';
         else
             q <= d;
         end if;
     end process;

It is only marginally longer but IMO easier to read. And it avoids introducing the notions of "clock" and "reset" which are not currently part of VHDL as well lots of extra syntactic sugar.

The semantics should be easy to define in terms of the existing "wait until" statement. Similar to how the existing sensitivity list maps to "wait on".

It should also be easy for synthesis tools to implement as it is basically the same as Verilog's @(posedge clk).


Nick

-- 
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.