LPM Counter Output Resetting To Wrong Value

[Altera_Forum]

Hello, 

 I am using the lpm_counter Megafunction and I am observing incorrect behavior at the counter Q output on 20% of the FPGA design builds.  In all the builds that fail, the counter output q[16] is an incorrect value of 1 after the sclr input port is released from reset when it should always be a value of 0 (like in the good builds).  The counter ports used are clk, sclr, sload, data, cnt_en, and q.  The sload counter input port is always a value of 0 in both the good state and failed state according to the logic analyzer.  All the ports are inside the same clock domain clk80. The output failed state occurs even when there are no timing violations on the clk80 clock domain.  I would really appreciate any suggests about how to fix this unexpected intermittent counter behavior.  Thanks! John

[Altera_Forum]

--- Quote Start ---  Hello,  I am using the lpm_counter Megafunction and I am observing incorrect behavior at the counter Q output on 20% of the FPGA design builds.  In all the builds that fail, the counter output q[16] is an incorrect value of 1 after the sclr input port is released from reset when it should always be a value of 0 (like in the good builds).  The counter ports used are clk, sclr, sload, data, cnt_en, and q.  The sload counter input port is always a value of 0 in both the good state and failed state according to the logic analyzer.  All the ports are inside the same clock domain clk80. The output failed state occurs even when there are no timing violations on the clk80 clock domain.  I would really appreciate any suggests about how to fix this unexpected intermittent counter behavior.  Thanks! John  --- Quote End ---    I can only think of sclr is asynchronous at origin. You can try register it first then apply it. Timing tool will otherwise ignore that path

[Altera_Forum]

Hi kaz, 

 The sclr is truly a synchronous clear. That signal is already registered with same clock that is used for the lpm counter clock input.  Thanks! John

[Altera_Forum]

--- Quote Start ---  Hi kaz,  The sclr is truly a synchronous clear. That signal is already registered with same clock that is used for the lpm counter clock input.  Thanks! John  --- Quote End ---    In that case I assume your observation is wrong as counters are last to be buggy. Try signaltap.  Or try infer a counter away from lpm and lower level tools.

[Altera_Forum]

I found the problem. It was a reset that was not constrained correctly to the counter clock. There was an exception constraint when there should not be one.  

 I changed to a reset input that had a correct timing constraint and the counter is now working reliably.  Thanks! John