Electronics > Projects, Designs, and Technical Stuff

Modern equivalent of 74HC4046 PLL?

<< < (11/19) > >>

Miti:

--- Quote from: BrianHG on July 22, 2020, 07:55:18 pm ---
--- Quote from: Miti on July 22, 2020, 12:29:21 pm ---
--- Quote from: BrianHG on July 22, 2020, 02:30:42 am ---Other than that, yes what I see roasts your old external PLLs.

--- End quote ---

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

--- End quote ---
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.

--- End quote ---

I didn’t plan for a digital PLL inside the FPGA.

Miti:

--- Quote from: BrianHG on July 22, 2020, 04:32:45 pm ---
--- Quote from: Miti on July 22, 2020, 12:29:21 pm ---
--- Quote from: BrianHG on July 22, 2020, 02:30:42 am ---Other than that, yes what I see roasts your old external PLLs.

--- End quote ---

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

--- End quote ---
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.

--- End quote ---

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?

BrianHG:
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.



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: ---
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


--- End code ---

BrianHG:
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.

BrianHG:
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: ---
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


--- End code ---

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod