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

0 Members and 1 Guest are viewing this topic.

Offline MattHollandsTopic starter

  • Frequent Contributor
  • **
  • Posts: 313
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #75 on: September 30, 2017, 09:14:02 am »
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, 09:20:38 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA video format conversion
« Reply #76 on: September 30, 2017, 10:53:07 am »
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, 10:58:16 am by BrianHG »
 

Offline MattHollandsTopic starter

  • Frequent Contributor
  • **
  • Posts: 313
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #77 on: February 25, 2018, 09:25:37 pm »
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
 

Offline BrianHG

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

Offline MattHollandsTopic starter

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

Offline BrianHG

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

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA video format conversion
« Reply #81 on: February 27, 2018, 06:47:12 pm »

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 27, 2018, 11:00:07 pm by BrianHG »
 

Offline MattHollandsTopic starter

  • Frequent Contributor
  • **
  • Posts: 313
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #82 on: February 28, 2018, 01:14:38 am »
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 MattHollandsTopic starter

  • Frequent Contributor
  • **
  • Posts: 313
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #83 on: February 28, 2018, 01:32:49 am »
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
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA video format conversion
« Reply #84 on: February 28, 2018, 02:04:42 am »
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.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA video format conversion
« Reply #85 on: February 28, 2018, 02:38:40 pm »
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.
 

Offline MattHollandsTopic starter

  • Frequent Contributor
  • **
  • Posts: 313
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #86 on: March 04, 2018, 10:00:55 pm »
#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 04, 2018, 10:03:31 pm by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline BrianHG

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

Offline MattHollandsTopic starter

  • Frequent Contributor
  • **
  • Posts: 313
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #88 on: March 04, 2018, 10:21:41 pm »
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 MattHollandsTopic starter

  • Frequent Contributor
  • **
  • Posts: 313
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #89 on: March 04, 2018, 10:53:13 pm »
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
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA video format conversion
« Reply #90 on: March 04, 2018, 11:10:18 pm »
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...
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA video format conversion
« Reply #91 on: March 05, 2018, 09:03:49 pm »
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.
 

Offline MattHollandsTopic starter

  • Frequent Contributor
  • **
  • Posts: 313
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #92 on: April 08, 2018, 02:11:37 am »
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
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA video format conversion
« Reply #93 on: April 08, 2018, 09:39:36 pm »
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 08, 2018, 10:24:37 pm by BrianHG »
 

Offline MattHollandsTopic starter

  • Frequent Contributor
  • **
  • Posts: 313
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #94 on: April 25, 2018, 11:10:31 pm »
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
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA video format conversion
« Reply #95 on: April 26, 2018, 12: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, 12:58:14 am by BrianHG »
 

Offline MattHollandsTopic starter

  • Frequent Contributor
  • **
  • Posts: 313
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #96 on: May 13, 2018, 06:12:36 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.

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
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA video format conversion
« Reply #97 on: May 14, 2018, 05:06:21 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.
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, 06:03:51 am by BrianHG »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA video format conversion
« Reply #98 on: May 14, 2018, 05:12:11 am »
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.

 

Offline MattHollandsTopic starter

  • Frequent Contributor
  • **
  • Posts: 313
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #99 on: May 15, 2018, 08:01:02 pm »
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 15, 2018, 08:03:58 pm by MattHollands »
Read about my stuff at: projects.matthollands.com
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf