Clocked Video IP for NTSC bt656

[Altera_Forum]

Hello everyone, 

 I desperately need help with getting my embedded sync bt656 clocked out IP to work.  I have connected the test generator module found in the VP 8.0 reference example, and connected it to the Clocked Out video ip.  Then connected the Video output 8 bit bus to my ADV7171 video IC.( which has been tested with its internal color bar.)  The test generator is set to send := 422 ycrcb 720 by 486  The Video Clocked out IP is set to Embedded sync mode, 720 by 486 active picture and 8 bit , 2 symbols per beat and interlaced.  synce field one is Active Picture line=20 Horizontal Blanking =138 Vertical Blanking = 20  Field zero F rising=266 F falling =4 vertical blanking rising edge line =264 vertical blanking =19  All I end up getting is a black screen, and when brightness is turned up it is light green vertical lines. Please can some one help me with this problem , it will be greatly appreciated.  regards, Nadeem

[Altera_Forum]

Have you signal tapped the outputs to see what's coming out?

[Altera_Forum]

thanks for your response. 

Yes i do seem to be getting video data out, but not sure if it correct. I know that the the video IC is doing something as it is definitely sending a signal to myscreen.  I was little confused by the question of using 10 bits and 2 symbols or 8 bits and 2 symbols.  not sure what the 10 bits , standard altera settings are for?  I am not even sure if my Blanking setting are right.  regards nadeem

[Altera_Forum]

Sorry I am not familiar with the IP cores you are using but this article on inserting BT656 TRS codes may help, http://www.singmai.com/sdi.htm. 

 If you are getting a green screen then that normally indicates the Y and C are swapped.

[Altera_Forum]

Nadeem 

I failed at several attempts to get the Test Pattern Generator to send data to the Clocked Video Output and then on to a Video Encoder in BT-656 format using VIP. I tried inside SOPC Builder and Inside Qsys. Both failed and I thought it was the tools. I finally moved both the TPG and CVI blocks to a the Quartus II block level (BSF). The setup attached displays color bars running on a normal NTSC monitor. I attached a PDF file showing the steps I used and hope it is helpful to you, or someone else, that has a similar problem. Seeing Color Bars on an NTSC monitor was my only goal in this write up. It requires I2C inititialization via NIOS2 for the ADI color encoder and a 27MHZ clock.   In your text you mention entering a variety of field lenghts for F0 and F1 fields. I tried to do this and the vertical sync was being written over by the CrYCbY data until (using the 100th monkey algorithm) I got this version (see attached PDF) to produce color bars. In the latest version of VIP there is an NTSC setup button that sets most of the parameters correctly.   There may be better ways to do this but at least this is one way to see that the hardware works. I am a new-user and am in awe of the people that have done this type of work for many years. They make it look simple. It is "after it works". Till then it is not simple at all. Lyle

[Altera_Forum]

The other thing you may want to look at in the data sheet is the i2c MPU port. 

You may need to set some registers inside the chip appropriately in order to have it generate video correctly. Also, it looks like you may be able to have the chip generate a color test pattern internally and output it to your monitor. You may want to try and get this feature to work before sending it video from your FPGA.

[Altera_Forum]

--- Quote Start ---  I finally moved both the TPG and CVI blocks to a the Quartus II block level (BSF).   --- Quote End ---     --- Quote Start ---   In the latest version of VIP there is an NTSC setup button that sets most of the parameters correctly.   --- Quote End ---   Hello, lrp! Which of two above acts really helped?

[Altera_Forum]

Hello, lrp ! 

   --- Quote Start ---   In the latest version of VIP there is an NTSC setup button that sets most of the parameters correctly. Lyle  --- Quote End ---   Do You mean, that some NTSC parameters are still set incorrectly by setup button?  What constraints did You use for that project?

[Altera_Forum]

--- Quote Start ---   I finally moved both the TPG and CVI blocks to a the Quartus II block level (BSF).   --- Quote End ---   How did You do that? Created the connections in QSYS and then generated *.bsf or You did not use QSYS at all?

[Altera_Forum]

Aphraton 

Your first question is: Which of two above acts really helped? Answer: The settings actually helped. These blocks work equally well inside the QSYS module or outside in block form. The file I attached to Message# 5 above shows them in block form.    Your second question: Do I mean that the NTSC default setting can result in incorrect settings? Yes. The PDF attached in# 5 spells out the sequence of settings and the values I used to get NTSC 720X480 color bars using the Altera IP. You need to send 8 bit data or 10 bit data depending on your encoder. My encoder is set to 8 bits in this example. The tricky value was the number of lines. Changing it even one or two in any direction causes very bad vertical sync problems. (which, in hind-sight, it should)   gwall (message#6) correctly mentions that the first step is to turn color bars on via I2C in the video encoder. They should be perfect on an o-scope or vectorscope or waveform monitor for 75% color bars. The DAC current setting resistor on the ADI part I used needed to be 4.12K with a 300 ohm load going into the 2:1 gain op amp. That LPF needs to move between the output of the encoder and the amp to remove the A/D noise or you can use the ADI app note which indicates a cap/inductor/cap filter in discretes. The I2C address and data to set up the ADI encoder is included in the little PDF I posted. NIOS is only used to set up the OpenCores I2C and send out the initial data.    After you get the color bars to show up correctly you only need to switch some I2C registers to allow the 27MHZ YUV data to drive the encoder at 75%. The two match nearly exactly but not 100%. The Altera generated color bars are 3% lower in luma than the ADI generated data and they have smoother transitions between the color bars.    I use a VTM-3100 vectorscope and took some pictures with my cell phone. I attached images from both cases: 1. ADV7393 internally generated colorbars and 2. ADV7393 generating color bars from the 27MHZ YUV stream from the Altera IP. These two groups of photos show the difference in the colorbars that are internally generated and those that are generated using the Altera IP.    There is also a modified encoder schematic showing the LPF. This does not use the high current output and low impedance matching that ADI recommends but saves a lot of power in the DAC output.   I apologize for not getting back sooner. My email was killing the messages from this forum and I have had a busy time. LRP

