819 line standards convertor.

[pitbuell94]

Hi CMjones01

Originally Posted by cmjones01

Are vsync and mclk synchronized in this design? For example, is mclk generated by a PLL locked to the incoming video? If not, then your code leads to a race condition where the length of the vsync_reset pulse depends on the exact timing between the edges of vsync and mclk, which could be anything between a whole cycle of mclk and 0. This could mean that vsync_reset is unreliable.

If they are synchronised, and any jitter on vsync is small compared with the period of mclk, then you should have no problem.

VSYNC comes true the LM1881 => video from TV receiver (625 SECAM)

MCLK comes from internal crystal of my FPGA => 50MHz.

In fact, there is no PLL to lock the 50MHz with the VSYNC signal frequency.

You're right.

I should find an other way to solve this problem and use your design.

Thanks for the information.

I'm a newbee, so, sometine, problem happens

I'll try tomorrow to finish wiring of the hard part and to test my solution to see if it's a really nightmare.

I''l inform you of the result.

fred.

[ppppenguin]

The usual answer to this class of problem is the classic 2 flipflop synchroniser. This takes an incoming edge and synchronises it to a clock. The first FF is clocked by the async input and is cleared by the synchronised output.

process (SELECTED_REFERENCE_PULSE, CK) begin    -- First stage of synchroniser
    if SELECTED_TIMING_REF                         then PRE_SELECTED_TIMING_REF <= false;    -- Async clear
        elsif rising_edge(SELECTED_REFERENCE_PULSE) then PRE_SELECTED_TIMING_REF <= true;    -- Set
    end if; -- SELECTED_REFERENCE_PULSE, CK
end process;


process (CK) begin
    if rising_edge(CK) then
            SELECTED_TIMING_REF <= PRE_SELECTED_TIMING_REF;    -- 2nd stage of synchroniser
    end if; --CK
end process;

[cmjones01]

Originally Posted by ppppenguin

The usual answer to this class of problem is the classic 2 flipflop synchroniser. This takes an incoming edge and synchronises it to a clock. The first FF is clocked by the async input and is cleared by the synchronised output.

If my reading of the code is correct, that produces a 1-CK-wide pulse on each rising edge of SELECTED_REFERENCE_PULSE. Is that right? It's a lot neater than my belt-and-braces state machine!

[cmjones01]

Originally Posted by pitbuell94

I'll try tomorrow to finish wiring of the hard part and to test my solution to see if it's a really nightmare.

I''l inform you of the result.

I look forward to hearing how it goes - I really like to see new technology applied to solve vintage problems. Good luck!

[pitbuell94]

Hi PPPPenguin and CMjones01,

Thanks for all.

Today I'm fully busy like a FIFO, I think experiment 'll wait till monday.

Fred.

[ppppenguin]

Originally Posted by cmjones01

If my reading of the code is correct, that produces a 1-CK-wide pulse on each rising edge of SELECTED_REFERENCE_PULSE. Is that right? It's a lot neater than my belt-and-braces state machine!

Correct. It's a classic and well proven design. Like all such designs it has metastability problems but these are minimal in most applications. The whole business of metastability , dealing with async signals and crossing clock domain boundaries is complex. Here are just a few online references. There are many more.

http://en.wikipedia.org/wiki/Metasta...in_electronics
http://w2.cadence.com/whitepapers/cdc_wp.pdf
http://www.asic-world.com/tidbits/metastablity.html
http://klabs.org/richcontent/General...iderations.pdf
http://www.xilinx.com/support/docume...es/xapp094.pdf
http://www.fpga4fun.com/CrossClockDomain.html

The example I gave was copied from one of my own designs. Typically a pulse once per TV frame (usually 40ms) is used to reset the counters in a subsystem that is generating a TV waveform. I don't need exact sync in this application and it's actually impossible to achieve sync to better than 1 clock cycle because the reference is not synchronous to the clock. Also there is residual jitter of a few clock cycles on the reference pulse. This doesn't matter if you are using it to reset a line counter - one TV line is much longer than any possible jitter. It does to me since I am using it to reset the pixel counter too. I solve the jitter problem by using a window. After the first reset I suppress any further resets unless they happen more than N clock pulses from the nominal time. N is determined by experiment for best results.

