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

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.