VHDL How to use TFP401 on a daughter card

Hello,

In my current project I am using these duo: LINK.

Up to this point I was not using the receiver, and was generating the sync and display enable signals myself. Now, I am planning to implement the receiver to have a background video stream on which I will be painting stuff through the transmitter (up to now I was dealing with this part only, the background was a constant color which was sent by transmitter as well).

The problem is that I can not think of a suitable way to count the pixels while using the HSYNC, VSYNC and DE signals of the incoming video signal. I know the active part by DE but I dont know which pixel is coming from the receiver, so that I pass it to transmitter unchanged or I pass it after manipulating its color.

Hope I could be clear enough. I am looking forward to your help, thank you!

PS: I have the pin config ready and working.

I'm assuming you're using the DVI-A mode based on your use of HSYNC, VSYNC, and DE?

You need to generate a pixel clock that matches the pixel rate of the incoming video. You could do this by oversampling the input and detecting bit changes and determine the center of the data eye. Altera does something similar with their ASI core. In that case they are trying to extract bits from a 270 MHz serial data stream, so they 5x oversample using both rising and falling edges of a 337.5 MHz clock (using 4 phases of the clock 0, 90, 180, 270), which just barely meets timing in a Cyclone III. Fortunately for you DVI-A the pixel clock maximum is something like 165 MHz, so you can get away with using something like 206.25 MHz to oversampling by 5 or 247.5 MHz to get oversampling by 6.

ads-ee said:

I'm assuming you're using the DVI-A mode based on your use of HSYNC, VSYNC, and DE?

You need to generate a pixel clock that matches the pixel rate of the incoming video. You could do this by oversampling the input and detecting bit changes and determine the center of the data eye. Altera does something similar with their ASI core. In that case they are trying to extract bits from a 270 MHz serial data stream, so they 5x oversample using both rising and falling edges of a 337.5 MHz clock (using 4 phases of the clock 0, 90, 180, 270), which just barely meets timing in a Cyclone III. Fortunately for you DVI-A the pixel clock maximum is something like 165 MHz, so you can get away with using something like 206.25 MHz to oversampling by 5 or 247.5 MHz to get oversampling by 6.

Click to expand...

Doesn't the card do those tasks itself and outputs a LLC signal ready to use? I am using that LLC signal, that is the pixel clock of my received video. I am using that clock both as a system clock and pixel clock for transmit part.

I am using a similar controller to this ONE. I am not that into types of DVI, but I assume it is DVI-A as it is, in fact, a VGA controller.

I can output what I receive (like dual monitors, with no alterations to the image) with no errors, so I think I do not have any issues with clocking. The problem is when I want to manipulate what I receive. I cant think of a way to reach to a specific pixel, how do I know for example, the received bit is the top left of the active region so that I can use a counter to reach to the pixel I want?

My mistake I thought you were working directly with the DVI-A signals received and not the output of some IC.

As I don't have time to research what is used on that receiver card to interface to the DVI and gives you the LLC output (whatever that acronym stands for), so I have no idea if you still have any of the Vsync Hsync information, which is what is used to determine where you are in the image. If that interface doesn't give you that information in some form then I'm not sure what magic they use to correctly sync the video.

ads-ee said:

My mistake I thought you were working directly with the DVI-A signals received and not the output of some IC.

As I don't have time to research what is used on that receiver card to interface to the DVI and gives you the LLC output (whatever that acronym stands for), so I have no idea if you still have any of the Vsync Hsync information, which is what is used to determine where you are in the image. If that interface doesn't give you that information in some form then I'm not sure what magic they use to correctly sync the video.

Click to expand...

I am basing my design on a reference design that is working (receiving from TFP401 and transmitting from TFP410), and that design uses that LLC signal as clock just as I explained. However, I also have access to those DVI-A signals you are speaking of, and I know what they are responsible for, as I wrote a transmitter on my own. However the problem is, I can not think of a way to use them to understand which pixel is just received.

What I am trying to do for example is to put a solid filled black square on a specific location on the screen while the remaining part is a video stream.

I'm pretty sure the timing is exact based on the pixel clock, a row of pixels is offset (in clocks) in a specific location between syncs. Off hand I don't know the exact position of the first pixel after a blanking period, but I'm sure there are resources out there that describe the location. There shouldn't be any problems of finding a specific location of a pixel within a frame as they are output row by row from top to bottom of the screen. I'm not sure what it is you don't understand.

I've mostly worked on MPEG transport streams (digital video), so I'm only somewhat familiar with the Analog side of video signalling. Maybe someone else can answer more specifically.

ads-ee said:

I'm pretty sure the timing is exact based on the pixel clock, a row of pixels is offset (in clocks) in a specific location between syncs. Off hand I don't know the exact position of the first pixel after a blanking period, but I'm sure there are resources out there that describe the location. There shouldn't be any problems of finding a specific location of a pixel within a frame as they are output row by row from top to bottom of the screen. I'm not sure what it is you don't understand.

I've mostly worked on MPEG transport streams (digital video), so I'm only somewhat familiar with the Analog side of video signalling. Maybe someone else can answer more specifically.

Click to expand...

No problem, thank you for your response. I couldn't find any vhdl design on the web that is using a vga/dvi/hdmi input/receive. Could you please help me find something similar to my project, I don't know if I need to google a specific word/phrase.

searching for VHDL VGA gave me this:
https://eewiki.net/pages/viewpage.action?pageId=15925278

It should give you some idea of the timings. They are they same for input and output.

I know about the timings but I was not sure how the receiver worked. I think I got over the issue, but now I am facing a new one.

I connected the receiver to my computer's GPU (as an extended dual monitor setup) and transmitter to monitor. Computer recognizes the display automatically but it says its DELL whereas its a SAMSUNG monitor. Moreover, when I set the resolution of the second monitor from AMD software to 1440x900 the monitor shows 1680x1050 in its information utility. When I set it to 1280x1024 however, it changes to it correctly and shows 1280x1024 in information utility.

I can see the extended desktop on the second monitor though.

TrickyDicky said:

searching for VHDL VGA gave me this:
https://eewiki.net/pages/viewpage.action?pageId=15925278

It should give you some idea of the timings. They are they same for input and output.

Click to expand...

ads-ee said:

I'm pretty sure the timing is exact based on the pixel clock, a row of pixels is offset (in clocks) in a specific location between syncs. Off hand I don't know the exact position of the first pixel after a blanking period, but I'm sure there are resources out there that describe the location. There shouldn't be any problems of finding a specific location of a pixel within a frame as they are output row by row from top to bottom of the screen. I'm not sure what it is you don't understand.

I've mostly worked on MPEG transport streams (digital video), so I'm only somewhat familiar with the Analog side of video signalling. Maybe someone else can answer more specifically.

Click to expand...

IMPORTANT UPDATE/QUESTION:

Do you know how I can update the EDID information that is stored in the eeprom on the daughter card? I updated the edid from BITEC website but when I view the EDID contents with monitor info view 1440x900 is still not present. This is why the monitor does not support this resolution over BITEC card. When I connect the monitor directly to the computer, the SAMSUNG EDID on the monitor does contain 1440x900 and the resolution is applied with no errors. So I want to copy the contents of the SAMSUNG's EDID to the eeprom of BITEC CARD, but I have no clue how to do it. If you know anything about the matter, please help me. I couldnt find anything similar, so I am not sure how I download edid information to FPGA. I suppose I need to write some kind of I2C code that I havent written before, so I am pretty much confused.

Thanks.