UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor notanother
Visitor
9,887 Views
Registered: ‎12-01-2015

Duty Cycle Problem with 320 Mhz

Jump to solution

Hi friends,

 

I have a problem with MMCM.

I need 320 Mhz clock frequency with %50 duty cycle

So I have to see 3.125 ns clock period and 1.5625 at high, 1.5625 ns at low for %50 duty cycle.

MMCM provide me 3.125 ns clock period but 1.625 at high 1.500 ns at low

I tied 320 Mhz input clock to MMCM with exact %50 duty cycle but the output 1.625 at high 1.500 ns at low

 

I read virtex 7 clocking guide. I found these

"The ISE or Vivado design tools will round up or down to the nearest multiple of 0.125 if the value is not specified as an exact 1/8th fraction"

"The resolution of the fractional divide is 1/8 or 0.125, effectively increasing the number of synthesizeable frequencies by a factor of eight"

 

But I really need 320 Mhz clock frequency with %50 duty cycle

 

What can I do?

Do you have an idea?

What is the disadvantages of not using MMCM in my design?

0 Kudos
1 Solution

Accepted Solutions
Scholar austin
Scholar
17,164 Views
Registered: ‎02-27-2008

Re: Duty Cycle Problem with 320 Mhz

Jump to solution

Time resolution is simulation,

 

Has nothing to do with the hardware.  Your 'problem' is solved.  Now you need to learn how to direct the simulator to use a finer simulation resolution (which will slow it down, and take longer to run, hence why the resolution gets set to a coarse value).

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
11 Replies
Scholar austin
Scholar
9,864 Views
Registered: ‎02-27-2008

Re: Duty Cycle Problem with 320 Mhz

Jump to solution

n,

 

I suspect it is exactly 50%, and you are measuring it either at the wrong place, or using an incorrect method.

 

To get the clock out without duty cycle distortion, look at clock forwarding using a DDR IOB DFF (basically two flip flops that clock on rising, and falling edges each cycle) driven by a BUFG.

 

With no multiply/divide, 320 in, 320 out, there is no fractional rounding going on.  Regardless, it is likely 50% even in those cases (anytime the output gets divided by 2).

 

 

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Explorer
Explorer
9,857 Views
Registered: ‎11-25-2014

Re: Duty Cycle Problem with 320 Mhz

Jump to solution

Are you generating other clocks with the MMCM as well or just the 320MHz? When you run the clocking wizard to configure the MMCM does it tell you that the actual duty cycle of the output clock is 50%? I agree with Austin that if the MMCM is configured properly then the duty cycle will be 50%.

 

Are you looking at the output clock in simulation? Or are you driving the clock to an output pin and looking at it with an oscilloscope? If the latter, what I/O standard are you using to drive the clock out, and what is the external load? 320MHz is fast and the driver could definitely corrupt the duty cycle.

0 Kudos
Visitor notanother
Visitor
9,842 Views
Registered: ‎12-01-2015

Re: Duty Cycle Problem with 320 Mhz

Jump to solution

Hi Austin,

I am measuring it at simulation.

I looked DDR DFF, but this is only the behavioral simulation.

I think there is a logical problem in MMCM with getting out a clock lower precision than 0.125 ns.

 

And I don't know what can I do?

0 Kudos
Visitor notanother
Visitor
9,840 Views
Registered: ‎12-01-2015

Re: Duty Cycle Problem with 320 Mhz

Jump to solution

Hi rjsefton,

 

I am generating my clock in testbench and I can observe that my clock has a 1.5625 ns at high and 1.5625 ns at low.

I am generating 320 MHz clock. 

As you said when I configure the MMCM .It tells me actual duty cycle is 50%. But it couldn't achieve 50%

 

I am just looking at the output clock in simulation

 

Here is a simulation screenshot.

The first one is my clock which one generated at testbench, also input clock of MMCM

The second one is output clock of MMCM 

 

clock.png
0 Kudos
Scholar austin
Scholar
9,832 Views
Registered: ‎02-27-2008

Re: Duty Cycle Problem with 320 Mhz

