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

0 Members and 1 Guest are viewing this topic.

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #50 on: July 22, 2020, 08:56:26 pm »
Other than that, yes what I see roasts your old external PLLs.

I totally agree! And about the title of this topic, I don't think you can find any more modern equivalent of HC4046 than this... :-DD
Your topic and location was in the wrong place.  I only found it by luck in with your other thread in the FPGA section.

If you made your topic in the FPGA section:
'Is it possible or Can you make a Cyclone PLL lock onto a 15KHz video source for a sampler clock?'
You would have never had to bother playing with any PLL ICs in the first place.

Though, you would never know how tricky it is to make those ICs operate in a clean behaved manner.

I didn’t plan for a digital PLL inside the FPGA.
Fear does not stop death, it stops life.
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #51 on: July 22, 2020, 10:03:11 pm »
Other than that, yes what I see roasts your old external PLLs.

I totally agree! And about the title of this topic, I don't think you can find any more modern equivalent of HC4046 than this... :-DD
Well, if you really wanted to ultimately get it as good as possible, with some much better clever coding, like running 2 long period counters at the top 500MHz, one on the positive clock and the other on the negative clock, with an emulation of the PC2 on the 4046 either letting the counters run free, subtract 1 or add 1 once in a huge period of the HS coming in, we can shrink that +/- 1.5ns jitter down to 0.5ns.  However, if the old external PLL worked with that +/-10ns jitter, +/- 1.5 should be fine.  Just adding a second neg_clk counter to your current logic with a little careful DDR output trick feeding the Cyclone's second PLL would cut your current theoretical +/-1.5ns jitter in half.

Basically we would be making your design appear to be operating at 672MHz and we would be using second's PLLs low bandwidth to average 2 of the reference counters driving the same current output pin in a swapping MUX configuration, basically using the output pin the same way a DDR output is driven, except the swap from n-counter bit 5 to the p-counter bit 5 would only be done once after every 2 or 4 10.5mhz cycles.  To verify this would be functioning properly, you would want a scope with at least 5 GSPS.  (IE: if your scope maxes out at 500MSPS, how do you expect to debug the fine transition timing of a 672MHz clocked source?)


Either that, or on the output 10.5MHz output pin, feed it in series through a 1pf cap or even a FM radio 10,5MHz ceramic IF filter to a tuneable inductor/transistor amp with a bandwidth below 7KHz and feed that transistor's output into the CLK input back into the Cyclone erasing all remaining jitter so long as the transistor amp and circuit board analog noise is well isolated from the circuit.

Looking at the jitter on the scope I don’t think it is necessary but it’s an interesting exercise, so let’s do it.
So two 5 bits counters, one always @(posedge) and the other always @(negedge).
Bit4 (counting from 0) of both counters connected to a MUX. The rest of the circuit doesn’t change.
The MUX is switched by another counter after every 2 - 4 cycles. Who clocks that counter?
Fear does not stop death, it stops life.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #52 on: July 23, 2020, 12:08:04 am »
Ok, I've done a few timing simulations.  After experimenting around, there was only 1 way to get consistent clean output results.  Negative edge clock was not used.  All that was needed was the 'ALTDDIO_IN' megafunction for the sync input.  This function automatically sets up a bunch of hidden timing corrections to some internal registers so the the sync in is captured on the rising and falling edge of the 336MHz clock, however, the results of the previous negative edge capture are delayed and are presented on the positive edge of the next clock.  Basically it has 1 input, 2 outputs, dataout_h, dataout_l.

Here is the simulation I came up with.
Note that 'clk_outa' is what feeds the input of the second PLL.
Output 'clk_fix' is a test output for visualization of the internal counter generating th 10.5MHz clock.
Notice what happens to 'clk_outa' when I shift the falling edge of 'SYNC_IN' by half a 336MHz clock at a time.

1029260-0

Now, because you are operating with a DDR input sampling at 672MHz when the theoretical limit is 500MHz, there were some things I had to set in Quartus to get reliable results.  It doesn't matter what your reported FMAX is, the outputs get skewed and the input sampling phase timing isn't as reliable without these changes.

In assignment settings, compiler settings:
1. Choose Speed or Performance, not Balanced or anything with 'Area' in the settings.
2. Do not prevent register retiming.  It is needed for the DDR input.
3. In advanced settings, make sure 'Power Optimization During Synthesis' is turned off.
4. In Fitter advanced settings, make sure 'Power Optimization During Fitting' is turned off.

In the project's pinout:
1. At minimum, your SYNC_IN should be on a DDR_DQ IO pin on a high speed IO bank.  (If I remember correctly, the top & bottom IO banks are high speed and left and right side ones are slower, however, this is on BGA I don't know about QFP)
2. It is preferable that your 10.5MHz clock output is in the same IO bank.

This will make your design run as fast as possible.  Not that it's going any faster than 336MHz, but the IO pin timing will be tight enough that you will capture that half-clock cycle SYNC_IN with high enough quality phase that it will inprove your PLLs overall jitter.

Here is the System verilog code I wrote to generate the output:

Code: [Select]

module MITI_PLL_Divider (
        input  logic clk,
        input  logic sync_inh,
        input  logic sync_inl,
        output logic clk_out,
        output logic clk_fix
        );

logic   [5:0]  counter, counter_dl;
logic   sync_inh_reg, sync_inl_reg;

always_ff @(posedge clk) begin

sync_inh_reg <= sync_inh;
counter_dl   <= counter;
clk_out      <= (counter_dl[5] && sync_inl_reg) ? counter_dl[4] : counter[4];

clk_fix      <= counter[4];

if (!sync_inh && sync_inh_reg) begin
                               counter      <= 0;
                               sync_inl_reg <= sync_inl;
                      end else counter      <= counter  +1;
end // @posedge clk

endmodule


« Last Edit: July 23, 2020, 12:11:23 am by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #53 on: July 23, 2020, 12:21:49 am »
Yes, it is possible to use a 'ALTDDRIO_OUT' and properly set it datain_h and datain_l so that you may generate a data_out with a half phase delay instead of my jump ahead and back every full clock cycle, however, you will need to simulate the results to guarantee you get the tricky part right during a change in alignment.  Again, there will be no negedge clock.  And this time around, the 10.5MHz clock output pin will require it be placed on a DDR IO output pin in the same high speed IO bank as the SYNC_IN DDR input.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #54 on: July 23, 2020, 12:38:01 am »
Ok, ok, ok, twist my leg...
Here is the perfect solution using the DDR output which makes a near perfect 10.5MHz clock which will have a theoretical +/- 0.7ns jitter, so long as the Hsync coming in doesn't have any jitter of it's own.


Code: [Select]

module MITI_PLL_Divider (
        input  logic clk,
        input  logic sync_inh,
        input  logic sync_inl,
        output logic clk_out_h,
        output logic clk_out_l,
        output logic clk_fix
        );

logic   [5:0]  counter, counter_dl;
logic   sync_inh_reg, sync_inl_reg;

always_ff @(posedge clk) begin

sync_inh_reg <= sync_inh;
counter_dl   <= counter;
clk_out_h    <= sync_inl_reg ? counter_dl[4] : counter[4];
clk_out_l    <= counter[4];

clk_fix      <= counter[4];

if (!sync_inh && sync_inh_reg) begin
                               counter      <= 0;
                               sync_inl_reg <= sync_inl;
                      end else counter      <= counter  +1;
end // @posedge clk

endmodule

« Last Edit: July 23, 2020, 12:40:20 am by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #55 on: July 23, 2020, 12:48:48 am »
Judge the difference for yourself...
1029280-0
 
The following users thanked this post: Miti

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #56 on: July 23, 2020, 02:20:37 am »
This should roast your reference function generator's 4ns jitter.
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #57 on: July 23, 2020, 02:31:12 am »
Judge the difference for yourself...
(Attachment Link)

So half a clock shift vs one clock shift. I don't speak system verilog but seems easy to translate to verilog.
By DDR_DQ IO pin, you mean one of those pins marked with Q in the pin planner, but use it as 3.3V TTL default, right?
Fear does not stop death, it stops life.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #58 on: July 23, 2020, 03:44:05 am »
To translate to verilog, except for the inputs, the 'logic' changes to 'reg'
input 'logic' changes to input wire.
'always_ff' changes to 'always'.

You can completely get rid of the 'clk_fix'.

Any IO voltage you use will work with 'ALT_DDIO_IN/OUT'.

As for the ALTDDIO_IN&OUT, they are in the mega IP store in the IO section.  Just set those up the same way you did your current PLLs in your existing code.  As long as you don't cross up the _h and _l, the code should make a clean clock.

Yes, on the top or bottom set of IOs for the FPGA, any IO pin would do.  Stick to 1 IO bank with a PLL in it for best results.  Just remember that in the future, you may want to reserve a dedicated PLL output pin if you will be clocking something like a ram chip.

Also, when feeding the 10.5MHz out back into the FPGA, the closest dedicated CLK input is usually the best choice.

The columns on the sides will also work, however, their response is a little slower.

I tried to simulate this design on Quartus Prime 18, LOL, it wouldn't even provide a clock output (it worked in functional mode, but not timing mode) and everything was dead due to Quartus believing that the PLL cant output a 336MHz clock though Quartus 9 seems to disagree.  An yet, your HDL was already clocking at 336MHz.

« Last Edit: July 23, 2020, 04:05:46 am by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #59 on: July 23, 2020, 04:14:23 am »
To compare the DDR to the SDR version, just change this line:

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

Code: [Select]
clk_out_h    <=  counter[4];
Or, make an new input wire ' enable_ddr ' and do this:

Code: [Select]
clk_out_h    <= (sync_inl_reg && enable_ddr) ? counter_dl[4] : counter[4];
So you may switch the DDR on and off in real-time when testing.
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #60 on: July 23, 2020, 03:51:00 pm »
Now, because you are operating with a DDR input sampling at 672MHz when the theoretical limit is 500MHz, there were some things I had to set in Quartus to get reliable results.

So we’re exceeding the maximum frequency of Cyclone 4? Is that a good idea and can I expect repeatable results between chips and between boards?
Fear does not stop death, it stops life.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #61 on: July 23, 2020, 04:49:53 pm »
Well, we are keeping that 336MHz internal.  It's only driving 18 registers.  Quartus compile timing report says that the FMAX is well above the 400MHz space, but the 'Restricted FMAX' is 250MHz.  This restriction is in place because they do not want you to drive IO pins with a signal greater than 250MHz.  The problem here is if you try to output the 336MHz, even on a dedicated PLL output pin.  That pin will need to open and close an N-channel and P-channel mosfet 672 million times a second without overlap, otherwise, that small transition time when both mosfets draws more current than what that section of the IC may be designed to do, including trying to charge and discharge the capacitance on the IO pin itself, and this current can get huge especially if you have a BGA with 128 IOs doing all this switching at the same time at the same speed.  In fact, reading deep into the Intel Cyclone data sheets, there actually are total IO usage limits with particular current settings, or particular IO standard settings on the chip at top frequencies.

Tell me, does your current PLL design make the FPGA burn your finger?

For this PLL, we are getting away with it since our 1 output pin never exceeds switching at 10.5MHz and 1 input at 15KHz.  If you need to output a clock of the first 336MHz PLL, though the 336 might will make it through, I would recommend making the PLL have a second output at 1/2, 168MHz, and feed that to the PLL output pin.

Here, I strategically chosen the IOs on 1 bank where a PLL is located running the MITI_PLL for a Cyclone III 144pin QFP, 3.3v LV TTL mode.  (Basically equivalent to the Cyclone IV, but Quartus 9 only simulates Cyclone III and later versions of Quartus no longer simulate designs).
1030674-0

Now here is the new timing simulation with the strategic IO settings:

1030678-1

Notice how much better the DDR IO trick creates an in between clock cycle compared to my last simulation where the IO went anywhere on the FPGA.

When you make your design, I'm expecting you will not output a 336MHz clock.
If you are really afraid, you can always run the PLL at 168MHz instead and use the DDR trick to achieve an equivalent 336MHz function which you already have now without the DDR.

(I have a sneaky suspicion when you use the ALT_DDIO_xxx function, they are clocking the final pin IO register with either 2 phases from the PLL clock, or at 2X speed with a dedicated shift register to move that half phase data back onto your main CLK for your logic.  I cannot achieve such clean DDR timing by any other means other than using the ALT_DDIO megafunction other than overclocking the design to 2x speed.)
« Last Edit: July 23, 2020, 09:27:14 pm by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #62 on: July 23, 2020, 05:21:54 pm »
1030160-0

Intel/Altera may have just made it policy to kill the simulation results just at the clock reaches 250MHz since they figure no one would bother create such a simple 20 register design which can run above 250MHz , yet not do anything complicated.  I guess it's a lack of imagination.
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #63 on: July 23, 2020, 05:31:40 pm »
Tell me, does your current PLL design make the FPGA burn your finger?

Far from that, the board only takes 80mA from 5V running only the PLL.
Fear does not stop death, it stops life.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #64 on: July 23, 2020, 05:38:42 pm »
Ok, so I guess we are waiting for you to place a resistor divider terminator for the scope 5v sync output into the cyclone & scope the PLL out in both SDR336MHz and the new DDR336MHz mode.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #65 on: July 23, 2020, 05:47:21 pm »
The Quartus Prime simulation failure is clearly a bug.  Here it is, right from the Cyclone IV data book:



Do not worry, we are completely in the clear unless your CycloneIV is the slowest low power version -9L...
Also notice my previous post FMAX and the -8 PLL maximum clock frequency.
Including the Fout to the dedicated PLL output pin which has a 472.5MHz limit.
I guess you can output the 336MHz if you want.

« Last Edit: July 23, 2020, 09:28:09 pm by BrianHG »
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #66 on: July 23, 2020, 09:03:57 pm »
Brian, something happened to the firsts attachment in #61, it is the same with the one in #65.
Fear does not stop death, it stops life.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #67 on: July 23, 2020, 09:26:31 pm »
Brian, something happened to the firsts attachment in #61, it is the same with the one in #65.
I know EEVblog has recently been corrupting attachments along may different posts for different people for some reason.
Give me a sec, I kept the originals just in case.  I'll re-upload the attachments right now.

Done, I checked them, they are OK as of 5:27 est GMT -5:00.
« Last Edit: July 23, 2020, 09:28:49 pm by BrianHG »
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #68 on: July 24, 2020, 02:29:33 am »
And here it is. PLL1 is the one without DDIO, PLL2 is with DDIO. The screen shots are with HSync from the spectrum analyzer and 10 seconds persistence. They are captured at the trigger point and one line (next HSync pulse) after the trigger point. Apparently there is a bit of jitter in the SA clock as well but the results are much better. 5V supply current is 82mA.

Thanks Brian, this works great!!!

Edit: The forum does what it wants with the attachments. Arrgh!
Edit1: I added some pixel shots. There's always a 21MHz falling edge of the 21MHz clock right in the middle of the pixel. With a simple inverter I could make that the write clock for the dual port RAM. And that is an extra indication that the clock is locked on the pixel (well HSync) clock.
« Last Edit: July 24, 2020, 02:51:00 am by Miti »
Fear does not stop death, it stops life.
 
The following users thanked this post: BrianHG

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #69 on: July 24, 2020, 02:50:42 am »
10 second persistence, I don't think you will have trouble either sampling the video from the scope with that clock as you were zoomed into 5ns per division & I think your pixel width was 100ns.  Using the PLL2, the jitter seemed to be under 1 division, 2.5ns, a little worse than my predicted 1.4ns.  Though, with all the accumulated noise around, quality of scope's internal clock & TTL driver sync output, & I don't know if your FPGA PCB has a dedicated supply layer for the analog PLL supply, you are doing an order of magnitude better than the dedicated PLL with it's 25ns jitter.

Should have done the measurements with only 2 channels active so you get 500MS/s instead of the 250MS/s.

Ok, you have 1 chore left, just add the ability to shift the 21MHz output phase with a 4 bit input to you verilog code giving you 16 select-able positions + a pass through of the H_Sync_in with that carried delay to prevent horizontal alignment capture jitter.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #70 on: July 24, 2020, 02:55:57 am »
Also, you are zoomed in too close.  What I really want to see is the beginning of the sync trigger at the left of the scope, and 20ns/div, only viewing the sync in and the DDIO output pin, not PLL#2.  This will show us how the counter is behaving during hsync reset, like is it being squished or stretched.  remember, that output DDIO output 10.5mhz reset takes effect something like 10-15ns after the h-sync in and we want to see a full cycle.  You should be scoping only on every h-sync to view this one right.

This will prove that the clock of 21MHz divides into a perfect integer of the scopes H-sync.

Right now, you cannot see the reset trigger point as it takes place further to the right of you scope shot.
« Last Edit: July 24, 2020, 03:06:02 am by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #71 on: July 24, 2020, 03:19:11 am »
Edit1: I added some pixel shots. There's always a 21MHz falling edge of the 21MHz clock right in the middle of the pixel. With a simple inverter I could make that the write clock for the dual port RAM. And that is an extra indication that the clock is locked on the pixel (well HSync) clock.
Look carefully at your pixel clock scope shots.  It's the rising edge of the cyan colored clock which always grabs the middle sweet spot of a pixel where it's analog vertical height stabilizes.  I'm counting each video element on the screen being 2 pixels wide at 21MHz.  The falling edge of the cyan clock is on the edges of a pixel.  Yet, you wont find out much until you grad the data coming into the cyclone as the inputs have a delayed setup time.  At 15Khz, this means your video coming out has a vertical resolution of something like 1024 pixels, ie 1024x240.  A little odd.  I would have suspected that the true sampling clock was 10.5 MHz making a screen res of 512x240.

Just like TTL logic using a resistor divider to drive a pseudo analog dac, it also seems that the video out of you scope falls slightly faster than it rises.  Easy to see when you have a clean sampling clock overlayed on your oscilloscope image.
« Last Edit: July 24, 2020, 03:23:19 am by BrianHG »
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #72 on: July 24, 2020, 03:34:49 am »
Also, you are zoomed in too close.  What I really want to see is the beginning of the sync trigger at the left of the scope, and 20ns/div, only viewing the sync in and the DDIO output pin, not PLL#2.  This will show us how the counter is behaving during hsync reset, like is it being squished or stretched.  remember, that output DDIO output 10.5mhz reset takes effect something like 10-15ns after the h-sync in and we want to see a full cycle.  You should be scoping only on every h-sync to view this one right.

This will prove that the clock of 21MHz divides into a perfect integer of the scopes H-sync.

Right now, you cannot see the reset trigger point as it takes place further to the right of you scope shot.

Like this? I can't see neither squish nor stretch.
Fear does not stop death, it stops life.
 

Offline MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #73 on: July 24, 2020, 03:39:17 am »
Look carefully at your pixel clock scope shots.  It's the rising edge of the cyan colored clock which always grabs the middle sweet spot of a pixel where it's analog vertical height stabilizes.  I'm counting each video element on the screen being 2 pixels wide at 21MHz.  The falling edge of the cyan clock is on the edges of a pixel.  Yet, you wont find out much until you grad the data coming into the cyclone as the inputs have a delayed setup time.  At 15Khz, this means your video coming out has a vertical resolution of something like 1024 pixels, ie 1024x240.  A little odd.  I would have suspected that the true sampling clock was 10.5 MHz making a screen res of 512x240.

Nope, the pixel clock is 10.5MHz, the oscillator is 21MHz. Pixel width is about 95us but I wanted to generate 21MHz exactly so I can have few edges to chose from. I will however implement the phase shifter.
Fear does not stop death, it stops life.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Modern equivalent of 74HC4046 PLL?
« Reply #74 on: July 24, 2020, 03:46:04 am »
Look carefully at your pixel clock scope shots.  It's the rising edge of the cyan colored clock which always grabs the middle sweet spot of a pixel where it's analog vertical height stabilizes.  I'm counting each video element on the screen being 2 pixels wide at 21MHz.  The falling edge of the cyan clock is on the edges of a pixel.  Yet, you wont find out much until you grad the data coming into the cyclone as the inputs have a delayed setup time.  At 15Khz, this means your video coming out has a vertical resolution of something like 1024 pixels, ie 1024x240.  A little odd.  I would have suspected that the true sampling clock was 10.5 MHz making a screen res of 512x240.

Nope, the pixel clock is 10.5MHz, the oscillator is 21MHz. Pixel width is about 95us but I wanted to generate 21MHz exactly so I can have few edges to chose from. I will however implement the phase shifter.

This is what the '4 bit sample phase (now 5 bit)' adjustment is for.  It shifts the 10.5MHz sample clock to 1 of 32 horizontal positions.  Something your 21MHz 2 positions in a 10.5MHz clock cannot do.

As for your latest scope shot, that looks dead perfect.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf