To handle the desired cases, the proposed syntax just gets too complex and cryptic to be that useful. Even with the proposed numeric phasing, how would you handle the reset condition of the implied phase? I'd rather see it coded in standard VHDL. It does not take that much code to accomplish the desired behavior. And it could be much more self-documenting. For example, most synthesizers will already handle the following: If rising_edge(clk) and enable(i) then -- NOT a gated clock! ... End if; 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 Brent Hayhoe Sent: Thursday, April 24, 2014 7:22 AM To: vhdl-200x@eda.org Subject: EXTERNAL: Re: [vhdl-200x] Multi-cycle Paths WAS: Clocked Shorthand Proposal Hi Jakko, Yes well spotted on the typo, it should be Falling _Edge in the process itself as well. Yes, the enable is a bit messy and confusing, which is why I suggested changing it to a phase integer indicating at elaboration time what phase to enable the sensitivity event on. so what I'm suggesting is: <signal>@<positive integer divisor><event function>[<positive phase integer>] This may give a better syntax for synthesis compilers. Yes, another problem with the enable is the need to generate a shift register control as you state, and this seems to complicate the whole issue requiring external (to the process) functional code. Hence why I suggested the enable control is replaced by a phase integer control. The main advantage as I see it is simpler coding style and the moving of the multi-cycle path control from the functional code into a compressed syntax within the sensitivity list. I'm not sure if that advantage is enough to warrant the quite involved changes required, but it seems worth discussing. Cheers, Brent. On 24/04/2014 08:23, Jakko Verhallen wrote: > > 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. > > > > > -- Regards, Brent Hayhoe. Aftonroy Limited Telephone: +44 (0)20-8449-1852 135 Lancaster Road, New Barnet, Mobile: +44 (0)79-6647-2574 Herts., EN4 8AJ, U.K. Email: Brent.Hayhoe@Aftonroy.com Registered Number: 1744190 England. Registered Office: 4th Floor, Imperial House, 15 Kingsway, London, WC2B 6UN, U.K. -- 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.Received on Thu Apr 24 15:08:04 2014
This archive was generated by hypermail 2.1.8 : Thu Apr 24 2014 - 15:10:05 PDT