Jump to solution

Sounds like a simulation bug.

 

Perhaps you could post the settings for the MMCM instantiation, along with the logs?

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Explorer
Explorer
9,821 Views
Registered: ‎11-25-2014

Re: Duty Cycle Problem with 320 Mhz

Jump to solution

@notanother -

 

What time resolution do you have set in the simulator?

0 Kudos
Visitor notanother
Visitor
9,810 Views
Registered: ‎12-01-2015

Re: Duty Cycle Problem with 320 Mhz

Jump to solution

@austin @rjsefton

 

This is the settings for the MMCM

 

//----------------------------------------------------------------------------
// Output Output Phase Duty Cycle Pk-to-Pk Phase
// Clock Freq (MHz) (degrees) (%) Jitter (ps) Error (ps)
//----------------------------------------------------------------------------
// CLK_OUT1___320.000______0.000______50.0_______79.487_____79.885
//
//----------------------------------------------------------------------------
// Input Clock Freq (MHz) Input Jitter (UI)
//----------------------------------------------------------------------------
// __primary_________320.000____________0.010

`timescale 1ps/1ps

module clk_wiz_0_clk_wiz
(// Clock in ports
input clk_in1_p,
input clk_in1_n,
// Clock out ports
output clk_out1,
// Status and control signals
output locked
);

// Input buffering
//------------------------------------
IBUFGDS clkin1_ibufgds
(.O (clk_in1_clk_wiz_0),
.I (clk_in1_p),
.IB (clk_in1_n));

 

// Clocking PRIMITIVE
//------------------------------------
// Instantiation of the MMCM PRIMITIVE
// * Unused inputs are tied off
// * Unused outputs are labeled unused
wire [15:0] do_unused;
wire drdy_unused;
wire psdone_unused;
wire locked_int;
wire clkfbout_clk_wiz_0;
wire clkfbout_buf_clk_wiz_0;
wire clkfboutb_unused;
wire clkout0b_unused;
wire clkout1_unused;
wire clkout1b_unused;
wire clkout2_unused;
wire clkout2b_unused;
wire clkout3_unused;
wire clkout3b_unused;
wire clkout4_unused;
wire clkout5_unused;
wire clkout6_unused;
wire clkfbstopped_unused;
wire clkinstopped_unused;

MMCME2_ADV
#(.BANDWIDTH ("OPTIMIZED"),
.CLKOUT4_CASCADE ("FALSE"),
.COMPENSATION ("ZHOLD"),
.STARTUP_WAIT ("FALSE"),
.DIVCLK_DIVIDE (1),
.CLKFBOUT_MULT_F (3.125),
.CLKFBOUT_PHASE (0.000),
.CLKFBOUT_USE_FINE_PS ("FALSE"),
.CLKOUT0_DIVIDE_F (3.125),
.CLKOUT0_PHASE (0.000),
.CLKOUT0_DUTY_CYCLE (0.500),
.CLKOUT0_USE_FINE_PS ("FALSE"),
.CLKIN1_PERIOD (3.125),
.REF_JITTER1 (0.010))
mmcm_adv_inst
// Output clocks
(.CLKFBOUT (clkfbout_clk_wiz_0),
.CLKFBOUTB (clkfboutb_unused),
.CLKOUT0 (clk_out1_clk_wiz_0),
.CLKOUT0B (clkout0b_unused),
.CLKOUT1 (clkout1_unused),
.CLKOUT1B (clkout1b_unused),
.CLKOUT2 (clkout2_unused),
.CLKOUT2B (clkout2b_unused),
.CLKOUT3 (clkout3_unused),
.CLKOUT3B (clkout3b_unused),
.CLKOUT4 (clkout4_unused),
.CLKOUT5 (clkout5_unused),
.CLKOUT6 (clkout6_unused),
// Input clock control
.CLKFBIN (clkfbout_buf_clk_wiz_0),
.CLKIN1 (clk_in1_clk_wiz_0),
.CLKIN2 (1'b0),
// Tied to always select the primary input clock
.CLKINSEL (1'b1),
// Ports for dynamic reconfiguration
.DADDR (7'h0),
.DCLK (1'b0),
.DEN (1'b0),
.DI (16'h0),
.DO (do_unused),
.DRDY (drdy_unused),
.DWE (1'b0),
// Ports for dynamic phase shift
.PSCLK (1'b0),
.PSEN (1'b0),
.PSINCDEC (1'b0),
.PSDONE (psdone_unused),
// Other control and status signals
.LOCKED (locked_int),
.CLKINSTOPPED (clkinstopped_unused),
.CLKFBSTOPPED (clkfbstopped_unused),
.PWRDWN (1'b0),
.RST (1'b0));


assign locked = locked_int;

// Output buffering
//-----------------------------------

BUFG clkf_buf
(.O (clkfbout_buf_clk_wiz_0),
.I (clkfbout_clk_wiz_0));

 

BUFG clkout1_buf
(.O (clk_out1),
.I (clk_out1_clk_wiz_0));

 


endmodule

0 Kudos
Scholar austin
Scholar
9,800 Views
Registered: ‎02-27-2008

Re: Duty Cycle Problem with 320 Mhz

Jump to solution

The parameters do not look correct,

 

CLOCK0 is supposed to be your 320?  If so, why specify an input divide, and output divide of 3.125?  Why not use 4?  Why would it be using fractional values?  Makes no sense at all, unless to get the other two outs it must.  Provide the odd other clocks from another MMCM?

 

Seems odd that those values were suggested.

 

Simulation is telling you the truth.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Visitor notanother
Visitor
9,781 Views
Registered: ‎12-01-2015

Re: Duty Cycle Problem with 320 Mhz

Jump to solution

@austin

 

Clock out seems to 320 MHz.

.DIVCLK_DIVIDE (1), So MMCM didn't divide input clock. 

 

CLKFBOUT_MULT_F (3.125), and CLKOUT0_DIVIDE_F (3.125) 

I don't know why this settings like that 

 

I generate another MMCM at different project from 320 MHz to 320 MHz. It's settings like that 

.DIVCLK_DIVIDE (1) , CLKFBOUT_MULT_F (3.125), and CLKOUT0_DIVIDE_F (3.125) 

 

It seems odd like you said

0 Kudos
Visitor notanother
Visitor
7,833 Views
Registered: ‎12-01-2015

Re: Duty Cycle Problem with 320 Mhz

Jump to solution

I changed the MMCM's multiply and divide settings manually

I set both value to 2. 

Here is my MMCM log

 

MMCME2_ADV
#(.BANDWIDTH ("OPTIMIZED"),
.CLKOUT4_CASCADE ("FALSE"),
.COMPENSATION ("ZHOLD"),
.STARTUP_WAIT ("FALSE"),
.DIVCLK_DIVIDE (1),
.CLKFBOUT_MULT_F (2.000),
.CLKFBOUT_PHASE (0.000),
.CLKFBOUT_USE_FINE_PS ("FALSE"),
.CLKOUT0_DIVIDE_F (2.000),
.CLKOUT0_PHASE (0.000),
.CLKOUT0_DUTY_CYCLE (0.500),
.CLKOUT0_USE_FINE_PS ("TRUE"),
.CLKIN1_PERIOD (3.125),
.REF_JITTER1 (0.010))

 

So I can get 1.562.000 ps at high and 1.563.000 ps at low 

It is better than previous one. But not enough :)

 

I need 1.562.500 ps at high and 1.562.500 ps at low

And I think this difference is about time resolution.

How can I achive exact %50 duty cycle. I couldn't find time resolution settings on MMCM

0 Kudos
Scholar austin
Scholar
17,165 Views
Registered: ‎02-27-2008

Re: Duty Cycle Problem with 320 Mhz

Jump to solution

Time resolution is simulation,

 

Has nothing to do with the hardware.  Your 'problem' is solved.  Now you need to learn how to direct the simulator to use a finer simulation resolution (which will slow it down, and take longer to run, hence why the resolution gets set to a coarse value).

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos