Author Topic: Modern equivalent of 74HC4046 PLL?  (Read 13814 times)

0 Members and 1 Guest are viewing this topic.

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #75 on: July 24, 2020, 04:39:41 pm »
Last scope shot analyzed...
1031814-0

Still very good unless the measurement on the left is something in the codding, but somehow corrects itself afterward.  Make sure you were operating in the DDR mode...

Now in you scope measurements from above with the second PLL, that PLL seemed way too noisy compared to this reference 10.5MHz clock feeding it.  The PLL should have generated a cleaner clock.

Possible fixes:
1. Redo measurements with only 2 channels shown so you see scope samples at 500MS/s so there is less interpolation of missing data.
2. Change the second PLLs bandwidth setting to 'AUTO'.  The low bandwidth setting I recommended was for fixing up a terrible 10.5MHz reference.  Your 10.5MHz seems excellent, using the low bandwidth setting is actually making the PLL output more jittery.

Lets see how you plan to software shift the 10.5MHz reference clock in your soft-PLL code.
If you do not want to do it in your soft-PLL section, I recommend making your second PLL run at 84MHz not 21MHz and sample every 8th pixel while making an adjustment to begin 1 through 8 clocks from the beginning of the h-sync.

Remember, you cannot simultaneously tap that DDIO input from the pin IO on a different clock domain without hindering the soft-PLL's performance.  Within your soft PLL just double or triple register the sync_inh and feed that to an output on your soft-pll code and use that as a new h-sync to control your video sampler section.

« Last Edit: July 24, 2020, 05:14:07 pm by BrianHG »
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #76 on: July 25, 2020, 01:21:54 am »
Still very good unless the measurement on the left is something in the codding, but somehow corrects itself afterward.  Make sure you were operating in the DDR mode...

How? I thought, since we're using DDIO in and out, we are in DDR mode. I'm sorry for being such a noob but I am...a noob.

Now in you scope measurements from above with the second PLL, that PLL seemed way too noisy compared to this reference 10.5MHz clock feeding it.  The PLL should have generated a cleaner clock.

Possible fixes:
1. Redo measurements with only 2 channels shown so you see scope samples at 500MS/s so there is less interpolation of missing data.
2. Change the second PLLs bandwidth setting to 'AUTO'.  The low bandwidth setting I recommended was for fixing up a terrible 10.5MHz reference.  Your 10.5MHz seems excellent, using the low bandwidth setting is actually making the PLL output more jittery.

Attached.
I did try low, medium and high bandwidth. It doesn't make any difference.

Lets see how you plan to software shift the 10.5MHz reference clock in your soft-PLL code.
If you do not want to do it in your soft-PLL section, I recommend making your second PLL run at 84MHz not 21MHz and sample every 8th pixel while making an adjustment to begin 1 through 8 clocks from the beginning of the h-sync.

I was thinking a 16 bit LPM_SHIFTREG with 336MHz clock and the reset condition "if (!sync_inh && sync_inh_reg) at data input. Then I use a 4 bit register and in a case statement I assign one of the output of the shift register to a wire. Then I use that wire as a condition to
if (wire)
  begin
   counter < 1'b0;
   sync_inl_reg <= sync_inl;
  end
  else...
 
Remember, you cannot simultaneously tap that DDIO input from the pin IO on a different clock domain without hindering the soft-PLL's performance.  Within your soft PLL just double or triple register the sync_inh and feed that to an output on your soft-pll code and use that as a new h-sync to control your video sampler section.

A challenge a day from you Brian...
How do you do that?
« Last Edit: July 25, 2020, 01:55:35 am by Miti »
Fear does not stop death, it stops life.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #77 on: July 25, 2020, 03:01:58 am »
Ok, in verilog, you do not need to bother with the 'LPM_SHIFT_REG'.

At least not in system verilog, but lI gave it a try.

Here is what your have when feeding the (I'm guessing since you haven posted your latest code...)

Code: [Select]
clk_out_h       <= sync_inl_reg ? counter_dl[4] : counter[4];
clk_out_l       <= counter[4];

Here is what I did:
Code: [Select]
input wire          load_phase,  // make high when loading the new phase
input wire [3:0] phase_in,      //  0 through 15 phase positions
output reg         sync_out       // buffered H-sync output
...........
reg   [3:0] phase_reg;
reg   [31:0] clk_shift_h, clk_shift_l, sync_shift;
..........

if (load_phase) phase_reg <= phase_in;

//clk_out_h       <= sync_inl_reg ? counter_dl[4] : counter[4];  // directly send output clock
//clk_out_l       <= counter[4];
clk_shift_h[0]    <= sync_inl_reg ? counter_dl[4] : counter[4];  // load output clock into beginning of shift register
clk_shift_l[0]    <= counter[4];
clk_shift_h[31:1] <= clk_shift_h[30:0];                 // Shift the shift register
clk_shift_l[31:1] <= clk_shift_l[30:0];
clk_out_h         <= clk_shift_h[phase_reg[3:0]*2];  // use the loaded phase_reg to select every second 0 through 30 taps on the shift register
clk_out_l         <= clk_shift_l[phase_reg[3:0]*2];

sync_out          <= sync_inh_reg;  // pass the sync input to the output.


I tried this code and Quartus reported the FMAX at 256MHz, but you need 336.  So, do not bother adding the phase to the soft-pll code.  Only add the :

Code: [Select]
output reg sync_out
....
sync_out          <= sync_inh_reg;

For your video sampling section, do not tie it's H-sync reference to the h_sync input pin, tie it to this module's 'sync_out' reg.

I would recommend running your sampling code at 84MHz or 168MHz.  Basically configuring your second PLL to give you that frequency from the 10.5MHz.  And when you grab a pixel, grab every 8th or every 16th clock.  Your sample phase will be 3 or 4 bits, selecting which on of the every 8th or 16th clock you take in a pixel.


It should be no more complicated than this (168MHz example):

Code: [Select]
input  wire [3:0] phase_selection,
input  wire set_phase_selection,
output reg  test_sample_point,

.....


reg [3:0] current_phase, phase_selection_reg;

always @ (posedge clk168m) begin

last_sync_in <= h_sync_in;

if (set_phase_selection) phase_selection_reg <= phase_selection;

if ( ~h_sync_in && last_sync_in ) begin                        // H-Sync pulse low has been recieved
                                  current_phase <= 0;          // clear the phase
                                  cord_x        <= 0;          // clear the video raster X coordinate
               if ( ~v_sync_in )  cord_y        <= 0;          // clear the video raster Y coordinate
               else               cord_y        <= cord_y + 1; // increment the raster Y coordinate

end else begin // not an hsync pulse, a video line

    current_phase <= current_phase + 1;

      if (current_phase == phase_selection_reg) begin   // time to sample a pixel

               //write input pixel to dual port ram at cord_x //

               cord_x            <= cord_x + 1;
               test_sample_point <= 1;  // pulse the test sample point
      end else test_sample_point <= 0;  // clear the pulsed test sample point

  end // end of video line

end // always @ posedge

(84MHz is the same except the current_phase & phase_selection will now be 3 bits instead of 4 bits.  The width of the test output pulse will also now be 42MHz instead of 84MHz.)

Making this code now without the ram, just the test_sample_point output feeding an output would reveal a tiny 84Mhz pulse once per pixel which you can move left and right, 16 positions, depending on the 'phase_selection'.

If you need to test and do not currently have an effective way of driving the 'phase_selection' with a number, and your dev board has an rs232 port, you may use my 'SYNC_RS232_UART.v' here:

https://www.eevblog.com/forum/fpga/verilog-rs232-uart-and-rs232-debugger-source-code-and-educational-tutorial/

You may also use the full RS232_debugger if you want to real-time read 4 byte ports, write 4 byte ports, and address read/write memory.

(warning, some FTDI USB-RS232 converters interfere with Quartus USB Blaster.  You just need to close the COM port before using the programmer & then you can re-open the com port.)

Note, if the test pulse jitters left & right, it's because of the way we are reading and converting the hsync coming in and how the clock is being generated.  The fix will be to make a 10.5MHz output on the second PLL as well as the 168MHz, and in your code, then first latch the sync into a register with an:

always @ (posedge clk10_5) begin
h_sync_clk10_latch <= hsync_in;
end

Then in the main code section, replace the h_sync_in with h_sync_clk10_latch.  This should extra clean up the h_sync.  If not, you may need to change the (posedge clk10_5) to a (negedge clk10_5).
« Last Edit: July 25, 2020, 03:43:22 am by BrianHG »
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #78 on: July 25, 2020, 11:58:31 am »
Please keep in mind that I need 55.125MHz as well for the VGA side. The second PLL cannot generate more than 42MHz in this combination. I think I’m okay though, maybe using bit 0 of the selection register to enable/ disable an inverter, this way I can use both rising and falling edges.
Fear does not stop death, it stops life.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #79 on: July 25, 2020, 12:28:17 pm »
So just use 42Mhz with 2 bits phase selection, 4 sample points.  + Only if you really need it, a DDIO_in on the video input bits allowing for a selection of when you grab the pixels, on the high or low transition edge of a clock of the 42MHz making a total of 8 sample phases to choose from.

I'm curious, what kind of panel are you using?
Most standard vesa video modes, like 1024x768 has a 65MHz clock, not 55.125MHz.

In fact, looking here: http://tinyvga.com/vga-timing
Code: [Select]
http://tinyvga.com/vga-timing/1024x768@60Hz
I don't see any multiple of 55.125MHz.

LOL, if your scope output 512x256 2 bit color, you have enough ram on the smallest CycloneIV to store an entire frame.
With a standard UART at 921600 baud, you can display around 3fps on a PC without any compression.
Probably around 10fps with dumb RLE compression.
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #80 on: July 25, 2020, 01:53:39 pm »

I'm curious, what kind of panel are you using?
Most standard vesa video modes, like 1024x768 has a 65MHz clock, not 55.125MHz.

In fact, looking here: http://tinyvga.com/vga-timing
Code: [Select]
http://tinyvga.com/vga-timing/1024x768@60Hz
I don't see any multiple of 55.125MHz.

LOL, if your scope output 512x256 2 bit color, you have enough ram on the smallest CycloneIV to store an entire frame.
With a standard UART at 921600 baud, you can display around 3fps on a PC without any compression.
Probably around 10fps with dumb RLE compression.

This one:
https://www.aliexpress.com/i/4000282196847.html

I know it is not a standard VGA pixel clock but the panel, and two monitors, have no issues locking onto this pixel rate and auto adjusting the position right in the middle. This is the only frequency that I found to give me a VGA framerate identical to the video framerate, with a little tweak in the front and back porch. This simplifies my buffering a lot. I don't need external double or tipple buffer to avoid flickers.
I also avoid the need for blending with driving the LCD panel directly, as the panel is only 640x480.
The video output is 509?x254 visible if my measurements are correct, so double the pixels and triple the lines, would fit quite nicely into 1024x768 VGA with some spare pixels left and right and lines top and bottom.

Edit: In Reply #10 you can see a picture of the panel showing a test pattern with the exact specs that I mentioned before, including three pixel wide horizontal lines.
« Last Edit: July 25, 2020, 02:20:23 pm by Miti »
Fear does not stop death, it stops life.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #81 on: July 25, 2020, 04:06:38 pm »
Ok. No prob.  I assumed you would use the panel at it's native edge to edge and scale the scope's sample image onto it either with a panel which was exact 2x by 3x, or, you would use a lower res panel like 640x480 and do a bi-linear or bi-cubic filtering, or even a sub-pixel scaling.  (IE sup-pixel scaling of a 640x480 LCD panel makes the panel appear to be 1920x480.  (some panels have a special RGB matrix which make their 640x480 sub-pixel mode more like 1280x960) This trick would make 512 pixels, or 509 pixels stretch much more nicely onto 1920 pixels wide without clunky edges.  However, you MUST be feeding the panel at it's native res, otherwise you will get color artifacts when doing this trick wrong.)
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #82 on: July 26, 2020, 02:03:16 am »
Ok, so I implemented the PLL clock, the ADC I2C reader and the IR into the VGA pattern generator. The ADC reads the brightness potentiometer, the IR input is used to select different color schemes. The module will have few color schemes with different colors for low and high brightness to give a bit of color to this old thing.

I then compared the vertical sync pulses of the spectrum analyzer and of the VGA output. Without HSync they drift slightly relative to each other. Once I connected the HSync, they are dead locked as they should be, and the pattern is very stable. I let them run for minutes and there was zero drift. Se attached.
Fear does not stop death, it stops life.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #83 on: July 26, 2020, 02:12:05 am »
Excellent.  Though I don't know the extent of you project, but if you stored the entire source image in the Cyclone DualPort ram, you don't really need the output video locked into the source video.  Your perfect locking is good if you only want to use a single 9kbit block of ram to generate the output image.

Is it just me, or is your video in 49.8Hz and your video out 99.6Hz?
LCD screens wouldn't flicker at 49.8Hz unless you want to drive VGA CRTs.

I assume for the brightness, you will just be assigning 2 contrast levels to the 2 source video levels before sending that to the LCD.

Maybe something with a little optional color, like you stated...

(FPGA tech note:  When defining any type of large memories like dual port or fifos with Cyclone FPGAs, they will round up you chosen memory size to the nearest 9kbits when fitted in the FPGA fabric.  So, if you have a 512x8 line buffer, it will still end up consuming a 1024x9 chunk in the Cyclone block ram.  The undefined region will just be ignored and never used.)
« Last Edit: July 26, 2020, 02:57:21 am by BrianHG »
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #84 on: July 26, 2020, 03:05:49 am »
Excellent.  Though I don't know the extent of you project, but if you stored the entire source image in the Cyclone DualPort ram, you don't really need the output video locked into the source video.  Your perfect locking is good if you only want to use a single 9kbit block of ram to generate the output image.

You are right, the reason I wanted to use only half image buffer is to reduce the output lag relative to the input image. Not sure if that is important though.

Is it just me, or is your video in 49.8Hz and your video out 99.6Hz?
LCD screens wouldn't flicker at 49.8Hz unless you want to drive VGA CRTs.

I assume you say that because you don't see the middle pulse in channel 1. Look at the gap in the thick yellow trace. They are both same frequency.
If you read from output port while you write to the input port, the image may blink for a moment. Also, when the output image starts in the middle of the input image due to drift, if there's a dramatic change in the input image, I think it would show. That's the flicker I was talking about.

I assume for the brightness, you will just be assigning 2 contrast levels to the 2 source video levels before sending that to the LCD.

Maybe something with a little optional color...

The input image would have 2 bits. 00 for black, 01 for low brightness and 11 for high brightness. The input from the ADC is a 10 bit value. The VGA output is 0-1023, even though it will be mapped to 16 or 32 output levels, I haven't decided yet. My intention is to multiply the ADC value with bit 0 or bit 1 to get the VGA output value and color according to the color scheme.
There will be 5 - 6 color schemes selected either using an external IR remote, or fixed scheme using jumpers.
There's a hole on the side of the case for focus adjustment in the CRT display that I can use for an IR sensor.
Fear does not stop death, it stops life.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #85 on: July 26, 2020, 03:18:13 am »

I assume you say that because you don't see the middle pulse in channel 1. Look at the gap in the thick yellow trace. They are both same frequency.
If you read from output port while you write to the input port, the image may blink for a moment. Also, when the output image starts in the middle of the input image due to drift, if there's a dramatic change in the input image, I think it would show. That's the flicker I was talking about.

Is this because you cannot retain a perfect H-sync from input to output image?
A delay of your output image by 1 or 2 lines of video should prevent this problem.

When you say blink, what do you mean?
Does the image jump vertically by a line, or a scrolling line jump, or something like that?

Since I don't know how you designed your architecture, I cannot foresee any approach I would use which would cause a blink of any sort.  A delay of 2-3 lines of video, IE a 1/5000 of a sec delay from picture in to picture out is nothing at all.  A delay of even 1 full frame at 1/50th of a second would not be registered or perceived by anyone.
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #86 on: July 26, 2020, 03:27:36 am »
I thought about that right after I posted. The frames should not drift at all if HSync is present, is just that they start in random position relative to each other. Let me give it more thought.
Fear does not stop death, it stops life.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #87 on: July 26, 2020, 03:35:29 am »
I thought about that right after I posted. The frames should not drift at all if HSync is present, is just that they start in random position relative to each other. Let me give it more thought.
Though this is easily solved, it still makes no difference if your picture out is delayed by 2-3 lines of picture.
You would literally have written 2-3 full lines in your 4 line buffer before the first one comes out.

You can also use the hsync coming into the sampler to reset the horizontal position counter of the hsync coming out of your VGA pattern generator.  Or, if you look at my sampler code, you can make an output which pulses at any cord_x number which you can use to reset the output horizontal position of your VGA generator to align it the way you like.  Same with the cord_y counter in my example code.  You can make the your output vsync begin on line 0, 1, 2 or 3 or any vertical position of the source video coming in.
« Last Edit: July 26, 2020, 03:37:40 am by BrianHG »
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #88 on: July 26, 2020, 06:00:02 pm »
Since we deviated pretty much from the initial PLL subject, I suggest we continue the discussion here:

https://www.eevblog.com/forum/projects/hp-8594e-replacing-the-green-crt-with-lcd/msg3022500/#msg3022500

That project will be the end application of this experiment plus these ones:

https://www.eevblog.com/forum/fpga/converting-a-two-level-analog-signal-to-two-bits-digital-in-cyclone-iv-orand-v/
https://www.eevblog.com/forum/fpga/adc-in-altera-cyclone-fpga/                    which I will finalize one day using your code with shift registers.
Fear does not stop death, it stops life.
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #89 on: July 29, 2020, 02:06:46 am »
In my designs, I usually fast input & fast output register all IOs in my designs at the minor possible cost of reaching an FMAX.

I assume digital IOs? I don't think it makes sense assigning fast IO registers to LVDS IOs.
Fear does not stop death, it stops life.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #90 on: July 29, 2020, 02:50:05 am »
In my designs, I usually fast input & fast output register all IOs in my designs at the minor possible cost of reaching an FMAX.

I assume digital IOs? I don't think it makes sense assigning fast IO registers to LVDS IOs.
Just go ahead.
Don't worry about FMAX, it's not like you have filled the FPGA to 98% logic registers full and you are trying to achieve an FMAX of 200MHz for the entire chip.

The fast in&out just directs the fitter where to optimize the location of the register D-flipflop on the FPGA fabric.  Locating the flipflop closest to the IO if that flipflop is the one generating an output, or reading an input just makes that associated IO pin have the tightest possible timing.

Using a flipflop on the right hand side of the fpga to drive an IO pin on the left hand side of the fpga might mean an internal better FMAX, but, that IO pin will probably have a huge delay before that data becomes valid.  Now unless you are willing to learn about defining the setup&hold times and constrained paths for IO pins, the fast IO is a cheap trick to tell to compiler to prioritize the IO pin's performance.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf