Author Topic: FPGA video format conversion  (Read 12515 times)

0 Members and 1 Guest are viewing this topic.

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
FPGA video format conversion
« on: June 26, 2017, 12:25:15 am »
Hi,

I am aiming to convert a CRT oscilloscope into an LCD oscilloscope by converting the video signal to VGA using an FPGA. The incoming video format is similar to VGA but uses different timing and voltages.

The pixel clock (ie time per pixel) etc for VGA is at a different rate to the incoming video signal. Therefore my incoming signal is not synchronised in any way with my outgoing video signal except that they are both 60Hz. I'm trying to figure out the best way to deal with this situation.

I was thinking what I could do is have two banks of memory. The incoming frame writes to the banks alternately, and the outgoing frame reads from the banks alternately, such that we never read from a bank at the same time as writing to it.  But this assumes that I can keep both displays completely in sync (they are both operating at 60hz). I would then have two different pixel clocks  (outgoing and incoming) and the banks of memory would switch between the two clocks and  I don't know if this is a good idea?

Is there a better architecture for converting between the two video signals?
Read about my stuff at: projects.matthollands.com
 

Offline marshallh

  • Supporter
  • ****
  • Posts: 1458
  • Country: us
    • retroactive
Re: FPGA video format conversion
« Reply #1 on: June 26, 2017, 03:33:22 am »
Yes, you have the right idea. But in practice the sync rates will never be exactly the same.
So you will need to treat them as asynchronous. You'll need at least 3 framebuffer slots to do rate conversion. Then add some very simple logic to increment ecah domain's FB ptr at each frame completion.
Verilog tips
BGA soldering intro

11:37 <@ktemkin> c4757p: marshall has transcended communications media
11:37 <@ktemkin> He speaks protocols directly.
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1152
  • Country: ca
Re: FPGA video format conversion
« Reply #2 on: June 26, 2017, 04:45:07 am »
Worse yet. If the input clock is faster then you should be able to skip some of the frames. If the input clock is slower you should be able to output the same frame twice. If the clock frequency varies over time you should be prepared to do either of these.
 

Online Yansi

  • Super Contributor
  • ***
  • Posts: 1808
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: FPGA video format conversion
« Reply #3 on: June 26, 2017, 04:48:00 am »
Yes, you have the right idea. But in practice the sync rates will never be exactly the same.
So you will need to treat them as asynchronous. You'll need at least 3 framebuffer slots to do rate conversion. Then add some very simple logic to increment ecah domain's FB ptr at each frame completion.

Why three frame buffers? How would you work with them?
 

Offline bktemp

  • Super Contributor
  • ***
  • Posts: 1623
  • Country: de
Re: FPGA video format conversion
« Reply #4 on: June 26, 2017, 05:05:29 am »
It can be done on several ways:
Using multiple frame buffers is one possible solution but requires an memory and may generate artefacts with changing screen content due to skipping/replicating frames.
If the output video timing must not match VGA exactly, you can choose a similar timing and fine tune/correct/sync the timing by skipping pixels or lines during blanking interval. This works fine for most TFT LCD panels and DVI/HDMI output, but may create problems for a true VGA output because of the PLL used for recovering the pixel and line clock in monitors. If input and output timing are close enough maybe a small linebuffer FIFO is sufficient, removing the need for an external memory.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 1670
  • Country: nz
Re: FPGA video format conversion
« Reply #5 on: June 26, 2017, 07:29:02 am »
Yes, you have the right idea. But in practice the sync rates will never be exactly the same.
So you will need to treat them as asynchronous. You'll need at least 3 framebuffer slots to do rate conversion. Then add some very simple logic to increment ecah domain's FB ptr at each frame completion.

Why three frame buffers? How would you work with them?

Triple buffering reduces the frame lag - it is in either of these states:
- One being filled
- One being displayed
- One waiting to be filled.

Or
- One being filled
- One waiting to be displayed
- One that is being displayed

It is used a lot in the software world to get the highest frames per second rates for interactive graphics, as the graphics H/W is never idle waiting for a buffer to come free.

(However, I don't that it is really applicable here).
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #6 on: June 26, 2017, 09:24:15 am »
Great, that's more or less the approach I thought I would go for. My next question then is, if I have these three buffers as three BRAMs in my FPGA, and I have my input pixel clock and my output pixel clock (operating at different frequencies), is it ok to just switch the BRAMs between the two clocks depending on who is accessing it? Or should I have a fast master clock that the BRAMs run on and then in some way interface this to the slower pixel clocks?

[edit] In reality, the amount of memory  I would need looks to be way more than is possible via BRAM using a reasonably priced FPGA (3 640x480 frames at 3 bits per pixel). How should  I structure the memory best for this? Would a chip like this be the right approach? http://www.alliancememory.com/pdf/dram/16M-AS4C1M16S-C&I_v2.0_March%202015.pdf [/edit]
« Last Edit: June 26, 2017, 09:51:22 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline marshallh

  • Supporter
  • ****
  • Posts: 1458
  • Country: us
    • retroactive
Re: FPGA video format conversion
« Reply #7 on: June 26, 2017, 09:51:24 am »
All modern FPGAs have true dual-port BRAMs. Just port A to your source domain (scope), and port B to sink domain (vga output).


However, it gets even easier if you can directly drive a panel digitally. Then you can feed it any pixel clock and any sync rate.
I've used this one: http://www.ebay.com/itm/361190698316
If you want I can give sample schematics and power supplies.

Verilog tips
BGA soldering intro

11:37 <@ktemkin> c4757p: marshall has transcended communications media
11:37 <@ktemkin> He speaks protocols directly.
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 604
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: FPGA video format conversion
« Reply #8 on: June 26, 2017, 12:28:31 pm »
The pixel clock (ie time per pixel) etc for VGA is at a different rate to the incoming video signal. Therefore my incoming signal is not synchronised in any way with my outgoing video signal except that they are both 60Hz.
What is the actual timing of your signal? What VGA display(s) do you want it to be compatible with?
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #9 on: June 29, 2017, 09:39:48 am »
I don't actually know the exact timings for the signal but I have some oscilloscope captures here: https://keepdevelopingprojects.wordpress.com/2016/01/25/project-crt-oscilloscope-lcd-mod-motivation/

I want it to be compatible with a 640x480 60Hz VGA signal
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #10 on: July 06, 2017, 09:42:36 am »
Or.... you can go the other way.  Try getting a cheap flat-panel VGA input and lower it's crystal clock at the same ratio 31.5:25.  Feeding the video in now, the monitor will think it's actually 31.5Khz by 75Hz.

Also, any old Comodore Multisync screens which supported 15Khz through 36KHz on the horizontal will work directly with this logic analyser output.

A stupid dumb FPGA based line doubler, using an Analog Devices VGA ADC, with a bottom end 15$ Altera FPGA using 2k x 8bit dual-port ram for double each line coming out to a resistor ladder video dac will make a 50Khz X 60Hz video mode of 500xYYY(double your source) (horizontal res is meaningless here, you can call this 640 pixels or 1024 pixels) which is supported by any flat panel today.


I don't really want to risk damaging the scope and I also want it to work with any VGA monitor so I would rather do proper conversions.
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #11 on: July 06, 2017, 09:43:46 am »
Can anyone recommend an ADC? I only need 4 bits maximum, single channel, probably at least 15MHz sample rate.

I was looking at the ADC1175 http://www.ti.com/lit/ds/symlink/adc1175.pdf but it looks kind of complex.
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #12 on: July 06, 2017, 09:58:22 am »
With that ADC, you will need a long period PLL clock generating circuit tied to the H-Sync.  But if you don't want to deal with an ADC with I2C controls, I understand.


Could you suggest an ADC that would not require a PLL? I don't really want to deal with a PLL either.

Is there no way that I can just manage the clock timing with the FPGA?  Does the clock really need to be in phase
« Last Edit: July 06, 2017, 10:07:05 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Online sokoloff

  • Frequent Contributor
  • **
  • Posts: 822
  • Country: us
Re: FPGA video format conversion
« Reply #13 on: July 06, 2017, 10:44:52 am »
I would wire this to a FPGA which has at least enough internal ram for 5 lines of video, since you are using monochrome, that makes 1kx8 per line x 5, or 6kx8 to be safe.  The FPGA will need 1 pll to 2x the clock since you will be making a simple dumb line doubler.  IE, 24Khz video in, 50Khz out, the vertical 60hz will remain the same.  You will need an 8 bit DAC (unless you are feeding a panel digitally), or resistor DAC with a video opamp to feed the RGB analog in of an LCD screen and a logic buffer to convert the 3.3v sync out of the FPGA to 5v ttl as not all LCD screens like 3.3v.
How would that work?

I'm assuming when he says "CRT scope", he means a traditional scope with arbitrary X-Y-Luma vector drive (where a lissajous circle is drawn by moving the CRT beam in a circle, not by a progressive scan of the screen in Luma-H-V style).
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #14 on: July 06, 2017, 11:07:33 am »
I would wire this to a FPGA which has at least enough internal ram for 5 lines of video, since you are using monochrome, that makes 1kx8 per line x 5, or 6kx8 to be safe.  The FPGA will need 1 pll to 2x the clock since you will be making a simple dumb line doubler.  IE, 24Khz video in, 50Khz out, the vertical 60hz will remain the same.  You will need an 8 bit DAC (unless you are feeding a panel digitally), or resistor DAC with a video opamp to feed the RGB analog in of an LCD screen and a logic buffer to convert the 3.3v sync out of the FPGA to 5v ttl as not all LCD screens like 3.3v.
How would that work?

I'm assuming when he says "CRT scope", he means a traditional scope with arbitrary X-Y-Luma vector drive (where a lissajous circle is drawn by moving the CRT beam in a circle, not by a progressive scan of the screen in Luma-H-V style).
Ok, we got a problem here: After writing and deleting all those posts I made which were correct, and are now gone!
@sokoloff, did you even look at the OT's scope in his thread:
https://keepdevelopingprojects.wordpress.com/2016/01/25/project-crt-oscilloscope-lcd-mod-motivation/
It's a digital driven display logic analyzer with old 25Khz video CGA driving a monochrome CRT which he want to convert to a format compatible with a modern LCD screen, whose video formats which start at 31.5Khz VGA.

« Last Edit: July 06, 2017, 01:18:31 pm by BrianHG »
__________
BrianHG.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #15 on: July 06, 2017, 01:17:19 pm »
Ok, we got a problem here: After writing and deleting all those posts I made which were correct, and are now gone!
@sokoloff, did you even look at the OT's scope in his thread:
https://keepdevelopingprojects.wordpress.com/2016/01/25/project-crt-oscilloscope-lcd-mod-motivation/
It's a digital driven display logic analyzer with old 25Khz video CGA driving a monochrome CRT which he want to convert to a format compatible with a modern LCD screen, whose video formats which start at 31.5Khz VGA.


@MattHollands, I'm sorry, but, @sokoloff  :scared: messed me up and I deleted the original correct answers I gave you to your inquiry.

If you want to make a video scan doubler for your 'logic-analyser', (it's not really a scope as it says 'logic analyser' right on the top left of the device), start by taking a look at Texas Instruments TVP7002.
https://www.digikey.com/product-detail/en/texas-instruments/TVP7002PZP/296-22891-ND/1765836
Trust me on this one, don't worry that this IC has 3 parallel digitizer, if this chip is too complicated for you to build a circuit board around, then this a video scan rate converter / format converter is over you head.  If you want to know more? why?  Just ask and I'll re-write some of my deleted descriptions.
« Last Edit: July 06, 2017, 01:18:50 pm by BrianHG »
__________
BrianHG.
 

Online sokoloff

  • Frequent Contributor
  • **
  • Posts: 822
  • Country: us
Re: FPGA video format conversion
« Reply #16 on: July 06, 2017, 01:20:34 pm »
Ok, we got a problem here: After writing and deleting all those posts I made which were correct, and are now gone!
@sokoloff, did you even look at the OT's scope in his thread:
https://keepdevelopingprojects.wordpress.com/2016/01/25/project-crt-oscilloscope-lcd-mod-motivation/
No, I only read half the internet tonight and that wasn't in the half I read...
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1152
  • Country: ca
Re: FPGA video format conversion
« Reply #17 on: July 06, 2017, 11:59:09 pm »
If you want to make a video scan doubler for your 'logic-analyser', (it's not really a scope as it says 'logic analyser' right on the top left of the device)

If you already have FPGA, it might be easier to build your own logic-analyzer front-end than to interface analog video signal.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #18 on: July 07, 2017, 01:37:12 am »
If you want to make a video scan doubler for your 'logic-analyser', (it's not really a scope as it says 'logic analyser' right on the top left of the device)

If you already have FPGA, it might be easier to build your own logic-analyzer front-end than to interface analog video signal.
I don't think so.  Did you see the picture of this guys logic analyzer/digital oscilloscope combo?
It's worth his time and a worthy project.
The TVP7002 does all the video interface work for him, he just needs to set a few I2C commands to set the horizontal resolution and he will be fine.
The FPGA will just double each line coming out of the TVP7002 as 2x speed.  Easy enough with a 2:1 PLL setting in the FPGA and 2x 1kx8 dual port ram line buffers.
He only needs 8 bit monochrome.  A bottom end 10$ fpga will be overkill.  If he has any skill with Altera or Xilinx, and he has no trouble with a little MCU to set the I2C controls of the TVP7002, he can convert his current approximate video res of 512x384 to 512x768.  Basically 1024x768, every pixel 2x wide by 2x tall.  (Note that the extra pixels around the border of the logic analyzer's specked 500x240 could just be called a black border over-scan...)
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #19 on: July 27, 2017, 09:10:04 am »
Sorry it's been a long while! I've been a bit busy, but I've made progress with this.

I wanted to test your theory about line doubling, so I used an FPGA to simulate the signals if I doubled the horizontal frequency and you're right the display locks onto the signal  ;D

I also like your plan to use the TVP7002.

I'm thinking of using the Lattice LCMXO1200 FPGA. It has 1PLL, comes in a nice QFP package and has 9.2Kbits of EBR RAM which is enough for about 6 horizontal lines. Plus, it is pin compatible witht he LCMX02280 which has 3 times the ram and two PLLs if I need it. Does that sound reasonable then?
Read about my stuff at: projects.matthollands.com
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 15258
  • Country: nl
    • NCT Developments
Re: FPGA video format conversion
« Reply #20 on: July 28, 2017, 02:58:09 am »
Hi,

I am aiming to convert a CRT oscilloscope into an LCD oscilloscope by converting the video signal to VGA using an FPGA. The incoming video format is similar to VGA but uses different timing and voltages.

The pixel clock (ie time per pixel) etc for VGA is at a different rate to the incoming video signal. Therefore my incoming signal is not synchronised in any way with my outgoing video signal except that they are both 60Hz. I'm trying to figure out the best way to deal with this situation.

I was thinking what I could do is have two banks of memory. The incoming frame writes to the banks alternately, and the outgoing frame reads from the banks alternately, such that we never read from a bank at the same time as writing to it.  But this assumes that I can keep both displays completely in sync (they are both operating at 60hz). I would then have two different pixel clocks  (outgoing and incoming) and the banks of memory would switch between the two clocks and  I don't know if this is a good idea?
You can keep both displays in sync. TFT screens allow a wide range of their clocks and synchronisation signals. I have done these kind of conversions several times already. I prefer to use a Xilinx 9500XL series CPLD because these don't need an external config storage and have 5V tolerance. If the incoming and outgoing rate can be made synchronous (no form of interlacing) you don't need any storage.
« Last Edit: July 28, 2017, 03:00:29 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #21 on: July 28, 2017, 03:02:04 am »
You can keep both displays in sync. TFT screens allow a wide range of their clocks and synchronisation signals. I have done these kind of conversions several times already. I prefer to use a Xilinx 9500XL series CPLD because these don't need an external config storage and have 5V tolerance. If the incoming and outgoing rate can be made synchronous (no form of interlacing) you don't need any storage.

What do you use for memory?
Read about my stuff at: projects.matthollands.com
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 15258
  • Country: nl
    • NCT Developments
Re: FPGA video format conversion
« Reply #22 on: July 28, 2017, 03:17:07 am »
You can keep both displays in sync. TFT screens allow a wide range of their clocks and synchronisation signals. I have done these kind of conversions several times already. I prefer to use a Xilinx 9500XL series CPLD because these don't need an external config storage and have 5V tolerance. If the incoming and outgoing rate can be made synchronous (no form of interlacing) you don't need any storage.
What do you use for memory?
If needed I use an external SRAM. This is a board I made to convert an STN dot matrix LCD into TFT:
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #23 on: July 28, 2017, 03:53:43 am »
If needed I use an external SRAM. This is a board I made to convert an STN dot matrix LCD into TFT:

I will definitely need some memory and it will be easier if it is dual port (or two devices) so I will probably just go with the FPGA solution. But I appreciate your advice.
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #24 on: July 29, 2017, 04:56:13 am »
Check out Altera's MAX10 devices.  No bootprom and plenty of ram for 8 bit grey, multiple lines, or you can oversample and not worry about the PLL phase fine tuning, an all in 2.5 chip solution.  1 Max PLD, 1 Video ADC, + DAC, or parallel digital out to panel.
Too many IOs for your needs, 144 pin TQFP,
https://www.digikey.com/product-detail/en/altera/10M02SCE144C8G/544-3098-ND/5284822
__________
BrianHG.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 15258
  • Country: nl
    • NCT Developments
Re: FPGA video format conversion
« Reply #25 on: July 29, 2017, 08:01:36 am »
Check out Altera's MAX10 devices.  No bootprom and plenty of ram for 8 bit grey, multiple lines, or you can oversample and not worry about the PLL phase fine tuning, an all in 2.5 chip solution.  1 Max PLD, 1 Video ADC, + DAC, or parallel digital out to panel.
Too many IOs for your needs, 144 pin TQFP,
https://www.digikey.com/product-detail/en/altera/10M02SCE144C8G/544-3098-ND/5284822
If you go that route it is much easier to buy a readily made VGA to TFT scaler board. One of the problems is that you'll need to phase align the ADC's sampling clock with the input signals to prevent sampling at a point which is half way a pixel. Otherwise straight vertical lines will look funny.

In my experience it is better to go from digital to digital and don't mess with the analog display signals.
« Last Edit: July 29, 2017, 08:21:44 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #26 on: July 29, 2017, 10:05:24 am »
Check out Altera's MAX10 devices.  No bootprom and plenty of ram for 8 bit grey, multiple lines, or you can oversample and not worry about the PLL phase fine tuning, an all in 2.5 chip solution.  1 Max PLD, 1 Video ADC, + DAC, or parallel digital out to panel.
Too many IOs for your needs, 144 pin TQFP,
https://www.digikey.com/product-detail/en/altera/10M02SCE144C8G/544-3098-ND/5284822
If you go that route it is much easier to buy a readily made VGA to TFT scaler board. One of the problems is that you'll need to phase align the ADC's sampling clock with the input signals to prevent sampling at a point which is half way a pixel. Otherwise straight vertical lines will look funny.

In my experience it is better to go from digital to digital and don't mess with the analog display signals.

Arrrrrgggg, you haven't been reading my post & MattHollands posts.  Matt intends to use the TVP7002 as it was designed to sample video, generate a pixel clock, do black level restoration and has built in antialiasing filters & pixel phase adjustment.  The MAX10 would take in the monochrome 8 bit video (1 channel from the TVP7002 RGB digitizer) and PLL 2x clock of the video, delayed 1 line, driving 2 copies out at 2x speed including the HS signal.  Voila, line doubled video.  Nothing more than an input counter on DP ram fed 8 bit video + 1 bit h-sync, with counter reset on low to high transition of h-sync, running the input, and an output counter at 2x driving the output data and output h-sync with the same counter reset on that side reset at that h-sync.  Every new input line cycles a MSB address line on the input side of the ram while a 2 line DFF delay of that MSB address is send to the output side clocked by the transition of the output sync.  You are looking at a design using around 80 logic elements + 2kx9bit dual-port ram.  The smallest MAX 10 will be effectively empty.
A 2 year old can logic this one up in Altera's Quartus in the graphic editor consuming half of 1 single top-hierarchy page.  Not a single line of verilog or VHDL code is needed.
__________
BrianHG.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 15258
  • Country: nl
    • NCT Developments
Re: FPGA video format conversion
« Reply #27 on: July 30, 2017, 12:32:59 am »
And where is the microcontroller + software needed to configure the TVP7002? Again, if you got his route then a pre-made board will be easier and cost less. Also in many cases you can use the monochrome information and map this onto colors to provide a display which is easier to read. I did this on an Advantest R3261A and a Lecroy LW420A.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #28 on: July 31, 2017, 08:34:42 am »
And where is the microcontroller + software needed to configure the TVP7002? Again, if you got his route then a pre-made board will be easier and cost less. Also in many cases you can use the monochrome information and map this onto colors to provide a display which is easier to read. I did this on an Advantest R3261A and a Lecroy LW420A.

Well this project is largely for learning purposes. Hence I want to try spinning my own FPGA board, capture and process the signals myself etc. I am planning on remapping colours!  :)
Read about my stuff at: projects.matthollands.com
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #29 on: August 01, 2017, 07:23:00 am »
Having done a couple of FPGA video format conversions, I thought I'd contribute a few ideas. Unlike nctnico or BrianHG, I'm not going to give OP a solution, but rather a few points to consider:

1) Have you clearly defined the input and output of the design, and other constrains?

For the input, you would need to get to the bottom of it, measure the pixel clock frequency and all the timing parameters in the unit of pixel clock (horizontal total, active, sync width, front and rear porch, and the same for vertical).

For the output, you need to know your goal. Is it an analog, industrial-standard VGA-compliant output, or something acceptable by a PC monitor, or a digital video signal acceptable by an LCD panel? They are three quite different goals, although they overlap in certain areas.

In terms of other constrains, would you mind tapping into the pixel clock in the original video circuit, and perhaps the digital signals that generate the analog video via a video DAC or resistor network, or you are strictly limited to the signals available on the interface cable?
What about power and mechanical constrains, such as, do you plan to install an LCD panel in the original unit replacing the CRT? If so, the output format will be further limited by the resolution and size of available LCD panels.

2) The solution depends on what you have, and what you want to do.

For example, if you have access to the original pixel clock, things can be much easier. Do the math, and you'll find out if you can convert the original pixel clock into the new video format pixel clock using the PLL or DCM in an FPGA - they often have limited M, N and reference frequency range. If you maintain the exact frame rate, you can live without a frame buffer. How many line buffers you need depends on the vertical active-to-total ratio of the input vs output formats. Draw diagrams of input and output video format in 2D and compare them side by side, and you'll understand what I meant.

If you don't have access to the original pixel clock, you would need a PLL to recreate the pixel clock in order to sample the video signal properly. Not just any PLL, a PLL with KHz reference input and multiplication factor in the hundreds to the thousands. There are dedicated IC for that purpose, and fortunately Video ADCs often come with one built-in.
 
Do you really need a Video ADC, aside from the built-in PLL? You don't if you have access to the digital video signals in the original circuit, or if the original video has very few intensity levels (let's say 8 or less). By the way, using an ADC does not prevent you from doing grey scale to color mapping.

3) Don't let the recipe limit your creativity.

Both nctnico and BrianHG's solutions have their merits. You don't have to take one and drop the other. Instead, understand your requirement and take the parts from their solutions that meet your needs. For example, MAX10 seems nice, even if you don't use a Video ADC. On the other hand, there are plenty of open-source soft-core CPUs that you can integrate into an FPGA to do housekeeping things such as configuring a Video ADC via I2C.

Line doubling works. True. But does the line-doubled video exactly what you wanted from the beginning? How much off is it from the industrial-standard VGA? What will the picture look like on an LCD panel installed in the original chassis, if that's your goal? If you need more than the most basic image scaling, there are at least 20 different algorithms, and someone developed a program that allows you to compare them side-by-side.

My point is, a lot of planning can be done on the drawing board before you jump in and start writing RTL or drawing schematics.
Hope that helps your learning experience, and good luck ;)
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #30 on: August 01, 2017, 09:11:42 am »
Quote
For the output, you need to know your goal. Is it an analog, industrial-standard VGA-compliant output, or something acceptable by a PC monitor, or a digital video signal acceptable by an LCD panel? They are three quite different goals, although they overlap in certain areas.
Originally I wanted to make it a true, industrial standard VGA, but having tested out a lot of monitors and found that they will lock onto a less "standard" signal, I'm happy to settle for any signal acceptable by a PC monitor. I  don't want a digital video signal because I want to be able to easily change the panel etc or have an external display.

Quote
In terms of other constrains, would you mind tapping into the pixel clock in the original video circuit, and perhaps the digital signals that generate the analog video via a video DAC or resistor network, or you are strictly limited to the signals available on the interface cable?

I do not want to modify the electronics at all.

Quote
What about power and mechanical constrains, such as, do you plan to install an LCD panel in the original unit replacing the CRT? If so, the output format will be further limited by the resolution and size of available LCD panels.

I do intend to rip out the old display and replace it. The LCD panel that I have found seems to be the perfect size. The original display was about 10" diagonal with 8" of actual display. I am replacing this with a 16:9 10.1" LCD display running in 4:3 mode (black bars).

Quote
Line doubling works. True. But does the line-doubled video exactly what you wanted from the beginning? How much off is it from the industrial-standard VGA? What will the picture look like on an LCD panel installed in the original chassis, if that's your goal? If you need more than the most basic image scaling, there are at least 20 different algorithms, and someone developed a program that allows you to compare them side-by-side.
Although it's not quite what I wanted from the beginning (non-standard video signal rather than true VGA), I think that it is just because I did not understand exactly how VGA worked. Also, could you specify what you mean by the image scaling thing? A link to the program you are talking about for example.

I appreciate your thoughts!!!
Read about my stuff at: projects.matthollands.com
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #31 on: August 01, 2017, 04:56:39 pm »
With a 10.1" 16:9 panel you are most likely dealing with LVDS or more advanced interface. Also part of the active display area that falls into the CRT viewing window could end up with X and Y pixel counts not integer multiples of the CRT pixel count. For instance, you may need to scale the 500x240 CRT image to something like 1170x760 to fill up the window just right. Now you'll need an image scaling algorithm that fits your expectations of complexity and image quality.

The software (open source) I talked about is at:
https://code.google.com/archive/p/2dimagefilter/
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 3287
  • Country: 00
Re: FPGA video format conversion
« Reply #32 on: August 02, 2017, 01:19:44 am »
Indeed, directly interfacing a LVDS LCD is not a piece of cake.  It's more difficult and complex than interfacing  old 5" STN LCDs and modern TFT little 4.3"-5" LCDs by five orders of magnitude at least.

I suggest you to interface a VGA-LCD, thus you have to deal only with VGA signals.
the Bunker is open!
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #33 on: August 02, 2017, 01:31:11 am »
The display I am buying does come with a VGA controller board so I will be using VGA
Read about my stuff at: projects.matthollands.com
 

Offline marshallh

  • Supporter
  • ****
  • Posts: 1458
  • Country: us
    • retroactive
Re: FPGA video format conversion
« Reply #34 on: August 03, 2017, 01:41:52 pm »
LVDS is trivial as long as your fpga supports serialization (and basically all do). The hardest part is packing your bits into the laneformat. It's 100% identical to parallel RGB apart from that. I converted a design in 30mins and it worked second try.
Verilog tips
BGA soldering intro

11:37 <@ktemkin> c4757p: marshall has transcended communications media
11:37 <@ktemkin> He speaks protocols directly.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 15258
  • Country: nl
    • NCT Developments
Re: FPGA video format conversion
« Reply #35 on: August 04, 2017, 01:04:14 am »
LVDS is trivial as long as your fpga supports serialization (and basically all do). The hardest part is packing your bits into the laneformat. It's 100% identical to parallel RGB apart from that. I converted a design in 30mins and it worked second try.
The easiest option is to use a Serdes chip from (for example) TI which converts parallel RGB + sync into an LVDS stream.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #36 on: September 21, 2017, 08:15:21 am »
Ok so I have since bought the display I am going to use.

Unfortunately, when I line double to signals from the logic analyser, it takes up only a small portion of the screen. (see attachment) The monitor is locking onto a 1280x768 resolution.

It looks like the original pixel frequency of the logical analyser is about 17.375MHz with a line time of 40us. It looks like simple line doubling won't get me a reasonable image. I may have to resort to buffering the frame and outputting at a different resolution.
« Last Edit: September 21, 2017, 08:20:07 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #37 on: September 21, 2017, 08:00:44 pm »
For vertical, It looks like you might have the space for line trippling.  Depending on how the original scope centers it's raster image, you will loose a few lines.

As for multiplying the vertical by 2.5x, you will need 5 lines of video cache to do this, but with monochrome, you should have space in your FPGA.  Not when scaling by a fraction, you need shades of grey on the output for a smear effect. 

For the horizontal, drive the LCD with a full 1280 pixels, but, for the TVP sampler, you can cheat by changing the horizontal PLL to sample more pixels than there actually are.  This will horizontally stretch the image by any number you like.  HOWEVER, for this to look good, you will need to set the TVP ADC to it's lowest RGB bandwidth filter setting (this softens the edges making a simulated filtered scale) and you will want at least 16 shades of grey support when imputing and outputting your video signal to get soft anti-aliased rounded edges on your pixels.  Otherwise, you will need to do this horizontal scale in FPGA code which isn't too terible since you scaling factor is fixed, but, it now becomes a question of configuring your PLL to multiply by 5, divide by 2.
__________
BrianHG.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #38 on: September 21, 2017, 08:06:33 pm »
With the scoped video output, how many lines of video actually has video content.  If it is only 240 of them, multiplying each line coming in by 3 gives you 720.  You will only have an extra 24 lines on the top and 24 line on the bottom of you LCD display.  This would be fairly good.  If your LCD screen is a 1280x720, this would fill out perfectly.

