On 03/04/2014 20:00, Jones, Andy D wrote: > 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): Unfortunately we have to face up to the fact that the EDA industry is not the greatest VHDL fan. This is not their fault, if you get 80% of your revenue from 20% of your customers (meaning SV/ASIC users) then obviously that is were you spend your R&D money. We cannot submit a "SV size" new VHDL standard to EDA vendors and expect them to implement it. We also don't want to confuse users with multiple ways of coding up something. So we have to make sure that the next standard is as lean and mean as possible and only fixes issues which can't be solved with the current language constructs, a package of some form of preprocessing (like 64bits naturals). Regards, Hans. > > 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.Received on Mon Apr 7 03:57:45 2014
This archive was generated by hypermail 2.1.8 : Mon Apr 07 2014 - 03:58:21 PDT