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

From: Brent Hayhoe <Brent.Hayhoe@Aftonroy.com>
Date: Wed Apr 23 2014 - 15:06:39 PDT
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