[cmjones01]

Thank you, Jeffrey. That's really useful information. I can see how metastability can crop up in all sorts of places in the real world.

I can see why the synchroniser can't achieve sync better than 1 clock cycle, but why does a multiple-clock-cycle jitter remain? In my simple mental model, the jitter should limited to +/-1 clock cycle, assuming that the sync is as stable as the clock. Or is that the bogus assumption?

[ppppenguin]

The 2FF synchroniser has an inherent 1 cycle jitter. The problem in my application is that the incoming reference has a jitter that is several clock cycles. The V and F outputs of Fred's LM1881 sync separator will have significant jitter. If you are using this to synchronise a line counter then adding a clock enable like this will give agood results.

process (CK) begin
    if rising_edge(CK) then    
        if VERT_CE='1' then
            SELECTED_TIMING_REF <= PRE_SELECTED_TIMING_REF;    -- 2nd stage of synchroniser

        end if; --VERT_CE
    end if; --CK
end process;

The entire vertical counter system should run at pixel clock rate with a clock enable at line rate. As an example this is the central vertical counter from the same design. VERT_CE is approximately the same as the reset pulse for the horizontal count.

The general rule for good logic design, especially in FPGAs, is to use the minimum number of clock signals. This vertical counter example is simplified from the same design.

process (CK) begin
    if rising_edge(CK) then    
        if VERT_CE then    --These run with vertical CE

--Central vertical 11 bit counter. Up to 1125 lines
            if                                      VRESET then VCOUNT <= 0;                                                    -- Reset at terminal count
                else                                                  VCOUNT <= VCOUNT + 1 MOD 2048;
            end if;

        end if; -- VERT_CE
    end if; --CK
end process;

[cmjones01]

Originally Posted by ppppenguin

The 2FF synchroniser has an inherent 1 cycle jitter. The problem in my application is that the incoming reference has a jitter that is several clock cycles.

OK, that makes sense. It's the synchroniser's jitter plus the inevitable jitter from the analogue world.

The entire vertical counter system should run at pixel clock rate with a clock enable at line rate.

Thank you, that's a very helpful tip, to think in terms of clock enables rather than clocks. I can see how the resulting thought process tends to force the designer to think about synchronisation in appropriate places.

[ppppenguin]

Originally Posted by cmjones01

I can see how the resulting thought process tends to force the designer to think about synchronisation in appropriate places.

In the design I have quoted from I have taken the clock enables to an extreme. The design is for a digital test pattern generator. It needs to run on standard definition (13.5MHz pixel clock), high definition (74.25MHz pixel clock) and 3GHz standards such as 1080/50p (148.5MHz pixel clock). This is a simplification but is good for explaining what I do. The entire video side of the generator (not the control side or some other stuff) is clocked at 148.5MHz. I generate a CE signal which can be switched to:

1 cycle out of 11 for SD
1 cycle out of 2 for HD
Always enabled for 3GHz

There is also a strange lopsided 1of6/1of5 CE which I use for the SD audio embedder. I'm sure it's possible to design an SD audio embedder that will work at 13.5MHz but it's a bit brain warping. Easier to mux the Y and C streams together into this pseudo 27MHz signal, do the embedding and demux back to 13.5MHz. The pseudo 27MHz signals look horrible on the scope, makes it look like there's a severe jitter problem but it all works well.

[pitbuell94]

Hi PPPPenguin,

I meet some problem to transpose your desgin to my own design.

What are the signal => SELECTED_TIMING_REF and PRE_SELECTED_TIMING_REF ?

Are they the Set and reset signal of the DFF or the signal D and Q and Not Q?

Sorry, for maybee, this stupid question.

Fred.

process (Vsync, mclk) begin

if SELECTED_TIMING_REF then PRE_SELECTED_TIMING_REF <= false;
elsif rising_edge(vsync) then PRE_SELECTED_TIMING_REF <= true;

end if;

end process;


process (mclk) begin
if rising_edge(mclk) then