[Altera_Forum]

--- Quote Start ---   It requires I2C inititialization via NIOS2 for the ADI color encoder and a 27MHZ clock.   --- Quote End ---   I studied Your project as a tutorial. It really helped! Would You please post Your NIOS II + I2C design to show how to program NIOS to do I2C inititialization and how to set I2C bidirectional pins in open collector mode. Or at least please point me to some good tutorial on this subject.

[Altera_Forum]

--- Quote Start ---  I studied Your project as a tutorial. It really helped! Would You please post Your NIOS II + I2C design to show how to program NIOS to do I2C inititialization and how to set I2C bidirectional pins in open collector mode. Or please point me to some good tutorial on this subject.  --- Quote End ---    Aphraton  I remember using Quartus version 7.x and editing the pin list to insure that each one correctly corresponded to the needs of the project. Any discrepancy was met with many glaring compiler errors so one quickly learned the ropes. However the newer version of the compiler seems to use the input/output declarations in the Verilog code to assign the pin type. In the attached PDF I put several more screen grabs of that project and some source code for you to look at. Please let me know what parts of this are still not clear. lrp

[Altera_Forum]

Thank You, lrp! 

What i2C IP did You use? OpenCores or something else? Did You use any custom presest in NIOS II instantiation? Is NIOS II /e ( free economical edition ) enough to intialize ICs via I2C?

[Altera_Forum]

Aphraton : Re: Clocked Video IP for NTSC bt656  

What i2C IP did You use? OpenCores or something else? Yes. This project used the OpenCores I2C routines.  Did You use any custom presest in NIOS II instantiation? No. This is simplest NIOS II/e with internal SRAM.  Is NIOS II /e ( free economical edition ) enough to intialize ICs via I2C? Yes. I2C and serial I/O are roughly equivalent to PIO in complexity. The NIOS II/e is way overkill for all these functions. Recall that these all can be done easily in any 8 bit processor and the resources needed are very few. I2C is mostly a matter of getting a dual trace scope connected to SCL and SDA. Verify the 100KHZ/400KHZ bit rate, the clock timing/polarity and the start/stop/restart transitions. Keep the initial message SHORT and force the same message to occur 4-10 times per second so you can sync the scope easily. Use one trace for clock and one for data and watch that the ACK bit is being pulled low by the slave. Then change the address and watch that the ACK bit is not being pulled low. At some point you get the first I/O byte to go out and come in. After that you simply change the address and use auto-increment to send multiple bytes. Problems in more complex protocol exchanges can be sussed out with simple analyzers that have built-in protocol analyzers. I use Saleae Logic-16 16 channel USB Logic Analyzer to simplify the process when it gets more complicated than a simple I/O device. For this level of project (Video Encoder/Decoder) you should use printf to the JTAG serial port and watch the system initialize as you expect. The printf statements can be commented out. The basic rule for debug statements is to not delete them, just comment them out because "if you used them once you will use them again". You will use them again, for instance, if you need to change the driver or use a slightly different chip in the future. In general use NIOSII/e with internal memory to get things started when bringing up new hardware. You can trust that a NIOS II/e with internal memory will ALWAYS boot and run regardless if other external memory is working correctly or not. You can get simple drivers running and use it to memory test flash/sram/dram etc. You can trust the FPGA to run correctly if the core is running and JTAG is good. New hardware must be assumed to be bad when you first bring up any board. It takes time but you must verify each line of code and every net on the schematic one-by-one. I have written bit-banged I2C routines and the OpenCores are much better because the processor is not trapped at a bit level. The OpenCore I2C routines are great. lrp

[Altera_Forum]

Hello, lrp! 

I am now beginning to test Your C code for I2C initialization and I before I started have several questions / comments: 1). In the datasheet "I2C Master core" ( i2c_specs.pdf ) from Opencores prescale is calculated in a different way, than in Your code. 2). Unsleep function doesn't produce pauses, stated in corresponding comments.  3). Where from can I get "i2c.h", "links.h" files, that are# include(d) in C code? They are not included in "I2C Master core" from Opencores.  Maybe should I use "i2c_opencores_regs.h" or "i2c_opencores.h" and "linker.h" instead?  P.S. I found the solution by myself.