0

I'm using ISE Project Navigator 14.7 with a Xilinx XC95144XL-5TQ100C CPLD in conjunction with a LM1881 video sync separator. I've also got a 14.3 MHz clock. I'm trying to generate VSYNC pulses in response to the LM1881 FIELD line changing (and yes, I know the LM1881 also has a VSYNC output; but I'm constrained due to the PCB I'm using which only allows me to view FIELD).

Here is the code I am using to generate the VSYNC signal (I tried to remove non-relevant parts):

library IEEE;

use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity outputGenFromLm1881 is

    Port ( clock14_3 : in  STD_LOGIC;
              lm1881Field : in  STD_LOGIC;
              vsync2_prime : out  STD_LOGIC);

end outputGenFromLm1881;

architecture Behavioral of outputGenFromLm1881 is

    constant cyclesPerVsync : natural := 238875;
    constant cyclesPerHalfLine : natural := 455;
    constant cyclesPerLine : natural := cyclesPerHalfLine*2;
    constant cyclesPerVsync2Pulse : natural := ((cyclesPerLine * 11)/2);

    -- we need 18 bits for range of vsync plus an extra bit to detect/prevent wrapping back to 0

    signal iVsync2Count : std_logic_vector(18 downto 0) := (others => '0');
    signal fieldOld : std_logic := '0';

begin

vsync2_prime <= '0' when (unsigned(iVsync2Count) < cyclesPerVsync2Pulse) else '1';

lm1881FieldThink: process(clock14_3)

begin

    if (rising_edge(clock14_3)) then

        -- if field has changed
        if (lm1881Field /= fieldOld) then           

            iVsync2Count <= (others => '0');
            fieldOld <= not fieldOld;

        -- we never want to wraparound back to 0 unintentionally
        elsif (iVsync2Count(18) = '0') then

            iVsync2Count <= std_logic_vector(unsigned(iVsync2Count) + 1);           

        end if;

    end if;

end process lm1881FieldThink;

Most of the time it behaves correctly as shown here: Text

But occasionally, the counter never resets even though fieldOld is getting changed properly.

Text

There's nothing else that modifies iVsync2Count except this process so I'm thinking somehow the section of the process that increments iVsync2Count is taking precedence over the reset. The trouble is I can't see how this is possible or how to fix it.

Can anyone explain why iVsync2Count sometimes does not get properly reset?

  • The diagrams are not from a simulation, but traced from real hardware? Have you synchronized lm1881Field to clock14_3? – Matthias Schweikart Mar 22 '23 at 17:27
  • Yes, this is real hardware. I thought that what I was doing in my process was good enough to synchronize but apparently this is where I'm going wrong. I'm not sure how to synchronize lm1881Field to clock14_3 (but I've taken a stab at it in my response to Dave Tweed). – Matt Ownby Mar 22 '23 at 20:07
  • @MattOwnby Can you ask a specific question – Voltage Spike Mar 22 '23 at 21:10

1 Answers1

1

You're using lm1881Field as an input to your state machine. I'm guessing that this input is not synchronized to your 14.3 MHz clock.

In the state machine, this input affects 20 different state bits — 19 in your counter iVsync2Count, plus fieldOld. Each of those bits has logic associated with it that determines that bit's next state. Each of those pieces of logic has a different delay (from the asynchronous input) associated with it.

So, if that input changes state at a "random" time with respect to the clock, there's a chance that some of the bits will see the change, and some will not. This leaves you in an inconsistent state.

This is why all inputs to state machines must be properly synchronized to the state machine clock.

Dave Tweed
  • 168,369
  • 17
  • 228
  • 393
  • So does that mean I would add a flip-flop that is triggered by the clock and the D input would be the random lm1881 field? or is there a cleaner way to accomplish that. (Thanks for the reply!!!) – Matt Ownby Mar 22 '23 at 20:06
  • UPDATE: Found this thread that explains it in detail: https://electronics.stackexchange.com/questions/79821/vhdl-receive-module-randomly-fails-when-counting-bits/79830#79830 (I'm sure Dave Tweed is getting tired of answering the same question but I'm very grateful!) – Matt Ownby Mar 22 '23 at 22:25