Hi Brent, Does the generate example contain a typo? You use 'fe' in the sensitivity list, but use rising_edge(clk). This syntax is not clear to me, if you have the enable signal, is it only considered at the first active edge? Or during all 3? Or only the last? Seems that you want to describe a shift register (which can be retimed with a synthesis tool?) The only gain with the new syntax is that you don't need to declare an array of the delayed signal. signal stack : array (0 to 2) of std_logic_vector(7 downto 0); ... stack(0) <= new_value; stack(1 to stack'high) <= stack(0 to stack'high-1); This does the same thing in current VHDL I believe? Jakko -----Original Message----- From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Brent Hayhoe Sent: Thursday, April 24, 2014 8:34 AM To: vhdl-200x@eda.org Subject: Re: [vhdl-200x] Multi-cycle Paths WAS: Clocked Shorthand Proposal Hi David, I agree with you which is why I included the Boolean enable function. The generate block uses this to enable each of the three generated processes at each of the three phases. The enable_vector would be enabled in a shift register manner post reset. However, this niggles me as it implies generated logic outside of the process. If we replaced the enable with a phase variable, which could be an implicitly defined positive (or natural) integer type with a range 1 (or 0) to the sensitivity divisor, 3 in this case (or 3-1 in the case of a natural type). This will infer the phase to enable the sensitivity on and could entirely be handled at elaboration time and not rely on run-time initializations. For synthesis operations this would imply the generation of phased clock enables for the processes. With regard to the event type; this was the reason for including the 're' function. We would be able to generate our own versions, 'fe' - falling edges, 'be' - both edges, etc. I think we would only need the new system defined 'event' sensitivity type, in order to give the ability to define the function: function "fe" (clk : std_ulogic) is return event begin if falling_edge(clk) then return active; else return inactive; end if; end function "fe"; This gives a new generate option as: for i in 1 to 3 generate process(clk@3fe[i], rst) is ... begin if (rst = '1') then ... elsif rising_edge(clk) ... end if; end process; end generate; Regards, Brent. On 24/04/2014 02:28, David Schetz wrote: > I think that it's not enough to just specify how often to activate the > process on the clock edge, but also which phase. If I had two > processes, each active only on every-other rising edge of the same > clock, I think it would be necessary to specify whether the two > processes are active on the same rising edge, or opposite rising > edges. Not disallowing a mix of rising and falling edges would be nice, too. > > In my heart, I guess I'd still rather generate my own clock enable > signal, and make it very clear what is happening, using current > syntax. If I felt it were too long-winded, I'd wrap it up in a component. > > > On Wed, Apr 23, 2014 at 6:06 PM, Brent Hayhoe > <Brent.Hayhoe@aftonroy.com <mailto:Brent.Hayhoe@aftonroy.com<mailto:Brent.Hayhoe@aftonroy.com%20%3cmailto:Brent.Hayhoe@aftonroy.com>>> wrote: > > > I must admit that I was and still am slightly confused by the Clocked > Shorthand Proposal. Like many others, I think the proposed syntax(es) seem > ugly and in some cases downright wrong (functional code in declarative > regions). > > However I think the need to specify and control multi-cycle path designs > at the RTL is difficult at present and could do with some improvement. If > I understand the proposal correctly, multi-cycle path generation is the > main problem that we are trying to address, rather than just pure pipe-lining. > > So as normal it got me thinking; what we need that is lacking, is more > functionality in controlling sensitivity lists. Ignoring the use of > concurrent signal assignments (at least for the present) and concentrating > on the well established clocked process approach, we need the ability of > setting when a process is triggered by its sensitivity list. > > So given a standard clocked process: > > process(clk@3, rst) is > ... > begin > if (rst = 1) then > ... > elsif rising_edge(clk) > ... > end if; > end process; > > Indicating that the clock sensitivity should occur every three times is > not enough to define what is required, as it is it could react every three > events or worse every three transactions. > > We need a method of defining a function to specify what type of event to > react to: > > process(clk@3re[enable], rst) is > ... > begin > if (rst = 1) then > ... > elsif rising_edge(clk) > ... > end if; > end process; > > The 're' would be a new type of function returning a new system defined > type based on events or transactions. So the code above would activate the > process on every third rising edge. The 'clk' signal would be an input to > the function such that this function will generate events for the > STD_uLOGIC type, but sensitivity functions could be generated for other > input types. It will require a new return type(s), e.g; > > type event is ( > active, > inactive); > > type transaction is ( > active, > inactive); > > in order to define the functions. > > The 'enable' is a Boolean control, perhaps a shared variable, to enable > the new function. If not enabled the 'clk' in the sensitivity activates > the process on any and all events. This will give a synchronization method > to offset processes in a generate loop: > > for i in 1 to 3 generate > process(clk@3re[enable_vector(i)], rst) is > ... > begin > if (rst = 1) then > ... > elsif rising_edge(clk) > ... > end if; > end process; > end generate; > > The enable is replaced by a Boolean vector, enabling the generate loop to > build three multi-cycle processes offset from one another by one clock period. > > These are some very rough thoughts, but possible have the germ of an idea > to solve this problem. > > What do people think? > > -- > > Regards, > > Brent Hayhoe. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please consider the environment before printing this e-mail -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Apr 24 00:23:44 2014
This archive was generated by hypermail 2.1.8 : Thu Apr 24 2014 - 00:24:01 PDT