FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5884 Discussions

LPM Counter Output Resetting To Wrong Value

Altera_Forum
Honored Contributor II
1,223 Views

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
0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
99 Views

 

--- 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
Honored Contributor II
99 Views

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
Honored Contributor II
99 Views

 

--- 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
Honored Contributor II
99 Views

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
Reply