I would agree that if the new code becomes either too cryptic or complex then it is self defeating in its purpose. However, a certain amount of 'crypticity' (I'm inventing new words here in a Bush'ism way) can be useful in identifying design intent at a higher level. How many of us look at a process sensitivity list and seeing (clk, rst) identify a clocked process and look within the code for details of edge and reset structure. What I am proposing is a syntax which is not just for generating a short hand method of coding, but something that can convey design intent quicker. Whilst I agree that coding in standard VHDL as you say, is often more convenient for the designer, it can be difficult to identify multi-cycle coding for the unfortunate soul that has to maintain said code some years later. Your point about reset conditions is well taken and opens up some more problems/solutions. Working mainly in the FPGA arena these days, asynchronous resets generally come for free. However there is still a need to synchronize the deactivating edge on a clock domain basis and I use instantiated reset synchronization blocks for this purpose. So how to accommodated these? for i in 1 to 3 generate rst_sync_inst : rst_sync port map( arst => sys_rst, d_clk => domain_clk@3re[i], d_rst => domain_rst ); process(domain_clk@3re[i], domain_rst) is ... begin ... end process; end generate; This provides a solution to controlling resets, but the addition of sensitivity control onto a port mapping syntax is a debatable subject! Brent. On 24/04/2014 23:06, Jones, Andy D wrote: > 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. -- 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 Fri May 30 02:34:38 2014
This archive was generated by hypermail 2.1.8 : Fri May 30 2014 - 02:34:39 PDT