Forum Discussion

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

Cyclone III counter problem

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

3 Replies

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

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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