[TimeQuest] Some asynchronous signals detected as clocks

Altera_Forum · ‎02-05-2015

Hello,

I am trying to make my first timing analysis with TimeQuest on a project which I have written for an exam at my university.

The project is a memory controller which incorporates the controller itself plus three instantiated RAMs, each provided with some glue logic and a couple of registers for I/O transactions on the shared data bus. From an external point of view the project is an entity with clock input, command/address inputs, exec, reset inputs and error and ready output signals (the data bus is internal and is not intended to be accessed from outside the controller).

The architecture of the memory controller includes counters, registers and combinational logic (MUXes, DEMUXes and a DECODER), plus a FSM which looks like having been synthesized with one-hot encoding. I have written the HDL code in order to load any internal register - including those I used for counters - when an asynchronous rising edge is provided to the CLK input of the register.

The problem is that TimeQuest recognizes these asynchronous load signals as clocks and cannot accomplish timing analysis. The weird thing is that only three among all those asynchronous load signals are recognized as clocks, whereas the other ones doesn't trigger any warning for TimeQuest. How can this happen? I've already tried to set false paths, but TimeQuest continues to consider those signal as clocks like if it would ignore the SDC command.

I would appreciate any suggestion and I thank you in advance.

Altera_Forum · ‎02-06-2015

Hi,

this often occures when you trigger a process with such signals. For example:


if (rising_edge(signal_load)) then
    {do something}
end if;

In this case quartus will always recognize "signal_load" as a clock because rising_edge is only meant to use clocks.

Check your design for edge detection on this signals and try to avoid the edge detection on asynchronous signals. For Example like this:


if (rising_edge(clock)) then
    signal_load_old <= signal_load;
    if ((signal_load_old = '0') and (signal_load = '1')) then
        {do something}
    end if;
end if;

This is only one method to catch the edges of a signal. There are sure some others (perhaps better).

Altera_Forum · ‎02-06-2015

--- Quote Start ---


if (rising_edge(clock)) then
    signal_load_old <= signal_load;
    if ((signal_load_old = '0') and (signal_load = '1')) then
        {do something}
    end if;
end if;

This is only one method to catch the edges of a signal. There are sure some others (perhaps better).

--- Quote End ---

Thank for your support.

I think I've got to the point. However I have not understood this method of catching edges. How can be signal_load_old and signal_load be different if before the 'if' statement there is a signal assignment between them?

Could another method of catching asynchronous edges be the following?


if (signal_load'event and signal_load = '1') then
   <do something>
end if;

Altera_Forum · ‎02-07-2015

--- Quote Start ---

Thank for your support.

I think I've got to the point. However I have not understood this method of catching edges. How can be signal_load_old and signal_load be different if before the 'if' statement there is a signal assignment between them?

--- Quote End ---

What you have to understand is that this is not procedural programming language. The code isn't executed line by line, it is synthesized into a logic circuit. The bit of code above doesn't assign signal_load_old = signal_load and then check if the two are different, it does both at the same time. Essentially it synthesizes to this circuit:

http://www.alteraforum.com/forum/attachment.php?attachmentid=10114&stc=1

Everything in the system is synchronous to the same clock edge, so {do something} will happen at the same time that signal_load_old is clocked in, so there is always an edge detected as shown in the timing diagram in the picture. (I've added some propagation delays in just to highlight better the way it works).

Altera_Forum · ‎02-07-2015

Ok, now I see clearly how this structure works. Thanks TCWORLD.

Meanwhile, I've changed my design, so now it uses those problematic registers with the main clock signal as their clock input and the asynchronous signal (the old asynchronous load) at the enable input. However, I've set these registers to work on the falling edge of the clock; this because the FSM changes state on the rising edge of the main clock and I considered some data delay for the enable signal (Moore output of FSM) to arrive at the registers. With this solution I managed to analyse the timing requirements on TimeQuest without unconstrained warnings for clocks.

Now I have strange results, that is a Launch-Latch clock relationship of 0 ns for the Hold Slack and a negative relationship of -5 ns for the Removal Slack. I'm guessing that TimeQuest isn't able to analyse a design where are both registers which work on the rising edge of the main clock and other ones which work on the falling edge, is this right?

Altera_Forum · ‎02-07-2015

don't sample on rising edge at one end and falling edge at other end. This will reduce setup relationship to half. apply same edge and don't worry about delays. That is the job of fitter , not the user.

Altera_Forum · ‎02-07-2015

--- Quote Start ---

don't sample on rising edge at one end and falling edge at other end. This will reduce setup relationship to half. apply same edge and don't worry about delays. That is the job of fitter , not the user.

--- Quote End ---

Ok, I've changed the design again. Now I have only rising edge-clocked registers in the entire design, which are loaded when the corrisponding enable signals are active.

The timing simulations are now consistent and the design also meets the timing requirements :)

The conclusions of this thread could be:

preferably use enabled registers instead of using an asynchronous load signal;
choose either a rising edge clock or a falling edge one for the design, then let the fitter do the job of avoiding race conditions.

Thank you all for your support.

Altera_Forum · ‎02-08-2015

--- Quote Start ---

Ok, I've changed the design again. Now I have only rising edge-clocked registers in the entire design, which are loaded when the corrisponding enable signals are active.

The timing simulations are now consistent and the design also meets the timing requirements :)

The conclusions of this thread could be:

preferably use enabled registers instead of using an asynchronous load signal;
choose either a rising edge clock or a falling edge one for the design, then let the fitter do the job of avoiding race conditions.

Thank you all for your support.

--- Quote End ---

number 2 conclusion is the normal practice. However, and this may have misled you, at i/o you are allowed to try and centre align latch clock with data eye. This will reduce setup relationship but is common practice to help an ailing fitter. Do you know why this difference is allowed? Just a short quiz for next week.