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. 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 Wed Apr 23 15:06:51 2014
This archive was generated by hypermail 2.1.8 : Wed Apr 23 2014 - 15:07:07 PDT