Forum Discussion

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

Cyclone III Latch Not Latching

Hello all,

I have a peculiar problem. I have been tasked with solving a problem that affects some of our production units but not others (even though the FPGA part number and configuration are the same). The part number is EP3C40F780C6N.

The failure happens on about 30% of the units. I have tracked the failure down in the post fit technology map viewer to a latch that is not latching. It receives a 37ns pulse on the input, which should latch the output high. However, on the failing units, it only latches some of the time. I figured this out by running signal probe pins to the input and outputs of the latch and attaching a DSO.

Does anyone have any insight into why this might be happening? The pulse is generated from a 27mhz clock, which does not seem to be that fast.

I have attached a screen shot from the technology map viewer of the latch which I labeled with the corresponding colors of the scope snapshots that I also attached. scope_4 shows the incorrect behavior that happens most of the time and scope_5 shows the correct behavior.

Thanks for your help.

9 Replies

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

    Latches are asynchronous things and hence tricky.

    There might be a (even very) narrow glitch on the 'internal blue' signal that may not be seen at the corresponding pin. This however will reset the latch.

    Speed of the devices varies between batches and usually improves slightly as the manufacturer tunes the process continuously.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    My current goal is to figure out the root cause of the problem and then develop a solution. Would it be safe to say that it is caused by a glitch? Would you recommend reworking the HDL in such a way that a latch is not generated?

    Thanks!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    --- Quote Start ---

    Would it be safe to say that it is caused by a glitch?

    --- Quote End ---

    In my view, a pure guess can't be "safe" because it possibly blinds out the actual reason. I don't see an option for glitch generation in the present test case, I think the possibility of a real interfering signal (crosstalk, ground bounce) should be considered. Depending on the required timing, changing the storage function implementation can reduce the interference susceptibility.

    Avoiding latches is a good idea in most cases.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    --- Quote Start ---

    I would expect crosstalk of external signals to the# R input.

    --- Quote End ---

    --- Quote Start ---

    I think the possibility of a real interfering signal (crosstalk, ground bounce) should be considered

    --- Quote End ---

    The external signals are 'test-outputs'. I wouldn't expect these to inject crosstalk, or ground-bounce at the internal LUT?

    As I don't see that internal crosstalk or ground-bounce can be the cause, the most probable cause is a glitch on the internal blue signal. Unfortunately we don't see the circuitry feeding the blue signal.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    --- Quote Start ---

    My current goal is to figure out the root cause of the problem and then develop a solution. Would it be safe to say that it is caused by a glitch? Would you recommend reworking the HDL in such a way that a latch is not generated?

    Thanks!

    --- Quote End ---

    I wouldn't waste too much time trying to work out what's causing the problem, just accept it's something to do with how the latch is imlpemented.

    Best Solution. If you have a fast clock sample the input you're trying to latch, when you see it go high drive your output high, reset low with the reset input.

    Second Best Solution. Use the latch input as a clock to a register with the reset as the asynch reset, in VHDL...

    process(input, reset)

    begin

    if(reset = '1') then

    latch_out <= '0';

    elsif(rising_edge(input)) then

    latch_out <= '1';

    end if;

    end process;

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

    Thank you for the replies everyone, I am going to rework the logic.

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

    You should probably understand how TimeQuest times latches, and make sure that you are meeting timing on your circuit. By default, TimeQuest times latches as falling edge registers and checks setup and hold to the falling edge of the latch signal. You can change this behavior to have the latches timed as combinatorial logic (pass-through mode, which I think is what you want). In this mode, it will check the timing from the previous register t the following register through the latch. In order to do this, you much generate the timing netlist in TimeQuest differently with the command 'create_timing_netlist -no_latch' (by the way, this option is NOT in the GUI so you will have to type it at the console prompt, or do it by Tcl script).