But, it your output picture is 384 lines, 25Khz x 416 lines = 60hz.  416 lines - 384 = 32 lines, 6 lines for v-front porch, 6 for v-sync, 20 for v-back-porch (These figures sound about right), then on your double, you need to double 384 lines, not 240 lines and your LCD should fill the picture completely vertically.  384x2=768 active lines of video.  Note that 512x384 is a natural old VGA video mode.
« Last Edit: September 21, 2017, 08:15:56 pm by BrianHG »
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
FPGA video format conversion
« Reply #39 on: September 21, 2017, 10:08:37 pm »
I have yet to try the 2.5x multiply, but won't be able to do so for a few days.

I tried the 3x multiply and the display now locks onto a 1280x960 video and so it no longer fills the display  |O. (see attached)

The screen's native resolution is 1024x600, so the 2.5x might work nicely. (the original resolution is 500x240)
« Last Edit: September 21, 2017, 10:27:21 pm by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #40 on: September 22, 2017, 02:39:14 pm »
I have yet to try the 2.5x multiply, but won't be able to do so for a few days.

I tried the 3x multiply and the display now locks onto a 1280x960 video and so it no longer fills the display  |O. (see attached)

The screen's native resolution is 1024x600, so the 2.5x might work nicely. (the original resolution is 500x240)

Ohhhhhhh, 1024x600, that's an oddball...  500x240 at 2.5x Y res would scale great.  Here is the trick:

Source video:  Fill these 4 in sequence...
Line buffer1
Line buffer2
Line buffer3
Line buffer4
loop...

Video output sequence, delayed after 3 previous line buffers have been filled.
Show Line buffer1
Show Line buffer1
Show Line buffer2
Show Line buffer2
Show Line buffer2 averaged with Line buffer3  (Just add the 7LSB of each buffer together to get a new 8 bit sum)
Show Line buffer3
Show Line buffer3
Show Line buffer4
Show Line buffer4
Show Line buffer4 averaged with Line buffer1
.....
You get the point...

If you use this cheap average trick, this will give you nice sharp, but still rounded edges on the odd half extra lines.
Without the average, it will be a little chunky in places.

A smooth linear transformation process is possible, but, you will need (for monochrome) 3x2 multiply add with a rotating 5 sets of 3 factor table  (this can be calculated on the fly, but there is only 15 of them.  Putting these 3x5 numbers in a table rom would work best as you can play with them).  This one is the smoothest, but, eats up HW multipliers in the FPGA.  The coefficients in the table will control the vertical sharpness, giving you a linear filter, or cubic filter, or a hard sharp pixel clump filter.
« Last Edit: September 22, 2017, 02:48:13 pm by BrianHG »
__________
BrianHG.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #41 on: September 22, 2017, 02:47:26 pm »
I'm glad you are still working on this project even though you won that Oscilloscope in the contest from Dave.
__________
BrianHG.
 
The following users thanked this post: MattHollands

Online ebastler

  • Super Contributor
  • ***
  • Posts: 1980
  • Country: de
Re: FPGA video format conversion
« Reply #42 on: September 23, 2017, 12:34:44 am »
The screen's native resolution is 1024x600, so the 2.5x might work nicely. (the original resolution is 500x240) ´

Yes -- but how do you actually convince the display to work at its native resolution? When you tried 2x scaling (in X and Y, I assume) in your post further above, you mentioned that the display scaled to 1280*768 -- although 1024*600 should have worked nicely to display that?! 

Worth a try to use 2x scaling horizontally and 2.5x vertically. But the display might still have its own ideas about the mode it sets?
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
FPGA video format conversion
« Reply #43 on: September 23, 2017, 12:46:58 am »
The screen's native resolution is 1024x600, so the 2.5x might work nicely. (the original resolution is 500x240) ´

Yes -- but how do you actually convince the display to work at its native resolution? When you tried 2x scaling (in X and Y, I assume) in your post further above, you mentioned that the display scaled to 1280*768 -- although 1024*600 should have worked nicely to display that?! 

Worth a try to use 2x scaling horizontally and 2.5x vertically. But the display might still have its own ideas about the mode it sets?
Yep I agree it might be an issue. I will have to try it to see what it locks onto but I am away for a few days
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #44 on: September 23, 2017, 12:49:45 am »
I'm glad you are still working on this project even though you won that Oscilloscope in the contest from Dave.
this has always been more of a learning project and this logic analyzer/scope has features that the rtb2004 doesn't anyway e.g. 50 ohm input, 64 channel logic analyzer etc
Read about my stuff at: projects.matthollands.com
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 11507
  • Country: gb
    • Mike's Electric Stuff
Re: FPGA video format conversion
« Reply #45 on: September 23, 2017, 04:28:06 am »
Something that may be worth a try is a simplistic method using a single dual-port BRAM  framebuffer.
You will probably get some tearing artifacts as the output frame will sometimes contain elements from multiple source frames, but it may be acceptable, at least as a first attempt.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #46 on: September 23, 2017, 07:18:24 am »
Something that may be worth a try is a simplistic method using a single dual-port BRAM  framebuffer.
You will probably get some tearing artifacts as the output frame will sometimes contain elements from multiple source frames, but it may be acceptable, at least as a first attempt.

If the current approach of keeping the input and output frames in sync doesn't work then I'll probably resort to using a frame buffer. I am prototyping on a Xilinx Artix-7 FPGA  dev board which will have enough BRAM for multiple frames, but I plan to use a Lattice MachXO for the final design to save on cost (of the programmer and the FPGA) which only has enough BRAM for a few lines. However, with a pixel clock of ~17.375MHz I can probably get away with only two (if not one)  £0.50 SPI RAMs to handle the frame buffers.
« Last Edit: September 23, 2017, 07:20:33 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #47 on: September 23, 2017, 07:36:14 am »
It may also be possible to compress the frames using RLE seeing as there are so few colours and each line generally only has a few colour transitions.
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #48 on: September 26, 2017, 11:05:38 pm »
For vertical, It looks like you might have the space for line trippling.  Depending on how the original scope centers it's raster image, you will loose a few lines.

As for multiplying the vertical by 2.5x, you will need 5 lines of video cache to do this, but with monochrome, you should have space in your FPGA.  Not when scaling by a fraction, you need shades of grey on the output for a smear effect. 

For the horizontal, drive the LCD with a full 1280 pixels, but, for the TVP sampler, you can cheat by changing the horizontal PLL to sample more pixels than there actually are.  This will horizontally stretch the image by any number you like.  HOWEVER, for this to look good, you will need to set the TVP ADC to it's lowest RGB bandwidth filter setting (this softens the edges making a simulated filtered scale) and you will want at least 16 shades of grey support when imputing and outputting your video signal to get soft anti-aliased rounded edges on your pixels.  Otherwise, you will need to do this horizontal scale in FPGA code which isn't too terible since you scaling factor is fixed, but, it now becomes a question of configuring your PLL to multiply by 5, divide by 2.

Unfortunately, when I 2.5x the image, the resolution switches to a 1280x960 resolution (see attachment).

I discovered that I can do full 1024x600 (native resolution) with a clock of 48.875MHz from this document: https://www.kernel.org/doc/Documentation/fb/viafb.modes
This is obviously not a nice multiple of the 17.375MHz clock of the original image and so will eventually go out of sync. I can change the clock to be 48.65MHz (2.8x) and the display will lock on, but we are no longer at 60Hz frame rate so will loose sync. Adjusting the length of the porches to make it 60Hz causes the display to detect a weird resolution.

At this point, I think my best bet is to use two completely separate clock domains and a frame buffer in between. Sure, line doubling (or whatever) may WORK, but it won't give me the best image.
Read about my stuff at: projects.matthollands.com
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #49 on: September 27, 2017, 05:44:49 am »
Because you have an LCD driver board in between, you may or may not be able to use the native resolution of the LCD panel. It depends on what formats are pre-programmed in the driver board. You can generate an LCD panel native timing with the FPGA and give it a try.

I would ditch the LCD driver board and drive the panel directly with FPGA. I don't trust its scaler to give the best result, nor do I like the automatic detection and adaptation of video timings from the LCD driver board.

If you look at the LCD datasheet, the clock frequency is not strict (it has an acceptable range), the horizontal and vertical timing are not strict, either. With that flexibility you may be able to get away with frame buffer. Just need to do your math and find out. You loose that flexibility to a certain extent because the LCD driver board may apply additional restrictions.

Like I said, you should fully know your input, set a firm target for your output, and then work on the implementations to bridge the input and the output. It seems now you are limited by the choice of implementation and as a result have an ever changing output target. Well, that may be what most hobby projects look like.

 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #50 on: September 27, 2017, 02:16:33 pm »
Question:  Are you sure your video output pattern you are generating actually covers the video output.  Could there be a bug in your FPGA code.  Have you tried sending your video output to another screen.  If it's analog VGA, it should work on other monitors for testing...

Can you provide us a scope-shot from v-sync to v-sync of your video out and h-sync.
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #51 on: September 27, 2017, 10:00:26 pm »
Pretty sure everything is all good with the code.

Captures of the HP1662AS video signals (captured straight from the device) can be found about halfway down the page: projects.matthollands.com/2017/09/18/project-crt-oscilloscope-lcd-mod-calculating-video-timing/

The attachments are all captures from the output of my FPGA (to simulate the signals):
- 1x Line time = 40us,  h-sync = 3.23us
- 1x Zoom in
- 2x Line time = 20us, h-sync = 1.61us
- 2x Zoom in
- 2.5x Line time = 16us, h-sync = 1.21us
- 2.5 Zoom in
- 3x Line time = 13.333us, h-sync = 1.21us (this is inaccurate due to zoomed out time base)
 -3x Zoom in h-sync = 1.07us (accurate)

The v-sync and frame time all stay approximately constant.

For some reason the screen is now appearing to lock onto the 2.5x screen but not display it properly. 3x now seems to lock onto 1600x1200. Either way, I'm pretty sure I am generating ok signals.
« Last Edit: September 27, 2017, 10:51:14 pm by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #52 on: September 27, 2017, 11:07:52 pm »
Question:  Are you sure your video output pattern you are generating actually covers the video output.  Could there be a bug in your FPGA code.  Have you tried sending your video output to another screen.  If it's analog VGA, it should work on other monitors for testing...

Can you provide us a scope-shot from v-sync to v-sync of your video out and h-sync.

I just tested the signals on an oldish hp monitor:
HP1662AS signals - doesn't lock on
2x - 1280x800
2.5x - 1280x1024
3x - 1600x1200

Meanwhile, the 10.1" panel:
HP1662AS signals - doesn't lock on
2x - 1280x768
2.5x - ??? Seems to lock but doesn't display anything?!
3x - 1600x1200
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #53 on: September 28, 2017, 03:25:49 am »
Arrrg, on your scope shots, your missing a trace with the analog video.  I am unable to tell if when your actual picture starts vertically and ends vertically...
Ok, found it on your website link...

Now, your sync is only 3.3v.  A lot of monitors will fail to lock on this unless it is 5v level.  Of, they might manage to occasionally sync in and out...

Also, especially for trying to get the native mode on your main screen, sometimes the sync polarity needs to be positive (inverted).  Some monitors demand this if you want to access a preset mode.  This may mean inverting just the horizontal, or vertical, or both syncs.

As for your sync pattern, it looks fine, but, to improve it a little, latch the VS signal with each initial HS signal transition.  This will make the VS activate and de-activate at the same time as next HS signal transition.  This is not important for CRTs, but may affect some more modern LCD screen's power saving sleep mode...


Ok, I see what's going on on your website, your scope's video output has an astronomically huge equal v-front/back_porch of 87 lines each!  The v-sync pulse of 3 lines is normal.

However, your scope-shot from the source doesn't seem to reflect this figure.  Can you do me the favor and look at the video output and count the number of h-syncs between the last line of video and the beginning of the V-sync, then, the number of h-syncs during the v-sync, then, the number of h-syncs between the end of the v-sync and the first line with active video.

« Last Edit: September 28, 2017, 04:08:50 am by BrianHG »
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
FPGA video format conversion
« Reply #54 on: September 28, 2017, 04:36:07 am »
Arrrg, on your scope shots, your missing a trace with the analog video.  I am unable to tell if when your actual picture starts vertically and ends vertically...
Ok, found it on your website link...

Now, your sync is only 3.3v.  A lot of monitors will fail to lock on this unless it is 5v level.  Of, they might manage to occasionally sync in and out...

Also, especially for trying to get the native mode on your main screen, sometimes the sync polarity needs to be positive (inverted).  Some monitors demand this if you want to access a preset mode.  This may mean inverting just the horizontal, or vertical, or both syncs.

As for your sync pattern, it looks fine, but, to improve it a little, latch the VS signal with each initial HS signal transition.  This will make the VS activate and de-activate at the same time as next HS signal transition.  This is not important for CRTs, but may affect some more modern LCD screen's power saving sleep mode...


Ok, I see what's going on on your website, your scope's video output has an astronomically huge equal v-front/back_porch of 87 lines each!  The v-sync pulse of 3 lines is normal.

However, your scope-shot from the source doesn't seem to reflect this figure.  Can you do me the favor and look at the video output and count the number of h-syncs between the last line of video and the beginning of the V-sync, then, the number of h-syncs during the v-sync, then, the number of h-syncs between the end of the v-sync and the first line with active video.

Getting a 5V sync is a bit difficult, but for reasonable formats I haven't seen any monitors fail to lock (I've tried maybe 4 displays at some point).

Ill try doing some inverting of h-sync and v-sync.

I can count the h syncs. Do you mean on the original video source?

The huge front and back porches may explain why so much of the CRT isn't used. There is maybe 3/8th" of unused (black) display either side of the display area.

So does the display use the video signal as well as the syncs to lock onto the signal? Surely it can't because otherwise it would be unable to display a fully (or mostly) black image since there would be no video data to lock onto.
« Last Edit: September 28, 2017, 04:39:43 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #55 on: September 28, 2017, 06:31:13 am »
BrianHG is right. You need to get a better idea of the original video signal.

For starters, it is NOT OK to arbitrarily guess the pixel clock frequency. Getting an accurate pixel clock is vital for a properly sampled original video and will in turn significantly affect the quality of converted video. Your final solution doesn't tap into the pixel clock from the original circuit, that doesn't mean you don't need to know its exact frequency. In other word, to get an accurate H_TOTAL is as important as H_VISIBLE.

And everything else should be measured in pixel clock counts. Don't guess, measure. How do you know the exact pixel count of front and back porch? You need to find the DE (data enable) signal in the original circuit, sometimes disguised as 'Blanking'. Compare DE with hsync you get accurate count of H front and back porch, and same for V front and back porch. From the scope capture it doesn't seem that you have a symmetrical V front and back porch, how can you assume they have the same line count?

Another big misconception: Line doubler doesn't mean you have half the pixel count per line and double the line count while keeping the pixel clock the same. It means you double the pixel clock and line count while maintaining the same pixel count per line.

Personally I found a frequency counter works better than DSO when measuring the video timing, especially two-channel models that counts A by B and measures TI A to B. Obviously you have one of the latest scopes that would be better than scopes from 10, 20 years ago.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
FPGA video format conversion
« Reply #56 on: September 28, 2017, 06:42:22 am »
BrianHG is right. You need to get a better idea of the original video signal.

For starters, it is NOT OK to arbitrarily guess the pixel clock frequency. Getting an accurate pixel clock is vital for a properly sampled original video and will in turn significantly affect the quality of converted video. Your final solution doesn't tap into the pixel clock from the original circuit, that doesn't mean you don't need to know its exact frequency. In other word, to get an accurate H_TOTAL is as important as H_VISIBLE.

And everything else should be measured in pixel clock counts. Don't guess, measure. How do you know the exact pixel count of front and back porch? You need to find the DE (data enable) signal in the original circuit, sometimes disguised as 'Blanking'. Compare DE with hsync you get accurate count of H front and back porch, and same for V front and back porch. From the scope capture it doesn't seem that you have a symmetrical V front and back porch, how can you assume they have the same line count?

I am NOT guessing. I measured the video signal and divided it by the horizontal resolution (from the service manual) to get the pixel clock. Don't know why you think I guessed it. 17.375MHz.

If you're being confused by the article, that was using an arbitrary clock frequency because there is no need to be exact when im not actually sending any video signal.

I am using a chip (TVP7002) that is designed for pixel clock reconstruction from the sync signals. You don't need to tap into the original clock - computer monitors/tvs manage not to.

Quote


Another big misconception: Line doubler doesn't mean you have half the pixel count per line and double the line count while keeping the pixel clock the same. It means you double the pixel clock and line count while maintaining the same pixel count per line.


I know. To get double the lines I use double the pixel frequency and then double all of the vertical timings.

The input video is fully characterized (you are right about the porches not being totally equal - overlooked that).The problem is transforming it to a signal that the LCD will recognize and display reasonably. (although at this point I still plan to just use a frame buffer and two separate clock domains).
« Last Edit: September 28, 2017, 06:49:19 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #57 on: September 28, 2017, 07:34:25 am »

I am NOT guessing. I measured the video signal and divided it by the horizontal resolution (from the service manual) to get the pixel clock. Don't know why you think I guessed it. 17.375MHz.

If you're being confused by the article, that was using an arbitrary clock frequency because there is no need to be exact when im not actually sending any video signal.
Yep, that's what your article said:
Quote
It turns out that we don’t actually care what the pixel clock is as long as the v-sync and h-sync pulses are the correct length and at the correct intervals. This is because the display locks onto a signal using only the h-sync and v-sync pulses.

Quote
I am using a chip (TVP7002) that is designed for pixel clock reconstruction from the sync signals. You don't need to tap into the original clock - computer monitors/tvs manage not to.

The TVP7002 will not magically figure out what your pixel clock frequency is. You still need to program it. Assuming your line time (40us) and pixel frequency (17.375MHz) are correct, you'll need to program the TVP7002 with a 695 HSYNC to pixel clock ratio.

Quote
I know. To get double the lines I use double the pixel frequency and then double all of the vertical timings.

That's not what you said in the article. Your 'original' video has H_TOTAL=800 and your 'line doubled' video has H_TOTAL=400.


Quote
The input video is fully characterized (you are right about the porches not being totally equal - overlooked that).The problem is transforming it to a signal that the LCD will recognize and display reasonably. (although at this point I still plan to just use a frame buffer and two separate clock domains).

I agree, but in a different sense. The problem is that you are trying to get to a signal that your LCDs will recognize and display reasonably, (seemingly) without the detailed specs of what your LCD driver board is capable of. Instead, I think you should try to get to a signal that conforms to a common standard (VESA compliant for instance), then all the displays are supposed to display it properly.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #58 on: September 28, 2017, 08:25:43 am »
Ignore that article except for the captures that I referenced - I am going to update it with newer information.... I really messed up a lot of these measurements  |O So here I will go through characterising the signal. Attached are the 8 measurements I took.

