using clock enable

[rudy]

Hi, 

I have a state machine (with about 12 states), and there is an enable signal, that actually is used inside any else/if statement inside each one of those states. So, there is a huge fanout on the signal, and I am trying to use dedicated clock enable path for the flip/flops in my state-machines.

I would think that the the tool will be able to infer the clock enables and tie my enable signal to each one of the clock enables. However, when I opened up the placed and routed design in Vivado, I noticed that only some of registers is using the clock enable path, and for a good porition of the flip/flops in my state machine, the enable signal is actually being used in some LUTs, which is untimately driving the "D" pin of the flip/flop, rather than the clock-enable pin!!!

I was wondering, firstly, if there is any advantage to use the clock-enable pin rather than the "D" pin ?

Second, if there is an advantage, how could I make the tool use the clock-enable pin, rather than the "D" pin? Is such a thing possible to do? If it is possible, is this a good design practice?

Thanks,

--Rudy  

[eilert]

Hi Rudy,

you mentioned that CE is "used inside any else/if statement inside each one of those states".

Why that?

How did you code it?

If you have a synchronous process all you need to do is to write one if..then condition like this:

process (reset,clock) is

begin

  if reset = '1' then

    -- initialize regs

 elsif rising_edge(clock) then

   if CE='1' then

     - do some usefull stuff here

   end if;

 end if;

end process;

This way all FFs should use the CE-Input and it just needs two lines of code.

In your case, I suspect, CE is mixed up other signals/variables which are used in the datapath, therefore it goes into the LUTs

(Even the case selector for the states will cause this if you have CE mentioned in all states.)

Have a nice synthesis

  Eilert

[rudy]

Hi Eilert, 

You are absolutely right. That is exactly how I coded it, and I have bunch of mixed signals in there too. something like this:

process (reset,clock) is

begin

  if reset = '1' then

    -- initialize regs

 elsif rising_edge(clock) then

   if (CE='1' and A='1') then

     - do some usefull stuff here #1

   end if;

   if (CE='1' and B='0') then

     - do some usefull stuff here #2

   end if;

   -- I have at least 40 of this else/if

   if (CE='1' and B='1' and F='1') then

     - do some usefull stuff here #40

   end if;

 end if;

end process;

But, signal "CE" is the signal that is common for every single register. But since I have bunch of else/if statements (in the example above about 40), and imagine in the above exapmle, signals A,B,F are all 32 bit. 

You can see that signal 'CE" could potentially have hundereds of loads. And in theroy, there is no reason that I cannot speperate singal "CE" from reset of the signals, and tie "CE" signal to the clock enable. 

I think it will even be a better practice if we do it this way, but as I said, once I opened the implmented desgin, and look at the schematic, I saw most of my registers have their "CE" pins unused !!!

So, I thought the tool, would be able to recognize that since "CE" is common to all register, it can draw it out of LUTs and tie it to straight the "CE" pin !

And I was wondering if there is anyway to acheive this?

If indeed this is the better practice, can I somehow (with some manual effort), make sure it can be synthesized this way?

Thanks, 

--Rudy 

[eilert]

Hi Rudy,

computer tools have no idea of "all", "many" or "few".

Each signal means the same to them.

So if you write something like

 do sth. if this and this and this happens

the tool elaborates the logic needed for the condition to do what is required.

If one of these conditional signals is meant to be a CE, how should the tool know.

Another thing is the timing issue.

Not only data inputs, but also CE has to be stable before the setup/hold time of the FF.

If the CE-input is driven by some complex logic (as you mentioned the other signals are 32 bit vectors) the routing delay from that logic to the CE-input will be much longer, than having your intended CE absorbed in the logic that drives the data path, because that just uses the fixed connection inside the Slice.

A common CE signal for a lot of FFs should be generated synchronously and driven by one or more FFs direcly without any logic in between.

Have a nice synthesis

  Eilert

[bassman59]

---

@rudy wrote:

I would think that the the tool will be able to infer the clock enables and tie my enable signal to each one of the clock enables. However, when I opened up the placed and routed design in Vivado, I noticed that only some of registers is using the clock enable path, and for a good porition of the flip/flops in my state machine, the enable signal is actually being used in some LUTs, which is untimately driving the "D" pin of the flip/flop, rather than the clock-enable pin!!!

I was wondering, firstly, if there is any advantage to use the clock-enable pin rather than the "D" pin ?

Second, if there is an advantage, how could I make the tool use the clock-enable pin, rather than the "D" pin? Is such a thing possible to do? If it is possible, is this a good design practice?

---

In general, the synthesizer will do what is "Best." Even if it seems like using the CE input is "best," the tools may not agree.

What I do is this: synthesize the design and run in through the place and route with the correct timing constraints. If it fits and meets timing, I am done. I don't care if there is a "better" solution. 

[avrumw]

I agree with everything said so far.

One point, though - your coding style definitely isn't helping the synthesis tool infer CE's. You are hoping that the tool will notice the common (CE = '1') in all the clauses of the if/elsif and use that as a chip enable. It might (or might not) make a difference if you coded it with the CE clause in its own if statement, and the rest of the cases within that (please forgive my VHDL...). Its also cleaner and easier to read...

process (reset,clock) is
begin
  if reset = '1' then
    -- initialize regs
 elsif rising_edge(clock) then
   if (CE= '1') then -- this tells the tool that all the following FFs' are enabled
     if ( A='1') then
       - do some usefull stuff here #1
     end if;
     if (B='0') then
       - do some usefull stuff here #2
     end if;
     -- I have at least 40 of this else/if
     if (B='1' and F='1') then
       - do some usefull stuff here #40
     end if;
   end if;
 end if;

end process;

Avrum

[filgiorgi]

If it can help someone looking at this old post for the same reason...

I noticed some differences in the CE inference of the vivado synthesis tool depending on the datapath of D.

If D is fed by combinatorial logic depending on Q of the same flop (loopback logic), then CE is never connected to the enable signal of the process. The process enable logic is mixed in the LUT along with other combinatorial logic.

Otherwise, if D datapath comes from others flops, the enable signal is correctly assigned to the CE pin of the flop.

Example 1 of CE *NOT* driven by "ena" signal:

if rising_edge(clk) then
   if ena='1' then
      dout(15 downto 0) <= din(14 downto 0) & (din(14) xor dout(0));
   end if;
end if;

Example 2 of CE *NOT* driven by "ena" signal:

if rising_edge(clk) then
   if ena='1' then
      dout <= not dout;
   end if;
end if;

It is not evident to me why, but after some trials seemed to work so.