14th Oct 2011, 8:55 am | #81 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi everybody,
I'm back concerning this topic. I spent a several nights and I made several nightmare too to solve the problem of the software. The system is not running at this moment but it is still in progress... The problem come from the design of my FIFO... I haven't seen my FIFO design did not contain enough slots. Now, my fifo run in demo mode by using ISIM from XILINX. The next step is to build the hard part on veroboard. In attached files, there is the good running design of the fifo and the testbench to check it. As we said in France " Patience et longueur de temps font plus que force ni rage" => "Patience and time do more than force or rage ..." Have a nice day. Frédéric Cabanes. |
14th Oct 2011, 9:17 am | #82 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi again,
Some screen shot of the simulation. First screen shot show the start period of the fifo. We can see that the first value stored in the fifo is "8" just after the reset signal go to "0" and when the WR_EN is on with a rising edge of WR_clk. On the second screen, the fifo is in read mode, so, the first value on the stack is the first registred => "8" => correct. The screen shot N°3 is the srenn shot of the next startup period. I implement a counter for the WR_data independant of the reset. the next value is now "26" and we see in the next screen shot that when the next read fifo state come, the first value outputed is "26"=> correct. I hope this can help someone for others design in VHDL. Fred. |
17th Oct 2011, 9:03 pm | #83 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi Darryl and PPPPenguin,
Concerning my previous problem about synthesis, you can forget them. Well, since I use the new version of XILINX ISE 13.1, I have no problem anymore when I check my complet design. I think it was a problem of the previous version. Thank you very much for your help. Frédéric. |
20th Oct 2011, 7:31 am | #84 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi Darryl and PPPPenguin,
I've started to build the hard part. I meet some problem concerning the signal coming out from the NEXYX2. All the signals driving low frequencies are OK but the output signals of high frequencies are not square but triangular. For example, the sampling clock signal at 6 MHz for the TDA8708 and the clock signal for the TDA8702 are not visible at all. Is-there some trick for driving hight frequencie signal? Thank you very much. Frédéric. |
20th Oct 2011, 8:19 am | #85 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi,
I have made some change in the design of the FIFOs. Now, they are made by block RAM and not anymore LUT. Concerning the problem of the hight frequencies driving TDA8708 and TDA8702, I supposed the problem come from this => Xst:2169 - HDL ADVISOR - Some clock signals were not automatically buffered by XST with BUFG/BUFR resources. Please use the buffer_type constraint in order to insert these buffers to the clock signals to help prevent skew problems. Frederic. |
20th Oct 2011, 8:53 am | #86 |
Retired Dormant Member
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
|
Re: 819 line standards convertor.
BUFG is only used to buffer signals INSIDE the FPGA. All clocks signals driving a large number of loads should use a BUFG. The XST software will often insert a BUFG automatically.The fact it has not suggests you are using your clock signals badly.
I assume that the clocks to the TDA8708 and 8702 are coming from pins on the FPGA. If they are not square, what is the bandwidth of your oscilloscope? If it is less than 50MHz then the waveform will not be displayed accurately. The type of probe and method of connection will also affect the accuracy. I also need to question why only 6MHz clock. This sample rate will allow a maximum analogue bandwidth of 3MHz. |
20th Oct 2011, 9:23 am | #87 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi PPPPenguin,
You're right concerning the 6MHz clock for the TDA8708. I've made a mistake... it should be at least 13.5Mhz. I'll change this right now. Concerning the oscilloscope, I'll check everything because it's an TEKTRONIX with 4 * 100 mhZ. Maybee, it's a problem coming from the probe. Can you confirm me that the output of the FPGA give all the time for any frequencies in the normal range square signal ? I don't need to buffer output clock? I'm very sorry to disturb you with this but I'm so close to the end... I think now, I just need some small fine tuning setting concerning the VHDL code. I check with separate board the hardware part=> all are OK. I hope the system run until Christmas. Thank you very much for your support. Frédéric. |
20th Oct 2011, 10:20 am | #88 |
Retired Dormant Member
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
|
Re: 819 line standards convertor.
You may need to adjust the drive strength of the FPGA output pin. I think this can be varied from 2mA to 12mA. Here is an example from a UCF file:
NET "pSDI1<0>" LOC = D23 |IOSTANDARD = "LVCMOS33" |DRIVE= 4; This was working at up to 148.5MHz. I used the probes I describe below to optimise the waveform by adjusting the drive strength. My scope is only 400MHz so some of this was guesswork. Probes are very important. A low cost probe will give bad results. Even a high quality Tektronix 10:1 probe can easily give misleading results. The attached picture shows a home made probe that is better than anything you can buy for this sort of work. The voltage will not be accurate unless you make a resistor of exactly 4950R but this doesn't usually matter for logic work where you know the voltage beforehand. The high frequency response is good to over 1GHz. You can build the probe into an old ballpoint pen or simply solder the resistor directly to the circuit. Some scope have a 50R setting at the input. in this case you don't need the T piece and 50R termination. This article gives a lot of useful information. The probe I have described is what the author calls a resistive input or Z0 probe. He used 1K which gives more bandwidth and less attenuation but higher loading of the circuit under test. It is not critical for your application. http://www.sigcon.com/Pubs/straight/probes.htm |
20th Oct 2011, 1:44 pm | #89 |
Hexode
Join Date: Jul 2004
Location: Michigan USA
Posts: 325
|
Re: 819 line standards convertor.
Frederic,
I really can't add anything to what Jeff has already said. I routinely run fpga outputs at over 100MHz and have driven them as high as 270MHz. Even with a low drive strength you should not be having an issue driving a single load at 12MHz. I would verify your scope setup as Jeff has suggested. You also really should investigate the Xst:2169 - HDL ADVISOR error as this indicates you are driving non-clock loads. While there is nothing inherently wrong with this (I do it regularly for various reasons) you need to be fully aware of the implications. Darryl
__________________
Aurora video standards converters: http://www.tech-retro.com/Aurora_Design/Video_Home.html |
20th Oct 2011, 3:13 pm | #90 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi Darryl and PPPPenguin,
You're right. I check all my probe... and the problem come from them... I need to set all the compensation capacitor. I've made an error concerning the fact that using probe in X1 position give bad result . Using the probe in position X10 give really better result. My oscilloscope is an Tektronix TDS 3034B => 300 MHz Bandwidths. I think is enought to make the mesurment . I'll continu the test and inform you as soon results comes. Frédéric. |
1st Nov 2011, 11:54 am | #91 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi Dears gentlemen,
Concerning the final stage of my converter, do you think it's an problem if I avoid the final DAC? In place of it, I would like to use a discrete DAC with R2R components, then, this delete the read output clock for the final TDA8702. Tomorrow, I'll make the final tests of the digital part. For those who want to make some tests, I use an FXBB board and NEXYS2 500Kgates. For the first tests, I only use a LM1881 just to check the internal signal. No ADC are connected => TDA8708. In attached documents, you'll find the new design with some correction and a new UCF file to check internal signal. If someone have some question, you can ping me. Fred. |
1st Nov 2011, 11:59 am | #92 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi PPPPenguin,
Concerning the probe, I just finish to read the paper. Very interesting. Soon, I do an the resistive-input probe with your schematic. Thank you for your support. Fred. |
1st Nov 2011, 12:51 pm | #93 | |
Hexode
Join Date: Jul 2004
Location: Michigan USA
Posts: 325
|
Re: 819 line standards convertor.
Quote:
Darryl
__________________
Aurora video standards converters: http://www.tech-retro.com/Aurora_Design/Video_Home.html |
|
1st Nov 2011, 6:44 pm | #94 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi Darryl,
For my DAC, I'll use resistors about 10Ko and 20Ko of 1% accuracy. I hope this will be enough. The permanent current will be about 0.200 mA. I try to make some tests tomorrow by creating a simple ring counter with 8 bits driving a DAC resistor. Thank you for your support. Fred. |
2nd Nov 2011, 5:51 pm | #95 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi Dear all,
I meet actually a big problem with one of my internal signal. I need to create a reset signal for the complet design. This signal (raz_int) is an addition of an hardware reset (raz)=> easy => resistor and condensator and a signal coming from the LM1881 (vsync)=> the vsync signal from LM1881. raz_int <= raz or vsync_rst; The problem is that the signal coming from the LM1881 is hight for 230µs so, medesign run in a wrong way What I want is when the vsync signal come up, a pulse around 40 or 80 nS comes. The mclk period is 20nS. vsync_rst is the signal I want=>pulse around 1 or 2 mclk period derivated from the rising edge of vsync. I create this code below but XILINX give me the following information. process(mclk, raz)-- begin if raz = '1' then --hardware reset vsync_rst <= '0'; elsif (vsync'event and vsync = '1' and mclk ='1')then vsync_rst <= '1'; else vsync_rst <= '0'; end if; end process; ERROR:Xst:827: - "D:/Documents and Settings/Convertisseur_819_lignes/driver_625_avant_implemenatation.vhd" line 94: Signal vsync_rst cannot be synthesized, bad synchronous description. The description style you are using to describe a synchronous element (register, memory, etc.) is not supported in the current software release. Thank you for our support. Fred. |
2nd Nov 2011, 9:03 pm | #96 |
Nonode
Join Date: Oct 2008
Location: Warsaw, Poland and Cambridge, UK
Posts: 2,669
|
Re: 819 line standards convertor.
I think you need a little state machine, clocked by mclk, which enters a 'reset' state for one clock cycle whenever vsync goes high. That will produce a short reset pulse. The VHDL you've quoted is, in my understanding at least, not feasible to synthesize - it appears that vsync_rst should be '1' only during rising edges of vsync when mclk is high, which is impossible because a rising edge doesn't last any time!
|
2nd Nov 2011, 9:07 pm | #97 |
Nonode
Join Date: Oct 2008
Location: Warsaw, Poland and Cambridge, UK
Posts: 2,669
|
Re: 819 line standards convertor.
Try this for size - it's taken from the VHDL for my disc drive controller, and generates an output pulse one clock cycle wide on disc_changed_strobe whenever write_protect goes from '0' to '1'.
Code:
architecture Behavioral of disc_change_detector is type state_type is (low, pulse, high); signal state, next_state: state_type; begin stateadvance: process(clock_statemachine, reset) is begin if reset = '1' then state <= low; elsif clock_statemachine = '0' and clock_statemachine'event then state <= next_state; end if; end process; statechange: process(clock_statemachine, reset) is begin if reset = '1' then next_state <= low; elsif clock_statemachine = '1' and clock_statemachine'event then case state is when low => if write_protect = '1' then next_state <= pulse; else next_state <= low; end if; when pulse => next_state <= high; when high => if write_protect = '0' then next_state <= low; else next_state <= high; end if; end case; end if; end process; disc_changed_strobe <= '1' when state=pulse else '0'; end Behavioral; |
3rd Nov 2011, 12:37 pm | #98 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi cmjones01,
Thank you very much for your help, I try your code and finally, I found another solution. I delay and reverse the vsync signal with a FLIP FLOP and now all run vsync_reset <= vsync_inverse and vsync_ret; raz_int <= raz or vsync_reset; process(mclk, raz) begin if raz ='1' then vsync_ret <= '0'; elsif rising_edge (mclk) then vsync_ret <= vsync; end if; After one night, everything get more clear All the signal coming out the FPGA are exactly want I need. Now, I'm starting to build the hard part with TDA8708... Fred. |
3rd Nov 2011, 1:47 pm | #99 |
Retired Dormant Member
Join Date: May 2009
Location: Fresnes, France
Posts: 124
|
Re: 819 line standards convertor.
Hi,
The last up-date of all files. Fred. |
3rd Nov 2011, 5:01 pm | #100 |
Nonode
Join Date: Oct 2008
Location: Warsaw, Poland and Cambridge, UK
Posts: 2,669
|
Re: 819 line standards convertor.
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. |