1. Measured line video time = 28.8016us. Assuming 500px visible as stated in the datasheet (also look about right by measuring) -> pixel clock = 17.36MHz
2. Measured horizontal front porch = 1.0312us -> h-front-porch = 18
3. Measured horizontal back porch = 6.9776us -> h-back-porch = 121
4. Measured horizontal sync = 3.202us -> h-sync = 56 (although this doesn't divide well)
H_TOTAL = 695 or 40us
5. Measured frame video time = 15.1093 -> 378 lines (this is much more than the datasheet stated 240!)
6. Measured vertical front porch = 441.04us -> v-front-porch = 11
7. Measured vertical back porch = 1.01021ms -> v-back-porch = 25
8. Measured v-sync = 120.002us -> v-sync = 3
V_TOTAL = 417 or 16.68ms
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #59 on: September 28, 2017, 10:10:34 am »
I have now implemented the new measurements on the FPGA and here are the captures of the output: (note that the video signal is way higher because we depend on the 75ohm termination to pull the voltage down to 0.7v)

1. Line video time = 28.800us instead of 28.8016us ->
2. Horizontal front porch = 1.040us instead of 1.0312us
3. Horizontal back porch = 6.950us instead of 6.9776us
4. Horizontal sync = 3.219us instead of 3.202us
5. Frame video time = 15.1218ms instead of 15.1093ms
6. Vertical front porch = 441.42us instead of 441.04us
7. Vertical back porch = 1.01105ms instead of 1.01021ms
8. Vertical sync = 120.115us instead of 120.002us

This seems within margin of error of oscillators etc.

Sorry for my previous mistakes with characterising the signal.
« Last Edit: September 28, 2017, 10:14:54 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #60 on: September 28, 2017, 10:29:02 am »
Since your measured active line count (378 lines) is much more than the datasheet stated 240, why don't you suspect that the datasheet stated 500 pixels may not be correct, either?

It is worth noting that the video image may have black borders around the display image. Comparing the video signal to the sync is not a bullet-prof method to determine the front and back porches. As a result the H_total could be off. My advise would be to find the actual, physical pixel clock and DE signals in your machine. That way you can be sure. There may or may not be surprises, but it is better to find out earlier than later.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #61 on: September 28, 2017, 10:34:41 am »
Since your measured active line count (378 lines) is much more than the datasheet stated 240, why don't you suspect that the datasheet stated 500 pixels may not be correct, either?

It is worth noting that the video image may have black borders around the display image. Comparing the video signal to the sync is not a bullet-prof method to determine the front and back porches. As a result the H_total could be off. My advise would be to find the actual, physical pixel clock and DE signals in your machine. That way you can be sure. There may or may not be surprises, but it is better to find out earlier than later.

The reason I suspect that the 500 pixels is correct is that when I measure pixels per mm, and measure the whole screen, it comes out as ~500 pixels. I agree its not a very accurate method.

The black borders (whether or not they are there) would be present all the time (the size of the screen never changes and always has a white background), so it's not really any different to having larger porches. I agree this is an assumption that could theoretically not be true, but for now I am willing to risk it.
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #62 on: September 28, 2017, 10:42:01 am »
Ignore that article except for the captures that I referenced - I am going to update it with newer information.... I really messed up a lot of these measurements  |O So here I will go through characterising the signal. Attached are the 8 measurements I took.

1. Measured line video time = 28.8016us. Assuming 500px visible as stated in the datasheet (also look about right by measuring) -> pixel clock = 17.36MHz
2. Measured horizontal front porch = 1.0312us -> h-front-porch = 18
3. Measured horizontal back porch = 6.9776us -> h-back-porch = 121
4. Measured horizontal sync = 3.202us -> h-sync = 56 (although this doesn't divide well)
H_TOTAL = 695 or 40us
5. Measured frame video time = 15.1093 -> 378 lines (this is much more than the datasheet stated 240!)
6. Measured vertical front porch = 441.04us -> v-front-porch = 11
7. Measured vertical back porch = 1.01021ms -> v-back-porch = 25
8. Measured v-sync = 120.002us -> v-sync = 3
V_TOTAL = 417 or 16.68ms

This is beginning to make more sense.  However, 417 line total -3 (normal) -11 (normal) -25 (normal) = 378.  This is still not standard vertical video mode, however, 423 lines -3 -11 -25 = 384.  This is a standard and still 59hz.  In fact, both 512x384@60hz and 640x384@60hz is an old, but standard Vesa VGA mode from the 80s...  You have obviously timed your syncs on your scope.  (These nasty things time better with a real frequency counter...)  I am not saying there is an error here, may this weird video mode is correct, but, do you have the ability to count the h-syncs from vs-vs through a counter?

Updating your video output raster specs, to double these new ones, do you fill your LCD more completely?
Also, when doing this, you don't need to yet, but, should clock at double frequency.
512x384 doubled to 1024x768 should fill your display completely.
« Last Edit: September 28, 2017, 10:44:24 am by BrianHG »
__________
BrianHG.
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #63 on: September 28, 2017, 11:10:51 am »

The reason I suspect that the 500 pixels is correct is that when I measure pixels per mm, and measure the whole screen, it comes out as ~500 pixels. I agree its not a very accurate method.

The black borders (whether or not they are there) would be present all the time (the size of the screen never changes and always has a white background), so it's not really any different to having larger porches. I agree this is an assumption that could theoretically not be true, but for now I am willing to risk it.

I guess you still don't get it why it is so important to nail down the actual pixel clock, H_ACTIVE and H_TOTAL to the last bit of accuracy (perfect integer multiples of pixel clock cycle that is). You have realized that the measured HSYNC width doesn't divide well by the calculated pixel clock cycle. That's a sign. You either measured the HSYNC wrong, or calculated the pixel clock wrong, or both.

In case this might help you reconsider: I've done some video conversion from CRT to LCD on old HP gear, and am in the process of doing more (not including the 166x series, though).
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #64 on: September 28, 2017, 11:29:04 am »
Ignore that article except for the captures that I referenced - I am going to update it with newer information.... I really messed up a lot of these measurements  |O So here I will go through characterising the signal. Attached are the 8 measurements I took.

1. Measured line video time = 28.8016us. Assuming 500px visible as stated in the datasheet (also look about right by measuring) -> pixel clock = 17.36MHz
2. Measured horizontal front porch = 1.0312us -> h-front-porch = 18
3. Measured horizontal back porch = 6.9776us -> h-back-porch = 121
4. Measured horizontal sync = 3.202us -> h-sync = 56 (although this doesn't divide well)
H_TOTAL = 695 or 40us
5. Measured frame video time = 15.1093 -> 378 lines (this is much more than the datasheet stated 240!)
6. Measured vertical front porch = 441.04us -> v-front-porch = 11
7. Measured vertical back porch = 1.01021ms -> v-back-porch = 25
8. Measured v-sync = 120.002us -> v-sync = 3
V_TOTAL = 417 or 16.68ms

This is beginning to make more sense.  However, 417 line total -3 (normal) -11 (normal) -25 (normal) = 378.  This is still not standard vertical video mode, however, 423 lines -3 -11 -25 = 384.  This is a standard and still 59hz.  In fact, both 512x384@60hz and 640x384@60hz is an old, but standard Vesa VGA mode from the 80s...  You have obviously timed your syncs on your scope.  (These nasty things time better with a real frequency counter...)  I am not saying there is an error here, may this weird video mode is correct, but, do you have the ability to count the h-syncs from vs-vs through a counter?

Updating your video output raster specs, to double these new ones, do you fill your LCD more completely?
Also, when doing this, you don't need to yet, but, should clock at double frequency.
512x384 doubled to 1024x768 should fill your display completely.

I used the frequency measurement on my scope to find the frequency of the vs and the hs and they almost perfectly divide into eachother by 417. To get 423 instead would be quite a margin of error.

Doubling the clock frequency and doubling the v-parameters the display does lock on and I am able to fill most of the display by twiddling the clock, phase, vertical and horizontal parameters on the display. But unfortunately now it overflows the display!
« Last Edit: September 28, 2017, 11:31:12 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #65 on: September 28, 2017, 11:34:24 am »

The reason I suspect that the 500 pixels is correct is that when I measure pixels per mm, and measure the whole screen, it comes out as ~500 pixels. I agree its not a very accurate method.

The black borders (whether or not they are there) would be present all the time (the size of the screen never changes and always has a white background), so it's not really any different to having larger porches. I agree this is an assumption that could theoretically not be true, but for now I am willing to risk it.

I guess you still don't get it why it is so important to nail down the actual pixel clock, H_ACTIVE and H_TOTAL to the last bit of accuracy (perfect integer multiples of pixel clock cycle that is). You have realized that the measured HSYNC width doesn't divide well by the calculated pixel clock cycle. That's a sign. You either measured the HSYNC wrong, or calculated the pixel clock wrong, or both.

In case this might help you reconsider: I've done some video conversion from CRT to LCD on old HP gear, and am in the process of doing more (not including the 166x series, though).

Ok, if I get some time on the weekend, I may be able to find some time to dig around inside the HP. Do you have any recommendations to help me find the pixel clock, etc? I've never been able to find schematics for this thing.

[edit] Oh hey, the service manual tells me that it uses a National Semiconductor LM1882CM, so I can look at the blanking pins on that, and the clock going into it to figure out the timing [/edit]
« Last Edit: September 28, 2017, 11:45:23 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #66 on: September 28, 2017, 11:46:07 am »
I assumed you would have the TVP chip by now.  Yes, for a pixel perfect 1:1 pixel capture, you need the true H-pixel clock values.  However, since you will be squeezing or stretching the picture horizontally, we might cheat here by oversampling with the TVP and using it's low pass filter to create an approximate analog display.  I was going to guide you on the trick to getting these values out of the chip...

But, this wont work for the vertical.  You need the exact active lines, and their positions.  Unless you already have the hardware to measure this down to the dot, you cannot rely on the scope's timing here.  Even my 25k$ Techtronix scopes fails at these tasks compared to a frequency counter which is why frequency counters still sell.

Yes, @simmconn is correct, assuming you need the perfect dot-dot capture, but, you can cheat a little here and still get a perfectly good looking picture since your source is low res and we can oversample enough and have enough shades of grey to make a smooth final result.  This still doesn't mean you can go for perfection, you just may not fill your panel horizontally perfectly.  This will be up to you since trying both is easy enough.

Note that you can adjust you horizontal and vertical position by changing the front and back porch on you FPGA video output.  This is safe as long as the total number of lines/pixels from front to back remains constant.  Do not worry about the alignment in the scopes video output.  The TVP has a programmable active video sampling window region which you set to shift it's picture coming into your line buffer and you will generate your video output sync based on an programmable offset of that signal.  As long at the total lines and total pixels match a multiple of the total lines and total pixels coming out of the TVP, you can shift you active video region as needed to center the image on the LCD if the LCD's internal adjustments cant go all the way to the edge...
« Last Edit: September 28, 2017, 11:53:13 am by BrianHG »
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #67 on: September 28, 2017, 11:54:24 am »
I assumed you would have the TVP chip by now.  Yes, for a pixel perfect 1:1 pixel capture, you need the true H-pixel clock values.  However, since you will be squeezing or stretching the picture horizontally, we might cheat here by oversampling with the TVP and using it's low pass filter to create an approximate analog display.  I was going to guide you on the trick to getting these values out of the chip...

But, this wont work for the vertical.  You need the exact active lines, and their positions.  Unless you already have the hardware to measure this down to the dot, you cannot rely on the scope's timing here.  Even my 25k$ Techtronix scopes fails at these tasks compared to a frequency counter which is why frequency counters still sell.

Yes, @simmconn is correct, assuming you need the perfect dot-dot capture, but, you can cheat a little here and still get a perfectly good looking picture since your source is low res and we can oversample enough and have enough shades of grey to make a smooth final result.  This still doesn't mean you can go for perfection, you just may not fill your panel horizontally perfectly.  This will be up to you since trying both is easy enough.

Note that you can adjust you horizontal and vertical position by changing the front and back porch on you FPGA video output.  This is safe as long as the total number of lines/pixels from front to back remains constant.  Do not worry about the alignment in the scopes video output.  The TVP has a programmable active video sampling window region which you set to shift it's picture coming into your line buffer and you will generate your video output sync based on an offset of that signal.

The TVP and PCB are on their way now. Not sure how long before I'll have that up and running. I tried moving pixels from the back porch to the front porch to see if that would let me move the image, but the screen would not lock if I changed it even by one.
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #68 on: September 28, 2017, 12:03:30 pm »
In case this might help you reconsider: I've done some video conversion from CRT to LCD on old HP gear, and am in the process of doing more (not including the 166x series, though).

Out of interest, what approach did you go for? Line doubling, or frame buffer, or something different?

Btw, I appreciate all the help guys.
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #69 on: September 28, 2017, 12:10:40 pm »
I tried moving pixels from the back porch to the front porch to see if that would let me move the image, but the screen would not lock if I changed it even by one.

This does not sound right.  In fact, if the H-total and V-total remain constant as well as the H-sync and v-sync, the image should always stay locked...

Can I see the source code of your sync generator....
__________
BrianHG.
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #70 on: September 28, 2017, 01:21:15 pm »
For the existing designs I've been lucky and didn't need frame buffer. The ones in the pipeline need frame buffer.

Thanks for the pointers (re: LM1882CM). It turns out the 166xC uses BT475 RAMDAC, which is theoretically supported by my existing design. Not sure about the 166xAs, though. HP often has significantly different display subsystems between the A, B and Cs of the same product family.

I've been tapping into the digital signals in the original video circuit as much as possible in order to get a clean picture and avoid D/A and A/D altogether. It also helps color remapping. Apparently you chose a different approach, which would work as well. I just wanted to let you know what I leaned to be important during the development. Getting to the bottom of the original video timing is a start.

I sort of disagree with BrianHG in that I think sharpness (clarity) is more important in the line-art type of image from the test equipment, rather than smoothness. So I'd rather get the original picture as accurately as possible, and let the scaling process mess up the sharpness as little as possible.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #71 on: September 28, 2017, 02:53:03 pm »

I sort of disagree with BrianHG in that I think sharpness (clarity) is more important in the line-art type of image from the test equipment, rather than smoothness. So I'd rather get the original picture as accurately as possible, and let the scaling process mess up the sharpness as little as possible.

Yes, but scaling still must be done if you want to project the original scope's 500 X-pixels onto a panel with 1280 X-pixels.  Unless you want a black border of 140 pixels on the left and right.  Converting 500 to 1280 is not a fixed multiple by 2.  Doing a nearest neighbor pixel resize here will lead to fat and thin vertical chunk pattern.  Whether you scale this digitally, or with my analog trick, scaling up 500->1280 will always be wider than 2 pixels, in fact, it will be 2.56.  Adjusting this slightly to 2.5 pixels (500-1250 (tiny black border of only 15 pixels now)), this means 2 pixels are a direct copy and every alternating second 2 pixels, you insert a 50/50 blend of the 2 in between pixels will still be a fully sharp yet less than an absolute chunky upsample.  I am not talking about doing a fancy full bi-cubic X-Y 16 to 256 tap filtering with an adaptive filter radius making a nice soft broadcast video production style scale.  He doesn't have the gate-count for that anyways, well,,, maybe since it is monochrome and so low res, but this is not the point.

We still don't know if his scope's output is truly 500 pixels VS 512 or even 640 (perfect 2:1 for this guy, no fancy filtering...).  I have a funny feeling that the quoted specs he used from the scope's user manual may just be the scope grid and center video output while the extra spare space listed in the back&front porch may contains the menu text items as we seen the video goes beyond the original specs found in MattHollands latest scope shots.
« Last Edit: September 28, 2017, 03:03:28 pm by BrianHG »
__________
BrianHG.
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #72 on: September 28, 2017, 04:48:37 pm »
I am not talking about doing a fancy full bi-cubic X-Y 16 to 256 tap filtering with an adaptive filter radius making a nice soft broadcast video production style scale.  He doesn't have the gate-count for that anyways, well,,, maybe since it is monochrome and so low res, but this is not the point.

The FPGA he uses has more than enough resources to do a fancy scaler. This is a learning experience. Let's see what he comes up with.

Quote
We still don't know if his scope's output is truly 500 pixels VS 512 or even 640 (perfect 2:1 for this guy, no fancy filtering...).  I have a funny feeling that the quoted specs he used from the scope's user manual may just be the scope grid and center video output while the extra spare space listed in the back&front porch may contains the menu text items as we seen the video goes beyond the original specs found in MattHollands latest scope shots.

I found a 1662C in my stash tonight which I forgot how much I paid for. Well, it powers up with a good picture and I was able to take some measurement on the video part. You are exactly right, that the '500x240' in the datasheet oscilloscope section describing the waveform display window, is not the resolution of the entire picture. Assuming the 1662C has the same video timing as the 1662A, he had most of the timing right but not all. Let's see if he'll get to the right numbers, or like he said, it may not be that important for getting a converted picture.

Sadly my existing board doesn't fit the 1662C due to a stupid mechanical issue - it is not the first time that happens. Because of that I won't be working on it any time soon, if at all.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #73 on: September 28, 2017, 09:51:53 pm »
Can I see the source code of your sync generator....

Code: [Select]
module vga_control( CLK, //CLK input
                    ENABLE, //enable module
                    RESET, //resets device
                    VGA_CLK, //pixel clock for vga
                    VGA_X, //x position of vga
                    VGA_Y, //y position of vga
                    VGA_HS, //horizontal sync
                    VGA_VS, //vertical sync
                    VGA_VISIBLE, //are we in visible region
                    VGA_RED, //4 bit red colour
                    VGA_BLUE, //4 bit blue colour
                    VGA_GREEN); //4 bit green colour
                   
    input wire CLK, ENABLE, RESET;
    wire VGA_HS, VGA_VS, VGA_VISIBLE;
    output wire VGA_CLK, VGA_HS, VGA_VS, VGA_VISIBLE;
    output reg [11:0] VGA_X, VGA_Y;
    output wire [3:0] VGA_RED, VGA_BLUE, VGA_GREEN;
   
    //HP1662AS PARAMETERS (17.36MHz clock)
    parameter H_TOTAL = 695;
    parameter H_SYNC_PULSE = 56;
    parameter H_VISIBLE = 500;
    parameter H_FRONT_PORCH = 18;
    parameter H_BACK_PORCH = 121;
    parameter V_TOTAL = 417;
    parameter V_VISIBLE = 378;
    parameter V_SYNC_PULSE = 3;
    parameter V_FRONT_PORCH = 11;
    parameter V_BACK_PORCH = 25;
   
    //Line doubled (34.720MHz clock)
    /*parameter H_TOTAL = 695;
    parameter H_SYNC_PULSE = 56;
    parameter H_VISIBLE = 500;
    parameter H_FRONT_PORCH = 18;
    parameter H_BACK_PORCH = 121;
    parameter V_TOTAL = 834;
    parameter V_VISIBLE = 756;
    parameter V_SYNC_PULSE = 6;
    parameter V_FRONT_PORCH = 22;
    parameter V_BACK_PORCH = 50;*/
   
           
    //generate clock (change clock for different display modes)
    wire PLL_LOCKED;
   //generate vga clock
    clk_wiz_17360 vga_clk(  .clk_out1(VGA_CLK),
                             .reset(RESET),
                             .locked(PLL_LOCKED),
                             .clk_in1(CLK));
                         
    //set VGA_VISIBLE high when we are in the visible portion of the image
    assign VGA_VISIBLE = (VGA_X >= H_SYNC_PULSE + H_BACK_PORCH) && (VGA_X < H_VISIBLE + H_BACK_PORCH + H_SYNC_PULSE) && (VGA_Y >= V_SYNC_PULSE + V_BACK_PORCH) && (VGA_Y < V_VISIBLE + V_SYNC_PULSE + V_BACK_PORCH);
    assign VGA_HS = ~(VGA_X < H_SYNC_PULSE);
    assign VGA_VS = ~(VGA_Y < V_SYNC_PULSE);
       
    assign VGA_RED = (VGA_VISIBLE ? 15 : 0); //red whenever we are in visible region
    assign VGA_GREEN = ((VGA_VISIBLE && ((VGA_X == H_SYNC_PULSE + H_BACK_PORCH) || (VGA_X == H_VISIBLE + H_BACK_PORCH + H_SYNC_PULSE - 1))) ? 15 : 0); //green/red vertical edges
    assign VGA_BLUE = ((VGA_VISIBLE && ((VGA_Y == V_SYNC_PULSE + V_BACK_PORCH) || (VGA_Y == V_VISIBLE + V_SYNC_PULSE + V_BACK_PORCH - 1))) ? 15 : 0); //blue/red horizontal edges
       
    //at every clock edge
    always @(posedge VGA_CLK)
    begin
        //if enabled
        if(ENABLE) begin
            //increment VGA_X and VGA_Y
            if(VGA_X < H_TOTAL - 1) begin
                VGA_X <= VGA_X + 1;
            end else begin
                VGA_X = 0;
                if(VGA_Y < V_TOTAL - 1) begin
                    VGA_Y <= VGA_Y + 1;
                end else begin
                    VGA_Y <= 0;
                end
            end
        end
       
        if(RESET) begin
            VGA_Y <= 0;
            VGA_X <= 0;
        end
    end
endmodule

Yes, but scaling still must be done if you want to project the original scope's 500 X-pixels onto a panel with 1280 X-pixels.  Unless you want a black border of 140 pixels on the left and right.  Converting 500 to 1280 is not a fixed multiple by 2.
The native display of my LCD is actually 1024x600 so 500 would scale well - shame it's apparently not 500.

Thanks for the pointers (re: LM1882CM). It turns out the 166xC uses BT475 RAMDAC, which is theoretically supported by my existing design. Not sure about the 166xAs, though. HP often has significantly different display subsystems between the A, B and Cs of the same product family.
The 1662AS uses a Brooktree BT476KPJ66 RAMDAC as well as the LM1882, looks very similar if not the same.
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #74 on: September 30, 2017, 04:30:24 pm »
Can I see the source code of your sync generator....

Code: [Select]
module vga_control( CLK, //CLK input
                    ENABLE, //enable module
                    RESET, //resets device
                    VGA_CLK, //pixel clock for vga
                    VGA_X, //x position of vga
                    VGA_Y, //y position of vga
                    VGA_HS, //horizontal sync
                    VGA_VS, //vertical sync
                    VGA_VISIBLE, //are we in visible region
                    VGA_RED, //4 bit red colour
                    VGA_BLUE, //4 bit blue colour
                    VGA_GREEN); //4 bit green colour
                   
    input wire CLK, ENABLE, RESET;
    wire VGA_HS, VGA_VS, VGA_VISIBLE;
    output wire VGA_CLK, VGA_HS, VGA_VS, VGA_VISIBLE;
    output reg [11:0] VGA_X, VGA_Y;
    output wire [3:0] VGA_RED, VGA_BLUE, VGA_GREEN;
   
    //HP1662AS PARAMETERS (17.36MHz clock)
    parameter H_TOTAL = 695;
    parameter H_SYNC_PULSE = 56;
    parameter H_VISIBLE = 500;
    parameter H_FRONT_PORCH = 18;
    parameter H_BACK_PORCH = 121;
    parameter V_TOTAL = 417;
    parameter V_VISIBLE = 378;
    parameter V_SYNC_PULSE = 3;
    parameter V_FRONT_PORCH = 11;
    parameter V_BACK_PORCH = 25;
   
    //Line doubled (34.720MHz clock)
    /*parameter H_TOTAL = 695;
    parameter H_SYNC_PULSE = 56;
    parameter H_VISIBLE = 500;
    parameter H_FRONT_PORCH = 18;
    parameter H_BACK_PORCH = 121;
    parameter V_TOTAL = 834;
    parameter V_VISIBLE = 756;
    parameter V_SYNC_PULSE = 6;
    parameter V_FRONT_PORCH = 22;
    parameter V_BACK_PORCH = 50;*/
   
           
    //generate clock (change clock for different display modes)
    wire PLL_LOCKED;
   //generate vga clock
    clk_wiz_17360 vga_clk(  .clk_out1(VGA_CLK),
                             .reset(RESET),
                             .locked(PLL_LOCKED),
                             .clk_in1(CLK));
                         
    //set VGA_VISIBLE high when we are in the visible portion of the image
    assign VGA_VISIBLE = (VGA_X >= H_SYNC_PULSE + H_BACK_PORCH) && (VGA_X < H_VISIBLE + H_BACK_PORCH + H_SYNC_PULSE) && (VGA_Y >= V_SYNC_PULSE + V_BACK_PORCH) && (VGA_Y < V_VISIBLE + V_SYNC_PULSE + V_BACK_PORCH);
    assign VGA_HS = ~(VGA_X < H_SYNC_PULSE);
    assign VGA_VS = ~(VGA_Y < V_SYNC_PULSE);
       
    assign VGA_RED = (VGA_VISIBLE ? 15 : 0); //red whenever we are in visible region
    assign VGA_GREEN = ((VGA_VISIBLE && ((VGA_X == H_SYNC_PULSE + H_BACK_PORCH) || (VGA_X == H_VISIBLE + H_BACK_PORCH + H_SYNC_PULSE - 1))) ? 15 : 0); //green/red vertical edges
    assign VGA_BLUE = ((VGA_VISIBLE && ((VGA_Y == V_SYNC_PULSE + V_BACK_PORCH) || (VGA_Y == V_VISIBLE + V_SYNC_PULSE + V_BACK_PORCH - 1))) ? 15 : 0); //blue/red horizontal edges
       
    //at every clock edge
    always @(posedge VGA_CLK)
    begin
        //if enabled
        if(ENABLE) begin
            //increment VGA_X and VGA_Y
            if(VGA_X < H_TOTAL - 1) begin
                VGA_X <= VGA_X + 1;
            end else begin
                VGA_X = 0;
                if(VGA_Y < V_TOTAL - 1) begin
                    VGA_Y <= VGA_Y + 1;
                end else begin
                    VGA_Y <= 0;
                end
            end
        end
       
        if(RESET) begin
            VGA_Y <= 0;
            VGA_X <= 0;
        end
    end
endmodule
Not bad, simple and compact.  If you would take my recommendation, I would recommend these alterations, which may help alleviate you horizontal/vertical picture alignment bug.  (maybe, the problem may be elsewhere which we can discover with another test...)

1.  Make vga_visible (for H&V) = (VGA_X < H_VISIBLE) && (VGA_Y < V_VISIBLE)
Ahhhhh, now your outputs VGA_X and VGA_Y are your actual output visible X&Y coordinates.  Now, for the X, you can use these to feed the address of your dual-port line buffer memory on the output side.
2.  Make VGA_HS = (VGA_X >= H_VISIBLE + H_FRONT_PORCH ) && (VGA_X =< H_VISIBLE + H_FRONT_PORCH + H_SYNC_PULSE) ;
3.  Do the same for VGA_VS.

********  You should only bother going further below this point if you want a real-time software controllable video output generator.

Though, thanks to compiler optimizations, and you are using fixed parameters, your current code works out simple and compact, but, if you want to adjust in real time the video positioning, in one of my old codes, I basically had in the counting loops this:
4 additional latched input regs, HS_start, HS_stop, VS_start, VS_stop, VGA_HS&VS are now output regs instead of wires...(Actually, I personally prefer everything coming out of my modules to be regs so that feeding IOs directly make extra clean clear cut clock timing):

Inside the @posedge clk/if(VGA_X < H_TOTAL - 1) begin
Code: [Select]
if (VGA_X = HS_start) begin
VGA_HS <= 1;
end else if (VGA_X = HS_stop) begin
VGA_HS <= 0;
end
The reason for not placing all the adds and sums inside the '(VGA_X = HS_start)' is since these are no longer constants for the compiler to figure out before wiring logic, any math performed gets converted into gates, versus a simple equality comparator.  Same goes for the adding a latched reg input for H_TOTAL and H_VISIBLE and of course all the Vertical factors.  Having input latched regs gives you that 1 input 14 bit data buss with 3 bit address & WE making 8 internal regs to be latched to create any video format you like.

I know there seems to be only 8 variables of consequence H_total, H_active, HS_start, HS_stop, + VS versions, but you might add 2 more later-on, something like H_genlock & V_genlock which will allow you to set an adjustable offset between the source video frame and the output video frame.  These could be tied into the counters + 1 & an external additional HS&VS input into this module.
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #75 on: September 30, 2017, 07:14:02 pm »
Not bad, simple and compact.  If you would take my recommendation, I would recommend these alterations, which may help alleviate you horizontal/vertical picture alignment bug.  (maybe, the problem may be elsewhere which we can discover with another test...)

1.  Make vga_visible (for H&V) = (VGA_X < H_VISIBLE) && (VGA_Y < V_VISIBLE)
Ahhhhh, now your outputs VGA_X and VGA_Y are your actual output visible X&Y coordinates.  Now, for the X, you can use these to feed the address of your dual-port line buffer memory on the output side.
2.  Make VGA_HS = (VGA_X >= H_VISIBLE + H_FRONT_PORCH ) && (VGA_X =< H_VISIBLE + H_FRONT_PORCH + H_SYNC_PULSE) ;
3.  Do the same for VGA_VS.

This was actually my original approach because, as you say, it creates the nice situation where VGA_X and VGA_Y are your actual visible display coordinates.
However this does not generate the same signals as the HP1662AS.
What you will notice is that, in the HP1662AS, the h-sync and v-sync fall at the same time. In my code, this is also the case. In your code, h-sync falls then we wait for the whole pulse then h-sync rises, then we wait for the h-back-porch, then the v-sync falls (because VGA_X does not increment until we have done h-the back-porch). And this does make a difference. In fact, I found that when displaying industry standard 640x480 60Hz VGA, my monitor would lock on if I used your approach, but would not lock on using my approach (you could make it lock if you inverted the sync pulses).
Quote
2.  Make VGA_HS = (VGA_X >= H_VISIBLE + H_FRONT_PORCH ) && (VGA_X =< H_VISIBLE + H_FRONT_PORCH + H_SYNC_PULSE) ;

I think it should be < rather than =<.

Unfortunately, I have been called away on a last minute trip for two weeks so won't be able to make much progress. On the plus side, the TVP and PCB have arrived so I just need to solder than up. I have also been persuaded to look inside the HP for the real timing signals  :) Thanks for the help.
« Last Edit: September 30, 2017, 07:20:38 pm by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #76 on: September 30, 2017, 08:53:07 pm »
Oooops, for the VS Alignment, in my old code, the V counter was incremented on my original 'HS_start' register, not the 'H_TOTAL' H counter reset flag, thus making the VS change at the beginning of a new HS.  Note that my code was in use in 2003 on an Altera ACEX FPGA.  All the simple regs I used with the simple if (A==B) code was designed for minimal gate count, fastest compile time, maximum F-MAX and fully programmable sync-generator + genlock functions.   The registers were filled by a MCU where doing the simple math to fill the 8 regs was better written and controlled in C code.  As you can imagine at the time, the limitations of the FPGAs and even the bugs I had to work around in the compilers the first generation of Altera's Quartus.

As for the video output structure, all you need to set is the H_Total to be equal to a multiple (the same number since you FPGA PLL Clock will be multiplying this one by another 2 to generate your video output clock) of the equivalent HORIZONTAL_PLL_Divider inside the TVP IC.  The shape and position and polarity of your sync coming out of you FPGA can be tailored to anything which best suits your LCD screen, it need not be a perfect 2:1 mirror of what is coming out of the scope through the TVP.  This means when you tune the TVP's H_PLL clock generator, you will need to adjust your internal H_TOTAL variable to keep sync.  Play adjusting in real time may force you to make your sync generator real-time adjustable just for convenience.

  Though, the TVP does have programmable I2C registers which will allow you to modify the sync pulse width, sync polarity, and even a active video region outputs to window the active video area to simplify some of your FPGA code.




« Last Edit: September 30, 2017, 08:58:16 pm by BrianHG »
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #77 on: February 26, 2018, 08:25:37 am »
Hi guys, it's been a while. I started a new job and moved cities so progress has been slow. I'm back on the train though.

The plan is to have a separate board for the TVP and for the FPGA. That way I can develop the TVP stuff using my Digilent Nexys 4 DDR board before spinning my own FPGA board. The TVP board is complete, schematic below, but I can't seem to get my register settings right. For now I am just trying to get the TVP to lock onto a 1280x1024 60Hz signal.

What works: I can input Hsync and Vsync and use the H-PLL to generate the 108MHz pixel clock.

What doesn't work: I should be getting some kind of changing output on the G[9:0] pins, but they never change. By default all G[9:0] pins are low, but by changing the Green Fine Offset MSBs register I can change this default value, but it still doesn't change depending on the video signal. I can see a valid video signal gets right up to the pin of the chip so I don't know what's going on.

I'm sure there must just be a register setting I am missing, but I can't find it  >:( Any pointers appreciated.

If it is useful, here is a dump of all the registers o the TVP, starting from address 0x00.
02 69 80 A0 00 06 10 20 00 00 00 80 83 80 52 2E 5D 20 01 00 B5 04 11 02 00 00 C2 77 07 00 10 10 10 0D 08 12 6B 10 80 0C 53 08 07 00 50 00 80 8C 04 5A 18 60 03 10 00 00 20 69 00 07 00 03 04 00 2C 01 2C 06 05 05 1E 1E 00 00 E3 16 4F 02 CE 06 AB F3 00 10 55 FC 78 F1 88 FE 00 10.
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #78 on: February 26, 2018, 03:41:25 pm »
I would like to see your schematic before I analyses the I2C controls.
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #79 on: February 26, 2018, 08:31:22 pm »
Must've forgotten to upload it, sorry.
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #80 on: February 27, 2018, 05:17:27 am »
Everything looks perfect, I'll go through the I2C regs late tonight.
__________
BrianHG.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #81 on: February 28, 2018, 05:47:12 am »

If it is useful, here is a dump of all the registers o the TVP, starting from address 0x00.
02 69 80 A0 00 06 10 20 00 00 00 80 83 80 52 2E
5D 20 01 00 B5 04 11 02 00 00 C2 77 07 00 10 10
10 0D 08 12 6B 10 80 0C 53 08 07 00 50 00 80 8C
04 5A 18 60 03 10 00 00 20 69 00 07 00 03 04 00
2C 01 2C 06 05 05 1E 1E 00 00 E3 16 4F 02 CE 06
AB F3 00 10 55 FC 78 F1 88 FE 00 10.

Can you break this down into control names starting on page 26 of TI's datasheet?
Example:
02 = Chip revision.

69 8 = pll-divider = 1688  (This means you set the chip to sample 1688 pixels from H-sync to H-Sync)
1688 * 25Khz = 42200Khz, or, 42.2MHz.  You said 108MHz, this isn't right.

ADR $03 = A0 = Oscillator = 10 = 70-135MHz, and, 100 = charge pump current just below default.
Change this from $A0 to $60 if you are indeed running at 42.2MHz.

00 = Sampler phase

06 =        Clamp start  - The point in the picture to DC clamp the input capacitor to black level reference.  Make sure external clamp is disabled otherwise the video may clip to all 100% white or all 100% black.
10 = 16 = clamp width  - The duration of this clamp.

20 = Hsync output width of 32 pixels.

Adr...0E = 52 = #01010010
HSPO: HSYNC polarity override 0 = Polarity determined by chip (default)
HSIP: HSYNC input polarity 1 = Indicates input HSYNC polarity active high (default)
HSOP: HSYNC output polarity 0 = Active low HSYNC output (default)
AHSO: Active HSYNC override 1 = Active HSYNC is manually selected via the AHSS control bit (bit 3 of register 0Eh). (default)
AHSS: Active HSYNC select.  0 = Active HSYNC is derived from the selected HSYNC input
VSOP: VSYNC output polarity 0 = Active low VSYNC output (default)
AVSO: Active VSYNC override 1 = Active VSYNC is manually selected via the AVSS control bit (bit 0 of register 0Eh). (default)
AVSS: Active VSYNC select. 0 = Active VSYNC is derived from the selected VSYNC input

Are the read-back of HS polarity and VS polarity true?  Bit 6 for HS and Bit

--------------------------------

Change ADR $10 from $5D to $58.  No big difference here since you are not using Red and Blue.

Readback adr $14 seems OK.

Try switching:
ADR $22 to = 02.
ADR $26 to = 0.  (Must be disabled for your scopes weird non-standard video format.)
ADR $2F should be 0C.  Your read 8C may just be the undefined reserve bits.

Readback address $38 = 20, this is a semi-good sign, ADR$37 = 00 is a bad sign.  The IC isn't counting the number of lines in a frame...  If the IC working on the video V-sync and H-Sync, unless I misunderstood these 2 read only registers.
Readback address $39 and $40, = $069 = 105 = 27mhz / 105 = 257142.8571 hz, or, 257 Khz???  Is this correct, isn't your video around 25.7Khz?  Or, if you are using the IC internal 6.3 MHz clock reference, we get 60KHz?

These 2 read-backs say something may be wrong with the ICs 27MHz reference system clock or the syncs coming in aren't being read properly, or the IC's internal 6.3MHz clock

Readback ADR $3B is 7 - H-sync size.
Readback ADR $3D = 0 - This is telling us your V-Sync is 0 lines long.  This is obviously wrong.  Again, it is a sign that the IC doesn't see the VS or HS properly....

Also, make sure that reset pin is held low during power-up for a bit of time before making it high.

What are you reading on the green data port, all high, or all low.  If you are getting all high, then the ADC may be working fine and all we need to do is debug the clamp position setting after you look at my above changes.

Probe pins 81 and 78 directly, see if your syncs are getting there.
Also, scope the video going into the TVP IC, tell me what the voltage offset is.
« Last Edit: February 28, 2018, 10:00:07 am by BrianHG »
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #82 on: February 28, 2018, 12:14:38 pm »
Thank you for your comments, I appreciate it.
I made the stupid mistake of reading out all of these registers as soon as the chip boots and not giving it time to lock onto the video signals, therefore some of these registers are incorrect - I'm really sorry, it was only 6 registers though. I will address your comments one at a time.

Can you break this down into control names starting on page 26 of TI's datasheet?

I don't have time this evening but will try to do this soon.

Quote
69 8 = pll-divider = 1688  (This means you set the chip to sample 1688 pixels from H-sync to H-Sync)
1688 * 25Khz = 42200Khz, or, 42.2MHz.  You said 108MHz, this isn't right.
For now I am using a 1280x1024@60Hz video signal while I figure out the registers which does use a 108MHz clock. Here are the timings for a 1280x1024@60Hz display.
http://tinyvga.com/vga-timing/1280x1024@60Hz
I know them to be correct because the video source I am using is my FPGA running the default program. https://github.com/Digilent/Nexys-4-DDR-OOB/blob/master/src/hdl/Vga.vhd.

Quote
ADR $03 = A0 = Oscillator = 10 = 70-135MHz, and, 100 = charge pump current just below default.
Change this from $A0 to $60 if you are indeed running at 42.2MHz.
Running at 108MHz so not necessary :)

Quote
06 =        Clamp start  - The point in the picture to DC clamp the input capacitor to black level reference.  Make sure external clamp is disabled otherwise the video may clip to all 100% white or all 100% black.
10 = 16 = clamp width  - The duration of this clamp.
Internal clamp is indeed selected. Bit 7 of H-PLL and Clamp Control (addr 0x0F is 0)

Quote
Adr...0E = 52 = #01010010
HSPO: HSYNC polarity override 0 = Polarity determined by chip (default)
HSIP: HSYNC input polarity 1 = Indicates input HSYNC polarity active high (default)
HSOP: HSYNC output polarity 0 = Active low HSYNC output (default)
AHSO: Active HSYNC override 1 = Active HSYNC is manually selected via the AHSS control bit (bit 3 of register 0Eh). (default)
AHSS: Active HSYNC select.  0 = Active HSYNC is derived from the selected HSYNC input
VSOP: VSYNC output polarity 0 = Active low VSYNC output (default)
AVSO: Active VSYNC override 1 = Active VSYNC is manually selected via the AVSS control bit (bit 0 of register 0Eh). (default)
AVSS: Active VSYNC select. 0 = Active VSYNC is derived from the selected VSYNC input

Are the read-back of HS polarity and VS polarity true?  Bit 6 for HS and Bit

These all look fine. The HSYNC and VSYNC pulses are being accepted just fine and the HPLL is generating the 108MHz as expected.


Quote
Change ADR $10 from $5D to $58.  No big difference here since you are not using Red and Blue.

Try switching:
ADR $22 to = 02.
Tried this, but no change.

Quote
ADR $26 to = 0.  (Must be disabled for your scopes weird non-standard video format.)
I am not using the scope video signal for now, but will bear in mind for when I am.

Quote
Readback address $38 = 20, this is a semi-good sign, ADR$37 = 00 is a bad sign.  The IC isn't counting the number of lines in a frame...  If the IC working on the video V-sync and H-Sync, unless I misunderstood these 2 read only registers.
This is one of the registers that changed. It actually reads 0x242A or 1066 which is the correct number of lines per frame.

Quote
Readback address $39 and $40, = $069 = 105 = 27mhz / 105 = 257142.8571 hz, or, 257 Khz???  Is this correct, isn't your video around 25.7Khz?  Or, if you are using the IC internal 6.3 MHz clock reference, we get 60KHz?
Yeah the line frequency is about 63kHz. So using the ~6.5MHz clock this works out to be fine. This register was actually 0x06A when I read it back which is 106 but close enough given the low resolution of the 6.5MHz clock.

Quote
Readback ADR $3D = 0 - This is telling us your V-Sync is 0 lines long.  This is obviously wrong.  Again, it is a sign that the IC doesn't see the VS or HS properly....
Another one that changed when I let the chip settle. This becomes 0x03 which is the correct number of lines.

Quote
Also, make sure that reset pin is held low during power-up for a bit of time before making it high.
These are the first lines of the program. The reset pin is pulled down by a resistor and then pulled high after 100 seconds when the pin goes from hi-z to driven high.
Code: [Select]
_delay_ms(100); //(TVP must be held in reset for 5ms after power up)
DDRB = 0x45;
PORTB |= 0x05;
PORTB |= 0x40; //Bring TVP out of reset
_delay_ms(100); //No I2C traffic for 1us after reset is released

Quote
What are you reading on the green data port, all high, or all low.  If you are getting all high, then the ADC may be working fine and all we need to do is debug the clamp position setting after you look at my above changes.
All low by default. By changing addr 0x0C (Green Fine Offset MSBs) I can make the pins go high as I like though.

Quote
Probe pins 81 and 78 directly, see if your syncs are getting there.
Also, scope the video going into the TVP IC, tell me what the voltage offset is.
The syncs are definitely getting there. I can also verify this by the fact that they are also coming out of the chip on pins 23 and 24.
Attached is a capture of the video signal at the chip.

Other registers that changed are:
Blue Digital ALC Output LSBs (23h)
0E not 12

Green Digital ALC Output LSBs (24h)
00 not 6B

Red Digital ALC Output LSBs (25h)
04 not 10

Digital ALC Output MSBs (27h)
08 not 0C

So in summary:
02 69 80 A0 00 06 10 20 00 00 00 80 83 80 52 2E 5D 20 01 00 B5 04 11 02 00 00 C2 77 07 00 10 10 10 0D 08 0E 00 04 80 08 53 08 07 00 50 00 80 8C 04 5A 18 60 03 10 00 2A 24 6A 00 07 03 03 04 00 2C 01 2C 06 05 05 1E 1E 00 00 E3 16 4F 02 CE 06 AB F3 00 10 55 FC 78 F1 88 FE 00 10.
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #83 on: February 28, 2018, 12:32:49 pm »
As requested, here are the registers values along with their names. When I get time I will try and go through register by register to justify each setting.
Chip Revision             02
H-PLL Feedback Divider MSBs       69
H-PLL Feedback Divider LSBs       80
H-PLL Control             A0
H-PLL Phase Select          00
Clamp Start             06
Clamp Width             10
HSYNC Output Width          00
Blue Fine Gain             20
Green Fine Gain            00
Green Fine Gain            00
Blue Fine Offset MSBs          80
Green Fine Offset MSBs         83
Red Fine Offset MSBs         80
Sync Control 1            52
H-PLL and Clamp Control       2E
Sync On Green Threshold        5D
Sync Separator Threshold       20
H-PLL Pre-Coast            01
H-PLL Post-Coast         00
Sync Detect Status         B5
Output Formatter         04
MISC Control 1            11
MISC Control 2            02
MISC Control 3            00
Input Mux Select 1          00
Input Mux Select 2         C2
Blue and Green Coarse Gain      77
Red Coarse Gain            07
Fine Offset LSBs         00
Blue Coarse Offset         10
Green Coarse Offset         10
Red Coarse Offset         10
HSOUT Output Start         0D
MISC Control 4            08
Blue Digital ALC Output LSBs      0E
Green Digital ALC Output LSBs       00
Red Digital ALC Output LSBs      04
Automatic Level Control Enable      80
Digital ALC Output MSBs         08
Automatic Level Control Filter      53
Reserved            08
Fine Clamp Control          07
Power Control            00
ADC Setup            50
Coarse Clamp Control         00
SOG Clamp            80
RGB Coarse Clamp Control       8C
SOG Coarse Clamp Control      04
ALC Placement            5A
Reserved             18
Reserved            60
Macrovision Stripper Width       03
VSYNC Alignment            10
Sync Bypass            00
Lines Per Frame Status         2A24
Clocks Per Line Status         6A00
HSYNC Width             07
VSYNC Width             03
Line Length Tolerance         03
Reserved             04
Video Bandwidth Control         00
AVID Start Pixel          2C01
AVID Stop Pixel            2C06
VBLK Field 0 Start Line Offset      05
VBLK Field 1 Start Line Offset      05
VBLK Field 0 Duration         1E
VBLK Field 1 Duration         1E
F-bit Field 0 Start Line Offset      00
F-bit Field 1 Start Line Offset    00
1st CSC Coefficient         E316
2nd CSC Coefficient         4F02
3rd CSC Coefficient         CE06
4th CSC Coefficient         ABF3
5th CSC Coefficient         0010
6th CSC Coefficient         55FC
7th CSC Coefficient         78F1
8th CSC Coefficient         88FE
9th CSC Coefficient         0010
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #84 on: February 28, 2018, 01:04:42 pm »
Is your scope video shot at the input pin side of the cap?

If adjusting black level moves the ADC reading, basically this moves the DC voltage of the input pins during the clamp period, but, you see no picture data, it is as if you have the wrong analog video input selected, or, that video signal just isn't reaching the TVP video input pin, but, the ADC still seems to sample that black level charge.

Just for crazy sake, probe the red and blue data ports just to see if they have any modulated data on them.

Also, disable the SOG detector in the I2C bits.
Also change ADR $26 to = 0.  Without tri-level syncs, or by-level syncs the AGC / automatic contrast system will fail.  PC RGB video doesn't have these sync levels to measure what the contrast should be.
__________
BrianHG.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #85 on: March 01, 2018, 01:38:40 am »
Must've forgotten to upload it, sorry.
Found some minor mistakes in your schematic.

#1 Short out cap C23.
#2 Short out cap C32.
#3 Short out R9.
#4 Remove C12.
Optional, if you want to exactly match TI's reference design...
#5 Add a 1nf cap to pin 1 of U3 and GND.
#6 Cut the V-Sync signal going to pin 1 of U3 and add a 330 ohm series resistor.
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #86 on: March 05, 2018, 09:00:55 am »
#1 Short out cap C23.
#2 Short out cap C32.
#3 Short out R9.
#4 Remove C12.
Optional, if you want to exactly match TI's reference design...
#5 Add a 1nf cap to pin 1 of U3 and GND.
#6 Cut the V-Sync signal going to pin 1 of U3 and add a 330 ohm series resistor.

Oh wow yeah. Looks like I got carried away adding caps on the input and put the low pass filter on the wrong sync! I have done corrections #1-4, but #5 and #6 are a bit more destructive and I don't think are what is causing the problem, so will leave the out for now.

Is your scope video shot at the input pin side of the cap?

If adjusting black level moves the ADC reading, basically this moves the DC voltage of the input pins during the clamp period, but, you see no picture data, it is as if you have the wrong analog video input selected, or, that video signal just isn't reaching the TVP video input pin, but, the ADC still seems to sample that black level charge.

Just for crazy sake, probe the red and blue data ports just to see if they have any modulated data on them.

Also, disable the SOG detector in the I2C bits.
Also change ADR $26 to = 0.  Without tri-level syncs, or by-level syncs the AGC / automatic contrast system will fail.  PC RGB video doesn't have these sync levels to measure what the contrast should be.


Yep, probed on the TVP side of the cap. The other side of the cap is the same except the signal is shifted up so that it doesn't go below GND. I have powered down the SOG block and the ALC as suggested.

Interestingly, it does look like there is some activity on the red and blue output channels?? But only on the lowest bits.

Also interestingly, if I enable the colour space conversion block I do see some activity on the lower bits of the green output channel.

Tomorrow I am going to print out the datasheet register section and begin the process of going through the registers one by one to verify each register.
« Last Edit: March 05, 2018, 09:03:31 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #87 on: March 05, 2018, 09:15:36 am »
You also have the H-Sync and V-Sync going into the wrong inputs on the TVP.  They are backwards!!!
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #88 on: March 05, 2018, 09:21:41 am »
Doh!

That explains why I was getting confused with my inputs. Luckily for now I have just soldered wires to the input pins and I swapped Hsync and VSync from the source which is why it has been detecting vsync and hsync ok up until now. So I guess R9 and C12 should have remained for now.

Anyway, as I say, I have manually swapped vsync and hsync so there is no problem there until I come to use the proper connector - except that I don't have the low pass filter.
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #89 on: March 05, 2018, 09:53:13 am »
Alright! Looks like maybe it is fixed. I took another look under my microscope and it turns out pin 4 was not properly soldered. This is one of the AVDD pins so I resoldered it.

The first good sign was that the TVP suddenly started drawing an extra 80mA so clearly some part of the chip wasn't powering up. And yeah, now G[0:9] are outputting something!

My next move is to connect the clock, hsync, vsync and G[0:9] outputs to my MSO scope and see if I can capture the data and reconstruct a frame in matlab :)
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #90 on: March 05, 2018, 10:10:18 am »
You wired the previous parts correctly (the changes I listed), it's just the outputs of the 74HC buffer to the TVP.  Since you have those 2 series caps, remove those caps and jumper swap the signal there...  So the low pass filter on the VS line is actually in the right place...
__________
BrianHG.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #91 on: March 06, 2018, 08:03:49 am »
You are at a point, if you have a connection to you FPGA board with VGA out, to make a program which just passes the data and H&V syncs from in to out through a clocked D-Flip-flop register, reproducing a monochrome image on your monitor.  That should be a simple enough thing to do if you are sampling a VGA compatible mode.
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #92 on: April 08, 2018, 12:11:37 pm »
I thought I would quickly share the first success!

Using the logic analyser on my scope I captured the data from the first frame, then using Matlab I generated the original image. Obviously there are some slight timing issues, and the ADC is only using the bottom 8 bits instead of all 10, but these things can be fixed in the registers.

I also probed the LM1882 Video sync generator chip and can confirm a number of parameters:

Pixel Clock = 20MHz

Total Lines = 417
Vertical Back Porch = 11
Vertical Front Porch = 25
VSync = 3
Active Lines = 378

Total Dots = 800
Horizontal Back Porch = 24
Horizontal Front Porch = 136
HSync = 64
Active Dots = 576

This gives an overall resolution of 576x378 which is a bit of an odd one.. Haven't yet figured out the best way to do scaling on this with an output resolution of  1024x600.
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #93 on: April 09, 2018, 07:39:36 am »
Your horizontal isn't a problem.  Just tune the ADC H-PLL so you have 1024 active horizontal pixels.  (I know this isn't dot accurate sampling, turn down the ADC bandwidth and you will get smooth corners around the edges of your pixels)  The other choice is pixel perfect sampling.  Then you need to decide how to digitally upsample that, which in turn makes soft edges unless you do a perfect 2x or 3x dummy upsample.  Doing 2.5x will look chunky without some nice smoothing included.

Now, it's what you want to do with the vertical.
« Last Edit: April 09, 2018, 08:24:37 am by BrianHG »
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #94 on: April 26, 2018, 09:10:31 am »
I have the FPGA up and running to a basic level. Currently I have a dual port frame buffer between the RX and TX parts of the system which are running on two separate clock domains - this will evolve and I will add scaling. The image isn't  bad, but there is definite pixel swimming around pixels around text and the edges of buttons -see videos to demonstrate.

I have tried playing with the video bandwidth and pll phase but can't get rid of this swimming. What parameters can I play with to help with this problem?



Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #95 on: April 26, 2018, 10:56:32 am »
At this point, you should be using the ADC clock for everything through the FPGA to drive your DAC clock (in your case it may just be IOs) output, and raster generator.
It looks like you have an input data latch setup-and-hold error.
Just invert the clock input to your FPGA, or if you are feeding the FPGA PLL to multiply your clock, change the input phase.

The clock out of the ADC may also have a programmable phase.
Also, try adjusting the sampling phase on the I2C commands.  The ADC may be sampling right at the edge of a pixels.
Confirm ADC clock speeds and the PLL settings inside the ADC.
Same goes goes the FPGA PLL if you are using it to double the ADC's clock signal quality distributed inside the FPGA.
Also try lowering the ADC bandwidth / video input filter response.
« Last Edit: April 26, 2018, 10:58:14 am by BrianHG »
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #96 on: May 14, 2018, 04:12:36 am »
At this point, you should be using the ADC clock for everything through the FPGA to drive your DAC clock (in your case it may just be IOs) output, and raster generator.

It shouldn't matter if I am using a different clock domain on the other side of the dual port BRAM - this is a perfectly acceptable way of doing it for now. The reason I am using a different clock for the TX side of the BRAM is that, due to an oversight on my part, the clock output of the TVP doesn't go to a clock input on my FPGA eval board so the routing is pretty bad (vivado keeps complaining about it) so I want to minimise the usage of that clock. When I design my own fpga board I will use the TVP clock as the main clock.

It looks like you have an input data latch setup-and-hold error.
Just invert the clock input to your FPGA, or if you are feeding the FPGA PLL to multiply your clock, change the input phase.

The clock out of the ADC may also have a programmable phase.
Also, try adjusting the sampling phase on the I2C commands.  The ADC may be sampling right at the edge of a pixels.
Confirm ADC clock speeds and the PLL settings inside the ADC.
Same goes goes the FPGA PLL if you are using it to double the ADC's clock signal quality distributed inside the FPGA.
Also try lowering the ADC bandwidth / video input filter response.

It wasn't a setup-hold error in the FPGA. I have constrained all inputs based on the TVP datasheet and there are no complaints. I have mostly fixed the issue by changing the ADC clock phase so that the signals settle better before sampling.

I have also realised that the colours of the scope can be set to 100 different levels so i will need at least a 7-bit video DAC on the other side of the FPGA to make sure I can represent all 100 colours properly. Currently I only have a 4-bit DAC and I can produce a lot of noise on screen by setting the color level to be right on the boundary between one of these 16 colours. I'm thinking I will use the ADV7120 which is 8-bit.

I am planning to use linear interpolation, but it makes memory handling a bit more complex. Effectively for every pixel I will need to read make 3 memory accesses (pixel above, pixel below and the pixel to the right). The output operates at 48.875MHz which means I need to read at 3x that, all while also fitting in the write cycles for the RX. Any tips on doing this?
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #97 on: May 14, 2018, 03:06:21 pm »
At this point, you should be using the ADC clock for everything through the FPGA to drive your DAC clock (in your case it may just be IOs) output, and raster generator.

It shouldn't matter if I am using a different clock domain on the other side of the dual port BRAM - this is a perfectly acceptable way of doing it for now. The reason I am using a different clock for the TX side of the BRAM is that, due to an oversight on my part, the clock output of the TVP doesn't go to a clock input on my FPGA eval board so the routing is pretty bad (vivado keeps complaining about it) so I want to minimise the usage of that clock. When I design my own fpga board I will use the TVP clock as the main clock.
Are you saying you have enough BRAM to buffer an entire frame?  Then yes, you don't need synchronous clocks from input video to output video.  I thought you just had enough memory to buffer a few lines of video.
Quote
It looks like you have an input data latch setup-and-hold error.
Just invert the clock input to your FPGA, or if you are feeding the FPGA PLL to multiply your clock, change the input phase.

The clock out of the ADC may also have a programmable phase.
Also, try adjusting the sampling phase on the I2C commands.  The ADC may be sampling right at the edge of a pixels.
Confirm ADC clock speeds and the PLL settings inside the ADC.
Same goes goes the FPGA PLL if you are using it to double the ADC's clock signal quality distributed inside the FPGA.
Also try lowering the ADC bandwidth / video input filter response.

It wasn't a setup-hold error in the FPGA. I have constrained all inputs based on the TVP datasheet and there are no complaints. I have mostly fixed the issue by changing the ADC clock phase so that the signals settle better before sampling.

I have also realised that the colours of the scope can be set to 100 different levels so i will need at least a 7-bit video DAC on the other side of the FPGA to make sure I can represent all 100 colours properly. Currently I only have a 4-bit DAC and I can produce a lot of noise on screen by setting the color level to be right on the boundary between one of these 16 colours. I'm thinking I will use the ADV7120 which is 8-bit.
16 shades of grey should be good enough to not exhibit the severe degree of pixel noise shown in your video.  However, it would be more annoying if you are storing only 4 shades in ram.
Quote

I am planning to use linear interpolation, but it makes memory handling a bit more complex. Effectively for every pixel I will need to read make 3 memory accesses (pixel above, pixel below and the pixel to the right). The output operates at 48.875MHz which means I need to read at 3x that, all while also fitting in the write cycles for the RX. Any tips on doing this?
Need a better idea of exactly what you are trying to accomplish.  If you are repeating every 2 or 3 Y lines of video, no Y interpolation is needed, though, your pixels are square.  If you are multiplying the Y by an odd number like 2.5, then yes, now if you dont want thicker chunky bars every 2 or 3 lines, then Y linear filtering is needed.

If your LCD isn't allowing true native dot-dot rendering on the VGA side, then you will also need to soften things up as this problem will get amplified.  I've used simple 2D linear filtering when up-sampling and it tends to do a really good job and in your case, using the sampler to upsample the Y resolution, you will only need 2 multipliers and 1 adder to make it work.  Your BRam should be divided into 2 parallel banks.  1 for even input lines and one for odd input lines.  On the output side, you will just run the 2 appropriate even and odd lines in parallel, mixing the correct proportion of even and odd line source data.  This can all be done with 1 binary adding counter to define the Y output position, with extra LSB bits, and use the LSB bits, positive as you first multiplier factor, inverted for the second multiplier & sum those 2 outputs to render your line.  Note you will need to swap even and odd line output multiplying channels depending on which line you are rendering.

If you are sampling at the native mode of your scope to save memory, your output stage will now need double the multipliers for an X upsampler.

I still recommend lowering the TVP's input filters to the lowest frequency possible as your scope output s very low frequency pixel clock.  This will linear filter the X for you set the TVP to oversample.

Finally, yes, if your scope output 100 shades of grey and you don't want to see any artifacts, it is better having a real video DAC.  Oversampling on the X from the scope set to your LCD X res with a low pass video filter has a good chance of creating a dithered response in the LSB from the TVP generating a good equivalent 50 to 100 shades of grey as long as your 4 resistor dac is fairly linear.
« Last Edit: May 14, 2018, 04:03:51 pm by BrianHG »
__________
BrianHG.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #98 on: May 14, 2018, 03:12:11 pm »
Dirty trick.  Pull your crystal oscillator on your FPGA, tie the TVP's clock output to that input and you will now have the TVP feeding a global clock.

__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #99 on: May 16, 2018, 06:01:02 am »
I cut the clock trace and routed it to a different pin and that fixed the clocking issue for now. Will put it back when I design my own FPGA board.

I've done some calculations and if I start the output frame 1 line after the start of the input frame then the worst case difference between the two video signals is about 26 lines. So I will create a buffer of 28 lines to be safe. This requires 126kBits at 8-bit depth which will JUST fit into an iCE40HX8K. However I will only be able to store native resolution of 576*378 and therefore cannot use the TVP oversampling trick so I will create an X interpolator with the extra two multipliers.

I like your idea of breaking the ram into even and odd lines. Clever way of accessing both pixels at the same time.

The next thing to do is to make sure I am able to synchronise my input and output frames appropriately. The input frame is technically slightly slower frame rate than the output frame, but I think the LCD will be tolerant if I cut the V-sync pulse a little short. Only one way to find out.
« Last Edit: May 16, 2018, 06:03:58 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #100 on: May 17, 2018, 05:28:14 am »
Without an entire frame buffer, the video input and video output frame must have an exactly timed matched V-sync, though, you can have a fixed delay from video input to output.  If you don't you will need to skip lines or pixels which will mess up the PLL locking mechanism in your VGA LCD screen, or, you will crap out you video vertical output.

This shouldn't be a problem, taking the video input and it H-Sync and run a perfect 2x, or 2.25x or 2.5x or 2.75x or 3x output with a H-sync running the same pixel/line count as the TVP, but, at the PLL multiplied rate.  If you are attempting H-locking, instead of V-locking delayed by an extra line or 2, you might get horizontal alignment jitter as this locking may mess up, but, this shouldn't be necessary as all you need to do is wait 1 additional source line delay before beginning video output.

You only need a 4-5 line buffer to make this work, so, you have plenty of memory to over-sample the source video so that your output will look like an analog VGA signal with additional shades and you only need to worry about the Y stretching linear filtering.

« Last Edit: May 17, 2018, 05:31:29 am by BrianHG »
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #101 on: May 17, 2018, 05:59:20 am »
Quote
You only need a 4-5 line buffer to make this work, so, you have plenty of memory to over-sample the source video so that your output will look like an analog VGA signal with additional shades and you only need to worry about the Y stretching linear filtering.

Where do you get 4-5 from? If the input and output frames start at the same time there is a 26 line difference between the two frames at the end of the input frame. Therefore I need 26-lines in memory.
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #102 on: May 17, 2018, 08:58:10 am »
Quote
You only need a 4-5 line buffer to make this work, so, you have plenty of memory to over-sample the source video so that your output will look like an analog VGA signal with additional shades and you only need to worry about the Y stretching linear filtering.

Where do you get 4-5 from? If the input and output frames start at the same time there is a 26 line difference between the two frames at the end of the input frame. Therefore I need 26-lines in memory.
Ohh, are you doing some weird vertical scaling multiplication?
26 lines difference from top to bottom from what kind of vertical multiple?
2x? 2.5x?  The exact numbers are a blur going back somewhere around 5 pages on this thread...
What's the different usable Y res of the LCD and what's the Y res of the scope output?
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #103 on: May 17, 2018, 09:11:28 am »
The input resolution is 576x378 lines and the output resolution is 1024x600 lines.

The frame time of the input is 16.685ms and the output is not 16.9ish, off the top of my head. Will have to play around with removing lines etc to make 16.9 closer to 16.685.

Pixel rate input is 20MHz. Output is 48.875MHz
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #104 on: May 18, 2018, 08:57:34 am »
Ok so I have managed to synchronise the two video signals.

The first thing I did was change the pixel rate of the output from 48.875MHz to 48.928MHz which is only a 0.1% change and gives me an output frame rate much closer to the frame rate of the input. However they would still drift out of phase as this was not exactly correct.

Then I made the input assert a flag each time it started receiving line zero. The output then simply restarted the output frame whenever it saw this flag and it reached the end of an output line.This means that we are basically inserting/removing lines into the VSYNC as necessary to keep roughly in sync to within a line.

However, I found that this caused the LCD to flicker. Luckily, I found however that if I add/remove the lines in the front porch then it does not flicker!

So this is my solution. I will now try to reduce the frame buffer to the minimum necessary.
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #105 on: May 18, 2018, 09:46:52 pm »
You should be resampling the vertical by 51:32.  (ie, your vertical scaler requires a 6 bit counter, 378 will be stretched to 602 lines)  With this, you will loose a fraction of a line at the top and bottom of the display.  1/2 of a visible line on top and bottom to be very close.  It should still be a visible line, however, you need to make sure you also count your source's total scan lines into that ratio to make sure you end up with a whole number of lines to make a steady scaled output.  3:2 would be much easier, but your source 378 will end up as 567 leaving a black bar or 16 lines on the LCD above and below the centered image, however, your chance of making a perfect source to destination scaled image is far more likely to succeed.

Once again, your rendered output should be parallel to your input, since the input is 60hz and your output is 60hz.  Your output hsync should be a perfect 51:32, or 3:2 multiple of you input source and the video output should fit in with just a few line delay from the source.  No slipping, no line dropping in the front porch.

Occasionally removing lines in the video, I find it funny that this actually worked for you.


__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #106 on: May 18, 2018, 09:53:20 pm »
It makes sense that the LCD doesn’t care how many lines I put in the front porch. During the front porch it is just waiting for the vsync. Pixel clock is derived from the hsync pulse which is still constant.
Read about my stuff at: projects.matthollands.com
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #107 on: May 19, 2018, 05:23:00 am »
You should be resampling the vertical by 51:32.  (ie, your vertical scaler requires a 6 bit counter, 378 will be stretched to 602 lines)  With this, you will loose a fraction of a line at the top and bottom of the display.  1/2 of a visible line on top and bottom to be very close.  It should still be a visible line, however, you need to make sure you also count your source's total scan lines into that ratio to make sure you end up with a whole number of lines to make a steady scaled output.  3:2 would be much easier, but your source 378 will end up as 567 leaving a black bar or 16 lines on the LCD above and below the centered image, however, your chance of making a perfect source to destination scaled image is far more likely to succeed.

Once again, your rendered output should be parallel to your input, since the input is 60hz and your output is 60hz.  Your output hsync should be a perfect 51:32, or 3:2 multiple of you input source and the video output should fit in with just a few line delay from the source.  No slipping, no line dropping in the front porch.

Occasionally removing lines in the video, I find it funny that this actually worked for you.

Actually the scaling ratio doesn't have to be integer to integer (the last line from the source doesn't have to fall exactly on the last line in the destination). Scaling ratio is also affected by the usable area in the LCD panel, when the panel is a bit too large for the viewing window and margins should be reserved for best result.

The minimum amount of line buffer required is determined by the active to total line count ratio in source vs in destination, if the frame rate is the same. Say the source takes 70% of a frame time to display all active lines, and the destination takes 80% due to their different frame structures, line buffers will be needed for 10% of the source line count, plus overhead by the scaler and whatnot.

Linear interpolation is simple but the image is not sharp enough to my taste. In a commercial design I ended up with windowed sinc interpolation with 4 taps and up to 32 phases. Linear interpolation use a 2 tap filter, so the line buffer structure is different.

Having a variable frame structure may work, but I wouldn't count on it for use in a product. Some LCD panels have explicit requirement for a stable frame structure, some are implied, others may not care. It may work on one panel, but may not work on 100s or 1000s of them, even for the same part number.

I'd say lack of upfront planning would cost the OP more time and effort to get to where he needs to be, but he seems to enjoy the journey. So please keep on.  :popcorn:
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #108 on: June 30, 2018, 10:15:56 pm »
I have been working on the schematic for the final board. Settled on TVP7002->iCE40HX8K-BG121->ADV7125.

Currently the FPGA drives the HSYNC and VSYNC lines of the output VGA. How could I check that this will be ok? I could add a buffer if necessary.
Read about my stuff at: projects.matthollands.com
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 2591
  • Country: ca
