Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

Ripple clock caused by State Machines

Hi,

I'm trying to make a project, so I have 6 state machines which are related/cascaded. I have 3 state machines layers and a clock flow over those state machines as follows:

Layer 1: FSM_1........FMS_2

................|.................|

Layer 2: FSM_3........FMS_4

................|.................|

Layer 3: FSM_5<==>FMS_6

................|.................|

OBS: Do not consider any "." it was put just to help show the design schema.

FSM1/2 have four states:

type state_type is (init, wait, processData, sendData);

FSM3/4 have three states:

type state_type is (init, wait, sendCompResult);

FSM5 have five states:

type state_type is (initState, waitState, faultState, dispState, failState);

FSM6 have six states:

type state_type is (initState, inativeState, waitState, faultState, dispState, failState);

The changing of state in FSM3/4 occurs when FSM1/2 send a signal to those FSMs (FSM1 => FSM3 and FSM2 => FSM4). Then, this makes the following warnings appears, thus the circuit don't works as it should do.

Warning: Found 2 node(s) in clock paths which may be acting as ripple and/or gated clocks -- node(s) analyzed as buffer(s) resulting in clock skew

Info: Detected ripple clock "Layer2: DetecMaster|ControlUnityDetection:U01|pr_state. sendCompResult" as buffer

Info: Detected ripple clock "Layer1:AplicMaster|Processor:Proc_01|ControlUnityProcessor:U01|at_state.processData" as buffer

I have been trying hardly to solve this problem. I've look in many forums, but I didn't find a solution. How could I fix this problem? Should I use a derived clock? If yes, how can I assign one? I've been use a PLL as a clock... maybe the problem is related to some global clock, isn't it? I don't know what to do :(

Best regards,

Higor

13 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Ok guys,

    tnx for help me. I'll try to find out a little more.

    FvM:

    Maybe it didn't appear because there is an other logic part (the other FSM) that is dependent of this first one (when I say dependent means a situation quite similar to this that I showed. There is other FSM which is "activated" by a signal from the second FSM showed in code). Anyway, I appreciate your help. Unfortunately, I can't show more code than I've already showed.

    alt1000:

    The tips was very good, thank you too. But I've already did those things.

    Look, I understand that even only one clock domain can cause a little delay comparing bigger path and littler path, can't it? So I think to myself that this could be the issue for my design. On the other hand, this other logic part isn't too bigger than those first ones. So... if those parts of my logic don't cause ripple clock action, why an other similar logic do it?

    my best,

    higor
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Ripple clock means that a register output signal, e.g. any of the state variables or triggers from the state machines is feed to a register clock input. In VHDL, this is done by an edge sensitive expression e.g. (signal'EVENT AND signal='1') resepectively rising_edge(signal).

    As said by all contributors, this should be strictly avoided in a synchronous design. I think, the problematic location in your code should be easily detectable by tracing the signals mentioned in the Quartus warning.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Ripple clock means that a register output signal, e.g. any of the state variables or triggers from the state machines is feed to a register clock input. In VHDL, this is done by an edge sensitive expression e.g. (signal'EVENT AND signal='1') resepectively rising_edge(signal).

    As said by all contributors, this should be strictly avoided in a synchronous design. I think, the problematic location in your code should be easily detectable by tracing the signals mentioned in the Quartus warning.

    --- Quote End ---

    Mr. FvM,

    How can I trace those signals in the Quartus?

    I'm trying again to solve this problem.

    Thank you,

    higor