How to reduce jitter of 30-bit accumulator

Hello,

I have a 30-bit accumulator in which I use the last bit as my clock out to
the design.

In the following way:



always @(posedge clk or negedge reset_n)

  begin

   if (!reset_n) nco_acc[29:0]  <= 0;

   else nco_acc[29:0] <= nco_acc[29:0] + constant;

  end



   assign clk_out = nco_acc[29];



I notice that when the constant is 26-bit width the jitter on the clk_out is
acceptable however when the constant is 27 bit wide the jitter on the
clk_out is not acceptable.

How can I reduce the amount of jitter on the clk_out.

(I can't use clkdll all are used already in the design)



Thank you,

Am wrote:
> Hello,
>
> I have a 30-bit accumulator in which I use the last bit as my clock out to
> the design.
>
> In the following way:
>
>
>
> always @(posedge clk or negedge reset_n)
>
>   begin
>
>    if (!reset_n) nco_acc[29:0]  <= 0;
>
>    else nco_acc[29:0] <= nco_acc[29:0] + constant;
>
>   end
>
>
>
>    assign clk_out = nco_acc[29];
>
>
>
> I notice that when the constant is 26-bit width the jitter on the clk_out is
> acceptable however when the constant is 27 bit wide the jitter on the
> clk_out is not acceptable.
>
> How can I reduce the amount of jitter on the clk_out.
>
> (I can't use clkdll all are used already in the design)
>
>
>
> Thank you,

What is "acceptable" jitter?

If you want a clock with little jitter, you either need a subdivided
clock frequency (50MHz/12587, for instance) where you code a simple
counter or you use an external PLL.

The "problem" with NCOs and jitter is that the clock edge will *always*
be at your system clock edge.  Sometimes it's before your "ideal"
clock, sometimes it's after.

If one of your clk_dll resources uses your system clock as input, the
CLK0 output can be joined by the CLK90, CLK180, and CLK270 outputs and
- with appropriate BUFGMUX or combinatorial logic, you can select which
of 4 phases to use rather than toggling at the CLK0 edge only.

If you can't even do that, all that's left is FPGA techniques that are
beyond the scope of most engineering designs (and not very well
characterized so the spec limits won't be easy to pin down).

- John_H
(who has contemplated a discrete DCM replacement)

On Dec 6, 2:50 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
> Am wrote:
> > Hello,
>
> > I have a 30-bit accumulator in which I use the last bit as my clock out to
> > the design.
>
> > In the following way:
>
> > always @(posedge clk or negedge reset_n)
>
> >   begin
>
> >    if (!reset_n) nco_acc[29:0]  <= 0;
>
> >    else nco_acc[29:0] <= nco_acc[29:0] + constant;
>
> >   end
>
> >    assign clk_out = nco_acc[29];
>
> > I notice that when the constant is 26-bit width the jitter on the clk_out is
> > acceptable however when the constant is 27 bit wide the jitter on the
> > clk_out is not acceptable.
>
> > How can I reduce the amount of jitter on the clk_out.
>
> > (I can't use clkdll all are used already in the design)
>
> > Thank you,What is "acceptable" jitter?
>
> If you want a clock with little jitter, you either need a subdivided
> clock frequency (50MHz/12587, for instance) where you code a simple
> counter or you use an external PLL.
>
> The "problem" with NCOs and jitter is that the clock edge will *always*
> be at your system clock edge.  Sometimes it's before your "ideal"
> clock, sometimes it's after.
>
> If one of your clk_dll resources uses your system clock as input, the
> CLK0 output can be joined by the CLK90, CLK180, and CLK270 outputs and
> - with appropriate BUFGMUX or combinatorial logic, you can select which
> of 4 phases to use rather than toggling at the CLK0 edge only.
>
> If you can't even do that, all that's left is FPGA techniques that are
> beyond the scope of most engineering designs (and not very well
> characterized so the spec limits won't be easy to pin down).
> 
> - John_H
> (who has contemplated a discrete DCM replacement)

Sorry for the hick-up.
The jitter has little to do with the length of the accumulator, but
rather with the nature of the accumulated number.
A higher clock rate of the accumulator always helps.
There are wasteful ways to reduce the jitter with multiple accumulators
plus a fast Serializer.
I am playing around with 16 accumulators plus an MGT, to reduce the
jitter below 200 ps for any value of a 32-bit DDS circuit. But that's
rather extreme...
(Except when you have plenty of accumulators to spare ...)
Peter Alfke

On Dec 6, 4:57 pm, "Peter Alfke" <p...@xilinx.com> wrote:
> On Dec 6, 2:50 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
>
> > Am wrote:
> > > Hello,
>
> > > I have a 30-bit accumulator in which I use the last bit as my clock out to
> > > the design.
>
> > > In the following way:
>
> > > always @(posedge clk or negedge reset_n)
>
> > >   begin
>
> > >    if (!reset_n) nco_acc[29:0]  <= 0;
>
> > >    else nco_acc[29:0] <= nco_acc[29:0] + constant;
>
> > >   end
>
> > >    assign clk_out = nco_acc[29];
>
> > > I notice that when the constant is 26-bit width the jitter on the clk_out is
> > > acceptable however when the constant is 27 bit wide the jitter on the
> > > clk_out is not acceptable.
>
> > > How can I reduce the amount of jitter on the clk_out.
>
> > > (I can't use clkdll all are used already in the design)
>
> > > Thank you,What is "acceptable" jitter?
>
> > If you want a clock with little jitter, you either need a subdivided
> > clock frequency (50MHz/12587, for instance) where you code a simple
> > counter or you use an external PLL.
>
> > The "problem" with NCOs and jitter is that the clock edge will *always*
> > be at your system clock edge.  Sometimes it's before your "ideal"
> > clock, sometimes it's after.
>
> > If one of your clk_dll resources uses your system clock as input, the
> > CLK0 output can be joined by the CLK90, CLK180, and CLK270 outputs and
> > - with appropriate BUFGMUX or combinatorial logic, you can select which
> > of 4 phases to use rather than toggling at the CLK0 edge only.
>
> > If you can't even do that, all that's left is FPGA techniques that are
> > beyond the scope of most engineering designs (and not very well
> > characterized so the spec limits won't be easy to pin down).
> 
> > - John_H
> > (who has contemplated a discrete DCM replacement)