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.Received on Thu Apr 24 05:21:57 2014
This archive was generated by hypermail 2.1.8 : Thu Apr 24 2014 - 05:22:31 PDT