Re: FPGA video format conversion
« Reply #109 on: July 01, 2018, 03:25:30 am »
Not all monitors will work with a 3.3v coming out of the FPGA, and, if they do, it might be potentially on the edge of functionality that temperature could throw things off.  (I ran into this a few times, for real, but, I was testing with multiple completely different LCD screens... Some worked great at 3.3v.  Others seem to, however, mysteriously would go haywire at times.  The HS was sitting on the threshold of functionality for those screen and the FPGA output buffer moves slightly with it's temperature and that digital IO trying to feed a monitor cable and resistive load to GND at the other end.)

To be safe, I would use 74ACT04, or HCT04, 3 gates in parallel, powered from 5v, to drive that potential 75ohm load on HS&VS that some monitors have on the HS & VS inputs.  Others may have a 1k load, but, still, a nice low impedance 5v drive to spec is good and you will protect your FPGA from ESD and any other unpredictable surge from that VGA connector.

Between the FPGA output and the 74ACT04 inputs, I would have a 470 ohm pullup to 3.3v strengthening that crucial weaker high drive of the FPGA output to match it's larger low drive current and to pass that CMOS/TTL emulated threshold of a 5v powered HCT04/ACT04.

EG
                           -> T04 ->
FPGA OUT VS -> T04 -> VGA connector VS pin
                           -> T04 ->

                           -> T04 ->
FPGA OUT HS -> T04 -> VGA connector HS pin
                           -> T04 ->

In your FPGA code, just invert the HS & VS out.
« Last Edit: July 01, 2018, 03:35:02 am by BrianHG »
__________
BrianHG.
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #110 on: July 04, 2018, 07:21:43 am »
Depending on whether the VGA output is for an in-chassis VGA monitor or a DB-15 VGA connector and 6ft+ cable to the monitor. The sync driver may not be needed in the former case. Even if the sync driver is needed I would be careful with 74ACTs. They are fast and strong drivers, often too fast and too strong that create nasty reflections and ground bounce. Especially for the un-terminated sync lines. I have no idea why VESA specified a high load impedance for the sync signals but still use low-impedance coaxial cables for them. In that case proper clamping circuit at the source is probably more important than driving the full 5V voltage. The sync spec is in TTL levels so theoretically compatible with LVCMOS.
 

Online Yansi

  • Super Contributor
  • ***
  • Posts: 1808
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: FPGA video format conversion
« Reply #111 on: October 12, 2018, 09:10:21 am »
Isn't clamping already present, within the final stage of the '04 inverters? I mean, that complementary pair of mosfets has to have the substrate diodes connected somewhere, likely to a VDD and VSS. So clamping is already well present.
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #112 on: October 16, 2018, 07:51:54 am »
Well, it depends on what you want to get hit when the spike comes, the parasitic, un-characterized body diode in your multi-pin chip, or a more robust standalone diode right at the IO connector. Engineers may make different decisions base on many factors such as the cost structure and the usage environment of the product, etc.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf