Cyclone III counter problem

[Altera_Forum]

Hi all, 

I seem to have a problem with a counter implementation in Cyclone III. The code is attached below. Bascially, it should generate '1' for 1 clk cycle on parallel_load2 whenever the CNT is 0 and the CNT is counting on the rising edge of clkin. iLocked is a signal generated by other process as a reset signal for the counter. For now, iLocked been assigned a constant value of '0'.  ----------------------------------------------------------------------------------------------------------------------------- -- Free Running CNT signal CNT : integer range 511 downto 0 := 0;  FreeRunning : process (iLocked, clkin)  begin  if (iLocked = '1') then  CNT <= 0;  parallel_load2 <= '0';  elsif rising_edge (clkin) then  CNT <= CNT + 1;  if CNT = 0 then  parallel_load2 <= '1';  else  parallel_load2 <= '0';  end if;  end if;  end process; -----------------------------------------------------------------------------------------------------------------------------  For timing constraints, I have the following statement in the .sdc file:  create_clock -name ClientRxRClk -period 488.281 [get_ports {ClientRxRClk}]  Problem: The counter is defined up to 511, therefore, I do not have a statement to reset the CNT to 0. The problem is that when implemented in hardware, this CNT has some random behavior. It supposed to update on the rising edge of clkin, but sometimes, it updates randomly (on the falling edge). As illustrated in the picture attached here. This picture is taken from SignalTap II which probes the signal inside the Cyclone III chip. In the picture, ClientRxRClk is from an external chip and it is connect to the clkin port here. As shown here, the counter value was updated from 241 to 242 on the falling edge of ClientRxRClk. I was thinking maybe there's glitch from my external clock ClientRxRClk, but signalTap II doesn't show this. Can anyone help? Thanks  https://www.alteraforum.com/forum/attachment.php?attachmentid=7970

[Altera_Forum]

I am suspecting that the RxRClk signal from the external chip might not be as clean as it should be. Therefore, it might have some ringing on the fall edge creating the FPGA to update twice. Is there a way to prove this theory? if this is the case, what can I do? I know about debuncing circuit for switch, but never heard of clock signal needs to be debunked.

[Altera_Forum]

--- Quote Start ---  As shown here, the counter value was updated from 241 to 242 on the falling edge of ClientRxRClk. I was thinking maybe there's glitch from my external clock ClientRxRClk, but signalTap II doesn't show this.  --- Quote End ---   SignalTap acquisition clock frequency is too low to reliably show glitches.  Ringing clock edge sounds quite plausible. Usually source side impedance matching will remove ringing.

[Altera_Forum]

FvM, thanks for the reply. I probed the signal, it's actually quite clean, no ringing on the edges. I am wondering if my clock is too slow for the FPGA. So are you aware if there's a minimum frequency requirement for the clock signal for Cyclone III devices? I know there's requirement for the input clock for PLLs; but here, the RxRClk from the external chip is used directly as the clock source for the counter and this clock is only running at 2.048MHz. The risetime / falltime on the scope is typically in the 10~12ns range. I can't seem to find relevant information on minimum frequency requirement from Altera's own literature.  

Thanks