Forum Discussion

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

False triggering on dff?

I am using a Cyclone III starter kit with Quartus II v8.1 web edition. I am using library components to make a "one shot" with variable delay times in the msec range. There does not appear to be any library items that will do this function? My problem is that within this circuit the output of a lpm_compare "aeb" goes to a clock input of a dff. I have several of these in the design but one or two always trigger early. I put outputs on all areas of the circuit to monitor them with a scope and the clock is low for the required delay but the dff output changes state before it should? Other identical circuits operate normally? The D and PRN inputs are tied to Vcc and the CLRN input is (high) not active when this occurs. Has anyone seen this before? Of course it simulates fine with functional simulation. I have only been using the kit and software for a couple months so definitely a newbie. bdf diagram attached in pdf form. THANKS

6 Replies

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

    --- Quote Start ---

    Of course it simulates fine with functional simulation.

    --- Quote End ---

    Yes. But a timing simulation most likely immediately reveals the design flaws. You'll realize, that both comparator outputs have glitches, that can trigger the DFF before reaching the equal count. You can either resync the comparator outputs by another DFF to the respective counter input clocks or use a preset down counter instead.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    I would change the design to not clock the dff with a combinatorial signal. Register your aeb output and use the registered version to clock your flip flop. If that's not acceptable, you need to implement some sort of glitch-suppression (like maybe a gray encoder).

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

    FvM thanks for your prompt reply

    Are you saying that a timing simulation will show glitches in the "aeb" output of the lpm_compare megafunction?

    (1) Do you mean to connect the aeb output to the D input on the ff and then clock that ff with the same clock the counter uses and use the Q output to clock the original dff?

    (2)I need to be able to vary the count value that's why I used a constant. Will a preset down counter allow me to change the value like a constant? Is it in the library? The down counter does not have glitches?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    1) Yes. That's the same as jakobjones suggested with registering the comparator output.

    2) It's in the library, because it's just another configuration variant of the lpm_counter MegaFunction. I meant to use the carry output. However, thinking about my suggestion, I realized, that carry is basically a combinational output, that can have glitches too. So you should better use the registered variant. You may need to adjust the compare value, because the DFF output is delayed by one clock.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    FvM thanks to you and Jacob I really appreciate your assistance and extra effort. _Dave