Re: [vhdl-200x] Multi-cycle Paths WAS: Clocked Shorthand Proposal

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>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.
>
> 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.