SELECTED_TIMING_REF <= PRE_SELECTED_TIMING_REF;
end if;
end process;

[ppppenguin]

Hope this makes it clear

[pitbuell94]

Hi PPPPenguin,

I'm really, really a stupig guy...

I don't know why, but soudainly, everything get clear

I'm really sorry to disturb you with this.

I found the solution.

process (vsync_inverse, vsync_reset, mclk) begin
if vsync_reset ='1' then
vsync_delayed <= '0';
elsif rising_edge(vsync_inverse) then
vsync_delayed <= '1';
end if;
end process;

process (mclk) begin
if rising_edge(mclk) then
vsync_reset <= vsync_delayed;
end if;
end process;

Thank.

Fred.

[pitbuell94]

Hi,

It's seem to be the same photo

fred.

[ppppenguin]

In your photo the D input of the 1st FF should be connected to logic "1". Not to the Q bar output.

[pitbuell94]

Hi PPPPenguin,

Is-it a problem if I connect D to Q bar?

Normally, Q bar is at '1' when a reset occurs

In fact, in the code, there is no D signal, I think all is OK., isn't-it?

Fred.

[ppppenguin]

The VHDL implies that the D input of the 1st FF is always at logic 1. I don't know what would happen if the Q bar output is connected to the D input.

[pitbuell94]

I don't know this rule.

Reading your differents code, I learn some trick.

Strange behaviour concerning ISE 13 comes yesterday.

Normaly, I'm using the ISE 11, but now, I'm using ISE 13.

Syntax is OK, but it don't want to create the bit file.

Do I choose a bad PIN on the board to receive the signal from the LM1881?

Is-there special location concerning the use of the IO pin ?

In the document I have, there no specification at all concerning these information.


ERROR:Place:1018: - A clock IOB / clock component pair have been found
that are not placed at an optimal clock IOB / clock site pair. The clock
component <VS_LM1881_BUFGP/BUFG> is placed at site <BUFGMUX_X1Y10>. The
IO component <VS_LM1881> is placed at site <PAD18>. This will not allow
the use of the fast path between the IO and the Clock buffer. If this
sub optimal condition is acceptable for this design, you may use the
CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message
to a WARNING and allow your design to continue. However, the use of this
override is highly discouraged as it may lead to very poor timing
results. It is recommended that this error condition be corrected in the
design. A list of all the COMP.PINs used in this clock placement rule is
listed below. These examples can be used directly in the .ucf file to
override this clock rule. < NET "VS_LM1881" CLOCK_DEDICATED_ROUTE =
FALSE; >


I try today to mix all my differents design in a single one.

Have a good day.

Fred.

[ppppenguin]

Originally Posted by pitbuell94

ERROR:Place:1018: - A clock IOB / clock component pair have been found
that are not placed at an optimal clock IOB / clock site pair. The clock
component <VS_LM1881_BUFGP/BUFG> is placed at site <BUFGMUX_X1Y10>. The
IO component <VS_LM1881> is placed at site <PAD18>. This will not allow
the use of the fast path between the IO and the Clock buffer. If this
sub optimal condition is acceptable for this design, you may use the
CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message
to a WARNING and allow your design to continue. However, the use of this
override is highly discouraged as it may lead to very poor timing
results. It is recommended that this error condition be corrected in the
design. A list of all the COMP.PINs used in this clock placement rule is
listed below. These examples can be used directly in the .ucf file to
override this clock rule. < NET "VS_LM1881" CLOCK_DEDICATED_ROUTE =
FALSE; >

If a signal feeds clock inputs of FFs the software attempts to allocate a BUFG to that signal. This minimises clock skew when driving many clock inputs. In this case you are driving only 1 clock input so a BUFG is not needed. Add the suggested constraint NET "VS_LM1881" CLOCK_DEDICATED_ROUTE =
FALSE; to the UCF file

In more complex dsigns with several clocks, each of which drives a large number of inputs, it is often necessary to explicitly instantiate each BUFG and LOC it to a specific location.

[pitbuell94]

All Run now

I'm going to optimize the code.

There is some others small warning.

Fred.