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

From: Brent Hayhoe <Brent.Hayhoe@Aftonroy.com>
Date: Thu Apr 24 2014 - 05:21:32 PDT
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