1
\$\begingroup\$

I have a question regarding setting timing constraints on enable signals.

In my vhdl design I use an enable signal, to gate when the process needs to sample my input data. The enable signal is derived from the input data, using another vhdl component.

My clk is 27MHz, but the enable signal is maximum present at every 2nd cycle, so its period is minimum: 1/13.5MHz.

When I compile my design, I get warnings on the clk timing constraints, due to my algorithm. But can I make some timing constraint on the enable pin, this could probably make the vhdl code compile without warnings, by effectively only requiring half of the clk period.

test : process(reset, clk)
begin
  if reset = '0' then
     ... 
  elsif rising_edge(clk) then
    if en = '1' then
      ... vhdl algorithm is here ...
    end if;
  end if;
end process;
\$\endgroup\$
4
  • 1
    \$\begingroup\$ What exactly are the warning messages? Do they refer to the enable signal? Also, is the enable signal synchronous with the clock but aperiodic or is it truly asynchronous? \$\endgroup\$
    – Joe Hass
    Commented Jan 10, 2014 at 11:30
  • \$\begingroup\$ I'm just getting warning that my timing is not kept, negative slack. Yes, the enable signal is synchronous to the clock, but a periodic. \$\endgroup\$
    – JakobJ
    Commented Jan 10, 2014 at 11:44
  • 1
    \$\begingroup\$ I don't believe you. The tools will tell you which signals are causing the problems but we need to see the exact warnings if we are to help you. \$\endgroup\$
    – Joe Hass
    Commented Jan 10, 2014 at 11:49
  • \$\begingroup\$ I solved the problem in question by rewriting some of the vhdl for the algorithm, the path was too long, causing negative slack. But this would maybe not be an issue, if tool knew about the enable pin. So what I want to know, is how do you tell the compiler, eg. set a constraint, on an enable pin ? \$\endgroup\$
    – JakobJ
    Commented Jan 10, 2014 at 13:01

1 Answer 1

2
\$\begingroup\$

If you can guarantee that your enable will never be present faster than a particular rate, you can use a multi-cycle path constraint to tell the tools this. You don't say which FPGA family you are using, but searching the vendors helpfiles for multi-cycle should get you the information you need.

Having said that, in my experience these constraints are hard to verify. Checking that only the right logic is covered by them is hard, and if some additional logic gets included by accident, the design has a latent timing violation that is unknown to the designer.

So unless I have no other choice, I tend to aim for clock-speed improvement (for example using a better synthesiser, or pipelining, or..). Then I can run that logic at full speed, even though I don't have to, and I don't have to worry about validating complex multi-cycle path constraints.

\$\endgroup\$
1
  • \$\begingroup\$ Thank you so very much, I now know what to do and what to watch for. \$\endgroup\$
    – JakobJ
    Commented Jan 10, 2014 at 17:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.