3rd Nov 2011, 6:58 pm | #101 | |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi CMjones01
Quote:
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. Last edited by pitbuell94; 3rd Nov 2011 at 6:59 pm. Reason: finger go too fast... |
|
3rd Nov 2011, 9:47 pm | #102 |
Retired Dormant Member
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
|
Re: 819 line standards convertor.
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.
Code:
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; |
3rd Nov 2011, 10:26 pm | #103 |
Nonode
Join Date: Oct 2008
Location: Warsaw, Poland and Cambridge, UK
Posts: 2,678
|
Re: 819 line standards convertor.
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!
|
3rd Nov 2011, 10:28 pm | #104 |
Nonode
Join Date: Oct 2008
Location: Warsaw, Poland and Cambridge, UK
Posts: 2,678
|
Re: 819 line standards convertor.
I look forward to hearing how it goes - I really like to see new technology applied to solve vintage problems. Good luck!
|
4th Nov 2011, 7:46 am | #105 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi PPPPenguin and CMjones01,
Thanks for all. Today I'm fully busy like a FIFO, I think experiment 'll wait till monday. Fred. |
4th Nov 2011, 8:36 am | #106 | |
Retired Dormant Member
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
|
Re: 819 line standards convertor.
Quote:
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. Last edited by ppppenguin; 4th Nov 2011 at 8:44 am. |
|
4th Nov 2011, 9:20 am | #107 |
Nonode
Join Date: Oct 2008
Location: Warsaw, Poland and Cambridge, UK
Posts: 2,678
|
Re: 819 line standards convertor.
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? |
4th Nov 2011, 10:56 am | #108 |
Retired Dormant Member
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
|
Re: 819 line standards convertor.
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.
Code:
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 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. Code:
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; |
4th Nov 2011, 11:59 am | #109 | ||
Nonode
Join Date: Oct 2008
Location: Warsaw, Poland and Cambridge, UK
Posts: 2,678
|
Re: 819 line standards convertor.
Quote:
Quote:
|
||
4th Nov 2011, 12:57 pm | #110 | |
Retired Dormant Member
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
|
Re: 819 line standards convertor.
Quote:
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. |
|
4th Nov 2011, 3:11 pm | #111 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
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; |
4th Nov 2011, 3:59 pm | #112 |
Retired Dormant Member
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
|
Re: 819 line standards convertor.
Hope this makes it clear
|
4th Nov 2011, 4:08 pm | #113 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
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. |
4th Nov 2011, 4:14 pm | #114 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi,
It's seem to be the same photo fred. |
4th Nov 2011, 5:40 pm | #115 |
Retired Dormant Member
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
|
Re: 819 line standards convertor.
In your photo the D input of the 1st FF should be connected to logic "1". Not to the Q bar output.
|
4th Nov 2011, 7:58 pm | #116 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
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. |
4th Nov 2011, 11:51 pm | #117 |
Retired Dormant Member
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
|
Re: 819 line standards convertor.
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.
|
5th Nov 2011, 9:01 am | #118 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
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. |
5th Nov 2011, 9:19 am | #119 | |
Retired Dormant Member
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
|
Re: 819 line standards convertor.
Quote:
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. |
|
5th Nov 2011, 10:10 am | #120 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
All Run now
I'm going to optimize the code. There is some others small warning. Fred. |