DDR3 initialization sequence issue

[promach]

Strange, why the Warning : Please wait for PSDONE signal before adjusting the Phase Shift. come back again ?

[promach]

I managed to solve the PSDONE warning

However, ck_dynamic output is still incorrect with respect to udqs_r

Note: I try to read this Xilinx support webpage, but I still could not find what I want in order to debug the non-working dynamic phase shift.

[promach]

@NorthGuy  I tried to read about DCM_SP settings and modified the code to use CLKFX instead of CLK0, but ck_dynamic signal is still wrong.  Why ?

Code: [Select]

// file: pll_tuneable.v
//
// (c) Copyright 2008 - 2011 Xilinx, Inc. All rights reserved.
//
// This file contains confidential and proprietary information
// of Xilinx, Inc. and is protected under U.S. and
// international copyright and other intellectual property
// laws.
//
// DISCLAIMER
// This disclaimer is not a license and does not grant any
// rights to the materials distributed herewith. Except as
// otherwise provided in a valid license issued to you by
// Xilinx, and to the maximum extent permitted by applicable
// law: (1) THESE MATERIALS ARE MADE AVAILABLE "AS IS" AND
// WITH ALL FAULTS, AND XILINX HEREBY DISCLAIMS ALL WARRANTIES
// AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING
// BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, NON-
// INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and
// (2) Xilinx shall not be liable (whether in contract or tort,
// including negligence, or under any other theory of
// liability) for any loss or damage of any kind or nature
// related to, arising under or in connection with these
// materials, including for any direct, or any indirect,
// special, incidental, or consequential loss or damage
// (including loss of data, profits, goodwill, or any type of
// loss or damage suffered as a result of any action brought
// by a third party) even if such damage or loss was
// reasonably foreseeable or Xilinx had been advised of the
// possibility of the same.
//
// CRITICAL APPLICATIONS
// Xilinx products are not designed or intended to be fail-
// safe, or for use in any application requiring fail-safe
// performance, such as life-support or safety devices or
// systems, Class III medical devices, nuclear facilities,
// applications related to the deployment of airbags, or any
// other applications that could lead to death, personal
// injury, or severe property or environmental damage
// (individually and collectively, "Critical
// Applications"). Customer assumes the sole risk and
// liability of any use of Xilinx products in Critical
// Applications, subject only to applicable laws and
// regulations governing limitations on product liability.
//
// THIS COPYRIGHT NOTICE AND DISCLAIMER MUST BE RETAINED AS
// PART OF THIS FILE AT ALL TIMES.
//
//----------------------------------------------------------------------------
// User entered comments
//----------------------------------------------------------------------------
// None
//
//----------------------------------------------------------------------------
// "Output    Output      Phase     Duty      Pk-to-Pk        Phase"
// "Clock    Freq (MHz) (degrees) Cycle (%) Jitter (ps)  Error (ps)"
//----------------------------------------------------------------------------
// CLK_OUT1___333.333_____90.000______50.0______260.000____150.000
//
//----------------------------------------------------------------------------
// "Input Clock   Freq (MHz)    Input Jitter (UI)"
//----------------------------------------------------------------------------
// __primary__________50.000____________0.010

`timescale 1ps/1ps

(* CORE_GENERATION_INFO = "pll_tuneable,clk_wiz_v3_6,{component_name=pll_tuneable,use_phase_alignment=true,use_min_o_jitter=false,use_max_i_jitter=false,use_dyn_phase_shift=true,use_inclk_switchover=false,use_dyn_reconfig=false,feedback_source=FDBK_AUTO,primtype_sel=DCM_SP,num_out_clk=1,clkin1_period=3.000,clkin2_period=3.000,use_power_down=false,use_reset=true,use_locked=true,use_inclk_stopped=true,use_status=true,use_freeze=false,use_clk_valid=true,feedback_type=SINGLE,clock_mgr_type=AUTO,manual_override=true}" *)
module pll_tuneable
 (// Clock in ports
  input         clk,
  // Clock out ports
  output        ck_dynamic,
  // Dynamic phase shift ports
  input         psclk,
  input         psen,
  input         psincdec,
  output        psdone,
  // Status and control signals
  input         reset,
  output [2:0]  status,
  output        input_clk_stopped,
  output        locked_dynamic,
  output        clk_valid
 );

  // Input buffering
  //------------------------------------
  BUFG clkin1_buf
   (.O (clkin1),
    .I (clk));


  // Clocking primitive
  //------------------------------------

  // Instantiation of the DCM primitive
  //    * Unused inputs are tied off
  //    * Unused outputs are labeled unused
  wire        locked_int;
  wire [7:0]  status_int;
  wire clkfb;
  wire clk0;
  wire clkfx;

  DCM_SP
  #(.CLKDV_DIVIDE          (2.000),
    .CLKFX_DIVIDE          (2),
    .CLKFX_MULTIPLY        (2),
    .CLKIN_DIVIDE_BY_2     ("FALSE"),
    .CLKIN_PERIOD          (3.000),
    .CLKOUT_PHASE_SHIFT    ("VARIABLE"),
    .CLK_FEEDBACK          ("1X"),
    .DESKEW_ADJUST         ("SOURCE_SYNCHRONOUS"),
    .PHASE_SHIFT           (64),
    .STARTUP_WAIT          ("FALSE"))
  dcm_sp_inst
    // Input clock
   (.CLKIN                 (clkin1),
    .CLKFB                 (clkfb),
    // Output clocks
    .CLK0                  (clk0),
    .CLK90                 (),
    .CLK180                (),
    .CLK270                (),
    .CLK2X                 (),
    .CLK2X180              (),
    .CLKFX                 (clkfx),
    .CLKFX180              (),
    .CLKDV                 (),
    // Ports for dynamic phase shift
    .PSCLK                 (psclk),
    .PSEN                  (psen),
    .PSINCDEC              (psincdec),
    .PSDONE                (psdone),
    // Other control and status signals
    .LOCKED                (locked_int),
    .STATUS                (status_int),
 
    .RST                   (reset),
    // Unused pin- tie low
    .DSSEN                 (1'b0));

    assign locked_dynamic = locked_int;
    assign status = status_int[2:0];
    assign input_clk_stopped = status_int[1];
    assign clk_valid = ( ( locked_int == 1'b 1 ) && ( status_int[2:1] == 2'b 0 ) );

  // Output buffering
  //-----------------------------------
  BUFG clkf_buf
   (.O (clkfb),
    .I (clk0));

  BUFG clkout1_buf
   (.O   (ck_dynamic),
    .I   (clkfx));




endmodule


[promach]

ck_dynamic output frequency issue is solved.

I made a mistake in the CLKIN_PERIOD and M/D ratio inside the clocking wizard configuration.
I have attached the wizard-generated pll_tuneable.v file.

From the simulation waveform, it seems that ck_dynamic output is still not 90 degree phase-locked (it is now 180 degree) to incoming udqs_r.  Why ?

Code: [Select]

// file: pll_tuneable.v
//
// (c) Copyright 2008 - 2011 Xilinx, Inc. All rights reserved.
//
// This file contains confidential and proprietary information
// of Xilinx, Inc. and is protected under U.S. and
// international copyright and other intellectual property
// laws.
//
// DISCLAIMER
// This disclaimer is not a license and does not grant any
// rights to the materials distributed herewith. Except as
// otherwise provided in a valid license issued to you by
// Xilinx, and to the maximum extent permitted by applicable
// law: (1) THESE MATERIALS ARE MADE AVAILABLE "AS IS" AND
// WITH ALL FAULTS, AND XILINX HEREBY DISCLAIMS ALL WARRANTIES
// AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING
// BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, NON-
// INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and
// (2) Xilinx shall not be liable (whether in contract or tort,
// including negligence, or under any other theory of
// liability) for any loss or damage of any kind or nature
// related to, arising under or in connection with these
// materials, including for any direct, or any indirect,
// special, incidental, or consequential loss or damage
// (including loss of data, profits, goodwill, or any type of
// loss or damage suffered as a result of any action brought
// by a third party) even if such damage or loss was
// reasonably foreseeable or Xilinx had been advised of the
// possibility of the same.
//
// CRITICAL APPLICATIONS
// Xilinx products are not designed or intended to be fail-
// safe, or for use in any application requiring fail-safe
// performance, such as life-support or safety devices or
// systems, Class III medical devices, nuclear facilities,
// applications related to the deployment of airbags, or any
// other applications that could lead to death, personal
// injury, or severe property or environmental damage
// (individually and collectively, "Critical
// Applications"). Customer assumes the sole risk and
// liability of any use of Xilinx products in Critical
// Applications, subject only to applicable laws and
// regulations governing limitations on product liability.
//
// THIS COPYRIGHT NOTICE AND DISCLAIMER MUST BE RETAINED AS
// PART OF THIS FILE AT ALL TIMES.
//
//----------------------------------------------------------------------------
// User entered comments
//----------------------------------------------------------------------------
// None
//
//----------------------------------------------------------------------------
// "Output    Output      Phase     Duty      Pk-to-Pk        Phase"
// "Clock    Freq (MHz) (degrees) Cycle (%) Jitter (ps)  Error (ps)"
//----------------------------------------------------------------------------
// CLK_OUT1___350.000_____90.000______50.0______257.143____150.000
//
//----------------------------------------------------------------------------
// "Input Clock   Freq (MHz)    Input Jitter (UI)"
//----------------------------------------------------------------------------
// __primary__________50.000____________0.010

`timescale 1ps/1ps

(* CORE_GENERATION_INFO = "pll_tuneable,clk_wiz_v3_6,{component_name=pll_tuneable,use_phase_alignment=true,use_min_o_jitter=false,use_max_i_jitter=false,use_dyn_phase_shift=true,use_inclk_switchover=false,use_dyn_reconfig=false,feedback_source=FDBK_AUTO,primtype_sel=DCM_SP,num_out_clk=1,clkin1_period=20.000,clkin2_period=20.000,use_power_down=false,use_reset=true,use_locked=true,use_inclk_stopped=true,use_status=true,use_freeze=false,use_clk_valid=true,feedback_type=SINGLE,clock_mgr_type=AUTO,manual_override=true}" *)
module pll_tuneable
 (// Clock in ports
  input         clk,
  // Clock out ports
  output        ck_dynamic,
  // Dynamic phase shift ports
  input         psclk,
  input         psen,
  input         psincdec,
  output        psdone,
  // Status and control signals
  input         reset,
  output [2:0]  status,
  output        input_clk_stopped,
  output        locked_dynamic,
  output        clk_valid
 );

  // Input buffering
  //------------------------------------
  BUFG clkin1_buf
   (.O (clkin1),
    .I (clk));


  // Clocking primitive
  //------------------------------------

  // Instantiation of the DCM primitive
  //    * Unused inputs are tied off
  //    * Unused outputs are labeled unused
  wire        locked_int;
  wire [7:0]  status_int;
  wire clkfb;
  wire clk0;
  wire clkfx;

  DCM_SP
  #(.CLKDV_DIVIDE          (2.000),
    .CLKFX_DIVIDE          (2),
    .CLKFX_MULTIPLY        (14),
    .CLKIN_DIVIDE_BY_2     ("FALSE"),
    .CLKIN_PERIOD          (20.000),
    .CLKOUT_PHASE_SHIFT    ("VARIABLE"),
    .CLK_FEEDBACK          ("1X"),
    .DESKEW_ADJUST         ("SOURCE_SYNCHRONOUS"),
    .PHASE_SHIFT           (64),
    .STARTUP_WAIT          ("FALSE"))
  dcm_sp_inst
    // Input clock
   (.CLKIN                 (clkin1),
    .CLKFB                 (clkfb),
    // Output clocks
    .CLK0                  (clk0),
    .CLK90                 (),
    .CLK180                (),
    .CLK270                (),
    .CLK2X                 (),
    .CLK2X180              (),
    .CLKFX                 (clkfx),
    .CLKFX180              (),
    .CLKDV                 (),
    // Ports for dynamic phase shift
    .PSCLK                 (psclk),
    .PSEN                  (psen),
    .PSINCDEC              (psincdec),
    .PSDONE                (psdone),
    // Other control and status signals
    .LOCKED                (locked_int),
    .STATUS                (status_int),
 
    .RST                   (reset),
    // Unused pin- tie low
    .DSSEN                 (1'b0));

    assign locked_dynamic = locked_int;
    assign status = status_int[2:0];
    assign input_clk_stopped = status_int[1];
    assign clk_valid = ( ( locked_int == 1'b 1 ) && ( status_int[2:1] == 2'b 0 ) );

  // Output buffering
  //-----------------------------------
  BUFG clkf_buf
   (.O (clkfb),
    .I (clk0));

  BUFG clkout1_buf
   (.O   (ck_dynamic),
    .I   (clkfx));




endmodule

[promach]

I have just temporarily solved the 180 degree phase shift issue just above.

Now, I have STA setup timing issues to worry about.
How shall I tackle these STA issues especially violated path #1 ?

[BrianHG]

Is that you 'OE' control path for the 'DQS's output enable?

Funny, but in my design, I have the OE DQS control tied to the DDR_CK 0 degree phase, not 90.

Also, I use a SDR OE control even though the data driving the IO pins is DDR for both DQS & DQ.  At least in Altera, it does help with routing not having to deal with the extra paths and 180 degree compliment path.

Note that my data DQ 'OE' control port does operate on the DDR_CK_90 phase as that port's write data is also on the DDR_CK_90 clock.

Read up on your DDR buffer.  It also probably has a non-ddr capable OE option, just like the newer MAX10/CycloneV do have a DDR OE, or even a SDR OE which you may set to shift onto the 180 degree falling clock, yet still receive it's control on the 0 degree input clock.

[promach]

@BrianHg  Thanks for reminding me to use differential IOBUFDS primitive.

However, the STA setup timing violation issue that I am facing now needs to be solved using set_false_path or set_group_group since wait_count is only used inside "clk" domain, instead of "ck_90" domain as stated in the STA timing violation table.

Please correct me if wrong.

Someone told me to use either derive_pll_clocks OR set_max_delay of 1.25 clock periods OR set_multicycle_path instead of just a brute set_false_path command which literally says that the signal could take 1 ns, or it could take 1 ms, and the user don't care.

[BrianHG]

Someone told me to use either derive_pll_clocks OR set_max_delay of 1.25 clock periods OR set_multicycle_path instead of just a brute set_false_path command which literally says that the signal could take 1 ns, or it could take 1 ms, and the user don't care.

Never use false path unless you do not care for random errors from build to built as that path delay  may fall inside one clock, or be accepted at the next clock, or even 2 more since the compiler will not care how slow a path takes from A-B and it may just get routed any which way on the fabric.  You use false path when you dont have any wiring from those 2 clock domains or dont care at all.

Only use multicycle, for example a setting of 2, if your code has been coded to allow for a 1 clock or 2 clock data delay.  This will be random every build and worse even random between multiple controls and bits if you do it between multiple clock domains.  So, use carefully and code with the error intent if you do.

Max delay should only be used for the IO pins and not internal paths as again, each silicon fabric can perform better than what the compiler targets as worst case scenario while the IOs may have specific rigid timing wiring & transistors to achieve a stable external interfacing.  If you are the master sending the clock and all controls to the DDR3, you may actually have a pretty large delay from internal clock to the IO pins, so long as that delay is globally flat between all transmitting IOs.  This will generate havoc with regard to reading data back into the FPGA.

To solve your internal core to IOBUF timing issues, have you tried making a set or series latches/chain to give the compiler the ability to graciously cross the clock domain on it's own terms without having to do any such tricks?  In my controller, my write data path going from CK_0 internally to the IO buffer's CK_90 first goes through a 3-4 DFF chain, the entire data DQ and DM and OE busses before it reaches my DDR_IOBUFF.  Without this chain, (this means all that data is also valid and ready 3-4 clocks early) Quartus would cripple my write data path (it actually cripples my core's CK_0 FMAX, not the actual CK_90 clock) down to ~75MHz, or generate a huge negative error slacks in the NS range instead of my current >400MHz clearance.


(In my code,'BrianHG_DDR3_IO_PORT_ALTERA.sv (v0.95 build)', lines 595 to end has this pipe running on at CK_90, while lines 550-595 has the write BL8 data serializer running on my core system clock CK_0.)

[promach]

To solve your internal core to IOBUF timing issues, have you tried making a set or series latches/chain to give the compiler the ability to graciously cross the clock domain on it's own terms without having to do any such tricks?  In my controller, my write data path going from CK_0 internally to the IO buffer's CK_90 first goes through a 3-4 DFF chain, the entire data DQ and DM and OE busses before it reaches my DDR_IOBUFF.

@BrianHg  you mean the need for CDC crossing ?

However according to https://www.verilogpro.com/clock-domain-crossing-part-1/ , slow-to-fast clock domain crossing (output to DRAM) is easy, but it is difficult the other way round (input from DRAM).

Please correct me if wrong.

[BrianHG]

To solve your internal core to IOBUF timing issues, have you tried making a set or series latches/chain to give the compiler the ability to graciously cross the clock domain on it's own terms without having to do any such tricks?  In my controller, my write data path going from CK_0 internally to the IO buffer's CK_90 first goes through a 3-4 DFF chain, the entire data DQ and DM and OE busses before it reaches my DDR_IOBUFF.

@BrianHg  you mean the need for CDC crossing ?

However according to https://www.verilogpro.com/clock-domain-crossing-part-1/ , slow-to-fast clock domain crossing (output to DRAM) is easy, but it is difficult the other way round (input from DRAM).

Please correct me if wrong.

Remember, we are CDC crossing from the same frequency to the same frequency, just at different phases.  Yes this is easy for the compiler, however, depending on the direction, it will require a layer of sequential DFF in the fabric before the final IO to allow the compiler to auto-accommodate regardless of your setup.  The compiler will do this by register-retiming a number of DFF cells along as carry chain to shift the data from 1 clock to the next phase in increments.  There is a lot more to this happening internally, but this tactic for stretching to data to the final DFF in the IO buffer will work.

When reading data, since the compiler will not know the final end product functioning phase, I specify the initial read clock phase equivalent to the CK_0 phase.  With the knowledge of the potential +/- 1 clock error in the read data as I tune when crossing from the read clock domain to the original CK_0 domain, I have written my own system to do that transfer correct this +/-1 error along all the data bits and controls regardless of the timing noise in the system as each signal path inside the FPGA will have a slight timing error and tuning the read clock position will reveal errors along the edges of certain critical phase positions.  You will probably need to look up and read a ton of crap with ingenuity to engineer your own equivalent solution as mine is based on decades of experiance.

[BrianHG]

By the way, your verilog CDC paper does give you a solid clue to how my read data CDC works, but I do not use an acknowledge response and you need 1 more piece to safely cover very wide buses like what happening with a 16bit or 128bit DDR3 data channel.

Again, some items are not needed as in the DDR3, you are crossing form 1 clock domain to the next where both have the same frequency, but are at an unknown phase relationship between one-another.

[promach]

Remember, we are CDC crossing from the same frequency to the same frequency, just at different phases.

@BrianHg 

Not really the same frequency at all. 

wait_count is used only inside "clk" domain which is only 50MHz , but udqs_iobuf_en is used inside "ck_90" domain which is of 350MHz

Note: I am also attaching the timing report (test_ddr3_memory_controller.twr) starting from line 1022

[BrianHG]

Are you saying clk_IBUFG_BUFG is a 50MHz clock, and obviously the ck_90 is your DDR3 350MHz clk?

Why is your DDR3_control/*** running at only 50MHz and not at the system 350MHz?

Having multiple clock domain frequencies driving a high speed IO is a big fat no-no for clean high speed FMAX.

If it must be done, any controls running on that input clock domain must fist be latched to the 350MHz domain, then use that bundle to drive the IOs.

[promach]

Are you saying clk_IBUFG_BUFG is a 50MHz clock, and obviously the ck_90 is your DDR3 350MHz clk?

Yes.

Why is your DDR3_control/*** running at only 50MHz and not at the system 350MHz?

Because there is too much of combinational logic happening inside the finite state machine within "clk" domain

[BrianHG]

Are you saying clk_IBUFG_BUFG is a 50MHz clock, and obviously the ck_90 is your DDR3 350MHz clk?

Yes.

Why is your DDR3_control/*** running at only 50MHz and not at the system 350MHz?

Because there is too much of combinational logic happening inside the finite state machine within "clk" domain

Then, how do you get commands and data out at high enough speed for the ram?

Hint: inside 'BrianHG_DDR3_PHY_SEQ.sv' (v0.95) read lines 500 to 512.  (DDR_CLK_50 is the DDR_CK  speed / 2 at 0 degrees, not 50 degrees, not 50MHz.  Not shown, CLK_IN is equivalent to your 50MHz input.)

[promach]

Then, how do you get commands and data out at high enough speed for the ram?

All manufacturer timings have been converted to the slow 50MHz "clk" domain.  Do not worry, I have verified this concern inside Modelsim micron model simulation and Xilinx ISIM simulator.

[BrianHG]

Ok, we are talking about something different on top of a different coding philosophy.  I guess you will have to solve this one on your own as my code, except for that power-up sequencer bridge from my 50MHz domain to the DDR_CK/2 domain switch at power-up, completely runs in the DDR_CK & DDR_CK/2 clock domain.

What I can tell you:
1)     Note that running additional clock domains directly off of the same PLL generating the DDR_CK clock, except that you have additional perfect divide by 2 and perfect divide by 4 clock outs will not generate those massive negative slack NS you are getting.

2)     The simulators like Modelsim will always simulate perfect.  ( I could have been finished in a week...)  When you get to silicon and authentic timing reports from the compiler, including after multiple builds with shared logic controlling your ram controller, this will not be the case.  Prepare for a debug and slight code alteration fest even if it appears to meet timing constraints.

[promach]

Note that running additional clock domains directly off of the same PLL generating the DDR_CK clock, except that you have additional perfect divide by 2 and perfect divide by 4 clock outs will not generate those massive negative slack NS you are getting.

Why did you mention about "additional perfect divide by 2 and perfect divide by 4" ?

[BrianHG]

Say for example you already have 3 PLL output, CK_0, CK_90 and a CK_READ being the tuneable one, I'm saying also add a CK_0_div2 and CK_0_div4, and maybe even CK_0_div8 outputs on that same PLL.  The compiler will only give you the routing timing benefits I mentioned if you place all your control logic on those CK_0/_div2/_div4/_div8 clocks.  Those timing benefits will all be destroyed if any control signals come from your 50MHz CLK_IN or from any other PLL even if it has been set to the same frequency or it was locked to your first PLL.

You should not need to worry about cross clock domain conversion with logic on these clocks communicating across their domains and you will not need to add any .sdc entries to get said performance gains.  Only at the edge of squeezing out the FPGA fabric's top last FMAX is when if your core logic is running on the _div4 clock sending control to the master CK_0 clock domain, you might want to pass a latch in the middle from _div4 to _div2, then the _div2 latched data onto the CK_0, however, this would only be required under extreme optimization circumstance which you should not need.

Operating between these CK_0/_div2/_div4/_div8 clock domains, you can trust that Modelsim's sim will match actual silicon.


Also, Modelsim ignores, doesn't use any .sdc timing information.

[promach]

Operating between these CK_0/_div2/_div4/_div8 clock domains, you can trust that Modelsim's sim will match actual silicon.

Are you suggesting to use PLL output even for slow 50MHz "clk" domain instead of feeding directly from external 50MHz clock crystal ?

If yes, CDC crossing is still needed since the clocks are not in the same frequency although they are from the same PLL.

Besides, I suppose Modelsim could not simulate vendor's PLL IP ?

Please advise.

[BrianHG]

Operating between these CK_0/_div2/_div4/_div8 clock domains, you can trust that Modelsim's sim will match actual silicon.

Are you suggesting to use PLL output even for slow 50MHz "clk" domain instead of feeding directly from external 50MHz clock crystal ?

If yes, CDC crossing is still needed since the clocks are not in the same frequency although they are from the same PLL.

Besides, I suppose Modelsim could not simulate vendor's PLL IP ?

Please advise.

#1, this can help, but will still be nowhere nearly as effective as using a /2, /4, and /8 from the DDR_CK frequency and it will not be effective at all if your DDR_CK output clock is a weird fraction with regard to the 50 MHz input.

#2, Yes, Xilinx should have their PLL function included in their Modelsim library, or be able to generate a library function of their PLL.  You still may use Xilinx's simulator anyways.

[promach]

#1 I am quite confused with your reply : "will still be nowhere nearly as effective as using a /2, /4, and /8 from the DDR_CK frequency". 

Note: My slow 50MHz "clk" domain would be a /7 from the 350MHz DDR_CK frequency.

#2 Wait, which of the following files to be copied to the Modelsim simulation directory ?

Code: [Select]

[phung@archlinux ipcore_dir]$ ls -al *pll*
-rw-r--r-- 1 phung users 1215 Jun  8 22:35 create_pll.tcl
-rw-r--r-- 1 phung users 1218 Jul 19 16:55 create_pll_ck.tcl
-rw-r--r-- 1 phung users 1222 Jul 19 17:21 create_pll_ck_180.tcl
-rw-r--r-- 1 phung users 1222 Jul 19 17:23 create_pll_ck_270.tcl
-rw-r--r-- 1 phung users 1221 Jul 19 17:18 create_pll_ck_90.tcl
-rw-r--r-- 1 phung users 1219 Jul 19 09:15 create_pll_ram.tcl
-rw-r--r-- 1 phung users 1224 Jul 30 21:27 create_pll_tuneable.tcl
-rw-r--r-- 1 phung users 1082 Aug 15 11:01 edit_pll.tcl
-rw-r--r-- 1 phung users 1085 Jul 21 20:36 edit_pll_ck.tcl
-rw-r--r-- 1 phung users 1089 Jul 19 17:29 edit_pll_ck_180.tcl
-rw-r--r-- 1 phung users 1089 Jul 19 17:29 edit_pll_ck_270.tcl
-rw-r--r-- 1 phung users 1088 Jul 19 17:29 edit_pll_ck_90.tcl
-rw-r--r-- 1 phung users 1091 Aug 15 11:10 edit_pll_tuneable.tcl
-rw-r--r-- 1 phung users  721 Aug 15 11:01 pll.asy
-rw-r--r-- 1 phung users 2489 Aug 17 12:50 pll.gise
-rw-r--r-- 1 phung users 2547 Aug 16 01:28 pll.ncf
-rw-r--r-- 1 phung users 1944 Aug 15 11:02 pll.sym
-rwxrwxrwx 1 phung users 2546 Aug 15 11:01 pll.ucf
-rwxrwxrwx 1 phung users 6169 Aug 15 11:01 pll.v
-rwxrwxrwx 1 phung users 3890 Aug 15 11:01 pll.veo
-rw-r--r-- 1 phung users 7959 Aug 15 11:01 pll.xco
-rwxrwxrwx 1 phung users 2981 Aug 15 11:01 pll.xdc
-rw-r--r-- 1 phung users 4867 Aug 15 15:00 pll.xise
-rw-r--r-- 1 phung users  789 Jul 19 16:59 pll_ck.asy
-rw-r--r-- 1 phung users 1258 Aug 17 12:50 pll_ck.gise
-rw-r--r-- 1 phung users 2548 Aug 16 01:28 pll_ck.ncf
-rw-r--r-- 1 phung users 2092 Jul 19 16:59 pll_ck.sym
-rwxrwxrwx 1 phung users 2547 Jul 19 16:59 pll_ck.ucf
-rwxrwxrwx 1 phung users 5679 Jul 19 16:59 pll_ck.v
-rwxrwxrwx 1 phung users 3720 Jul 19 16:59 pll_ck.veo
-rw-r--r-- 1 phung users 7927 Jul 19 16:59 pll_ck.xco
-rwxrwxrwx 1 phung users 2982 Jul 19 16:59 pll_ck.xdc
-rw-r--r-- 1 phung users 4891 Jul 20 00:28 pll_ck.xise
-rw-r--r-- 1 phung users  793 Jul 19 17:22 pll_ck_180.asy
-rw-r--r-- 1 phung users 1270 Aug 17 12:50 pll_ck_180.gise
-rw-r--r-- 1 phung users 2552 Aug 16 01:28 pll_ck_180.ncf
-rw-r--r-- 1 phung users 2100 Jul 19 17:22 pll_ck_180.sym
-rwxrwxrwx 1 phung users 2551 Jul 19 17:22 pll_ck_180.ucf
-rwxrwxrwx 1 phung users 5712 Jul 19 17:22 pll_ck_180.v
-rwxrwxrwx 1 phung users 3732 Jul 19 17:22 pll_ck_180.veo
-rw-r--r-- 1 phung users 7939 Jul 19 17:22 pll_ck_180.xco
-rwxrwxrwx 1 phung users 2986 Jul 19 17:22 pll_ck_180.xdc
-rw-r--r-- 1 phung users 4923 Jul 20 00:28 pll_ck_180.xise
-rw-r--r-- 1 phung users 2028 Jul 19 17:22 pll_ck_180_flist.txt
-rwxrwxrwx 1 phung users 5827 Jul 19 17:22 pll_ck_180_xmdf.tcl
-rw-r--r-- 1 phung users  793 Jul 19 17:25 pll_ck_270.asy
-rw-r--r-- 1 phung users 1270 Aug 17 12:50 pll_ck_270.gise
-rw-r--r-- 1 phung users 2552 Aug 16 01:28 pll_ck_270.ncf
-rw-r--r-- 1 phung users 2100 Jul 19 17:25 pll_ck_270.sym
-rwxrwxrwx 1 phung users 2551 Jul 19 17:25 pll_ck_270.ucf
-rwxrwxrwx 1 phung users 5705 Jul 19 17:25 pll_ck_270.v
-rwxrwxrwx 1 phung users 3732 Jul 19 17:25 pll_ck_270.veo
-rw-r--r-- 1 phung users 7938 Jul 19 17:25 pll_ck_270.xco
-rwxrwxrwx 1 phung users 2986 Jul 19 17:25 pll_ck_270.xdc
-rw-r--r-- 1 phung users 4923 Jul 20 00:28 pll_ck_270.xise
-rw-r--r-- 1 phung users 2028 Jul 19 17:25 pll_ck_270_flist.txt
-rwxrwxrwx 1 phung users 5827 Jul 19 17:25 pll_ck_270_xmdf.tcl
-rw-r--r-- 1 phung users  792 Jul 19 17:20 pll_ck_90.asy
-rw-r--r-- 1 phung users 1267 Aug 17 12:50 pll_ck_90.gise
-rw-r--r-- 1 phung users 2551 Aug 16 01:28 pll_ck_90.ncf
-rw-r--r-- 1 phung users 2098 Jul 19 17:20 pll_ck_90.sym
-rwxrwxrwx 1 phung users 2550 Jul 19 17:20 pll_ck_90.ucf
-rwxrwxrwx 1 phung users 5698 Jul 19 17:20 pll_ck_90.v
-rwxrwxrwx 1 phung users 3729 Jul 19 17:20 pll_ck_90.veo
-rw-r--r-- 1 phung users 7934 Jul 19 17:20 pll_ck_90.xco
-rwxrwxrwx 1 phung users 2985 Jul 19 17:20 pll_ck_90.xdc
-rw-r--r-- 1 phung users 4915 Jul 20 00:28 pll_ck_90.xise
-rw-r--r-- 1 phung users 1969 Jul 19 17:20 pll_ck_90_flist.txt
-rwxrwxrwx 1 phung users 5795 Jul 19 17:20 pll_ck_90_xmdf.tcl
-rw-r--r-- 1 phung users 1792 Jul 19 16:59 pll_ck_flist.txt
-rwxrwxrwx 1 phung users 5699 Jul 19 16:59 pll_ck_xmdf.tcl
-rw-r--r-- 1 phung users 1615 Aug 15 11:02 pll_flist.txt
-rw-r--r-- 1 phung users 1094 Aug 15 11:11 pll_tuneable.asy
-rw-r--r-- 1 phung users 1276 Aug 17 12:50 pll_tuneable.gise
-rw-r--r-- 1 phung users 2556 Aug 16 01:28 pll_tuneable.ncf
-rw-r--r-- 1 phung users 2880 Aug 15 11:11 pll_tuneable.sym
-rwxrwxrwx 1 phung users 2555 Aug 15 11:11 pll_tuneable.ucf
-rwxrwxrwx 1 phung users 6017 Aug 15 11:11 pll_tuneable.v
-rwxrwxrwx 1 phung users 3885 Aug 15 11:11 pll_tuneable.veo
-rw-r--r-- 1 phung users 7949 Aug 15 11:11 pll_tuneable.xco
-rwxrwxrwx 1 phung users 2990 Aug 15 11:11 pll_tuneable.xdc
-rw-r--r-- 1 phung users 4939 Aug 15 11:40 pll_tuneable.xise
-rw-r--r-- 1 phung users 2146 Aug 15 11:11 pll_tuneable_flist.txt
-rwxrwxrwx 1 phung users 5891 Aug 15 11:11 pll_tuneable_xmdf.tcl
-rwxrwxrwx 1 phung users 5603 Aug 15 11:01 pll_xmdf.tcl

pll:
total 40
drwxr-xr-x  6 phung users  4096 Aug 15 11:02 .
drwxr-xr-x 10 phung users 12288 Aug 16 01:28 ..
-rw-rw-rw-  1 phung users  6131 Mar 14 23:41 clk_wiz_v3_6_readme.txt
drwxr-xr-x  2 phung users  4096 Aug 15 11:02 doc
drwxr-xr-x  2 phung users  4096 Aug 15 11:02 example_design
drwxr-xr-x  2 phung users  4096 Aug 15 11:02 implement
drwxr-xr-x  4 phung users  4096 Aug 15 11:02 simulation

pll_ck:
total 40
drwxr-xr-x  6 phung users  4096 Jul 19 16:59 .
drwxr-xr-x 10 phung users 12288 Aug 16 01:28 ..
-rw-rw-rw-  1 phung users  6131 Mar 14 23:41 clk_wiz_v3_6_readme.txt
drwxr-xr-x  2 phung users  4096 Jul 19 16:59 doc
drwxr-xr-x  2 phung users  4096 Jul 19 16:59 example_design
drwxr-xr-x  2 phung users  4096 Jul 19 16:59 implement
drwxr-xr-x  4 phung users  4096 Jul 19 16:59 simulation

pll_ck_180:
total 40
drwxr-xr-x  6 phung users  4096 Jul 19 17:22 .
drwxr-xr-x 10 phung users 12288 Aug 16 01:28 ..
-rw-rw-rw-  1 phung users  6131 Mar 14 23:41 clk_wiz_v3_6_readme.txt
drwxr-xr-x  2 phung users  4096 Jul 19 17:22 doc
drwxr-xr-x  2 phung users  4096 Jul 19 17:22 example_design
drwxr-xr-x  2 phung users  4096 Jul 19 17:22 implement
drwxr-xr-x  4 phung users  4096 Jul 19 17:22 simulation

pll_ck_270:
total 40
drwxr-xr-x  6 phung users  4096 Jul 19 17:25 .
drwxr-xr-x 10 phung users 12288 Aug 16 01:28 ..
-rw-rw-rw-  1 phung users  6131 Mar 14 23:41 clk_wiz_v3_6_readme.txt
drwxr-xr-x  2 phung users  4096 Jul 19 17:25 doc
drwxr-xr-x  2 phung users  4096 Jul 19 17:25 example_design
drwxr-xr-x  2 phung users  4096 Jul 19 17:25 implement
drwxr-xr-x  4 phung users  4096 Jul 19 17:25 simulation

pll_ck_90:
total 40
drwxr-xr-x  6 phung users  4096 Jul 19 17:20 .
drwxr-xr-x 10 phung users 12288 Aug 16 01:28 ..
-rw-rw-rw-  1 phung users  6131 Mar 14 23:41 clk_wiz_v3_6_readme.txt
drwxr-xr-x  2 phung users  4096 Jul 19 17:20 doc
drwxr-xr-x  2 phung users  4096 Jul 19 17:20 example_design
drwxr-xr-x  2 phung users  4096 Jul 19 17:20 implement
drwxr-xr-x  4 phung users  4096 Jul 19 17:20 simulation

pll_tuneable:
total 40
drwxr-xr-x  6 phung users  4096 Aug 15 11:11 .
drwxr-xr-x 10 phung users 12288 Aug 16 01:28 ..
-rw-rw-rw-  1 phung users  6131 Mar 14 23:41 clk_wiz_v3_6_readme.txt
drwxr-xr-x  2 phung users  4096 Aug 15 11:11 doc
drwxr-xr-x  2 phung users  4096 Aug 15 11:11 example_design
drwxr-xr-x  2 phung users  4096 Aug 15 11:11 implement
drwxr-xr-x  4 phung users  4096 Aug 15 11:11 simulation
[phung@archlinux ipcore_dir]$

[BrianHG]

#1 I am quite confused with your reply : "will still be nowhere nearly as effective as using a /2, /4, and /8 from the DDR_CK frequency". 

Note: My slow 50MHz "clk" domain would be a /7 from the 350MHz DDR_CK frequency.

#2 Wait, which of the following files to be copied to the Modelsim simulation directory ?

Code: [Select]

[phung@archlinux ipcore_dir]$ ls -al *pll*
-rw-r--r-- 1 phung users 1215 Jun  8 22:35 create_pll.tcl
-rw-r--r-- 1 phung users 1218 Jul 19 16:55 create_pll_ck.tcl
-rw-r--r-- 1 phung users 1222 Jul 19 17:21 create_pll_ck_180.tcl
-rw-r--r-- 1 phung users 1222 Jul 19 17:23 create_pll_ck_270.tcl
-rw-r--r-- 1 phung users 1221 Jul 19 17:18 create_pll_ck_90.tcl
-rw-r--r-- 1 phung users 1219 Jul 19 09:15 create_pll_ram.tcl
-rw-r--r-- 1 phung users 1224 Jul 30 21:27 create_pll_tuneable.tcl
-rw-r--r-- 1 phung users 1082 Aug 15 11:01 edit_pll.tcl
-rw-r--r-- 1 phung users 1085 Jul 21 20:36 edit_pll_ck.tcl
-rw-r--r-- 1 phung users 1089 Jul 19 17:29 edit_pll_ck_180.tcl
-rw-r--r-- 1 phung users 1089 Jul 19 17:29 edit_pll_ck_270.tcl
-rw-r--r-- 1 phung users 1088 Jul 19 17:29 edit_pll_ck_90.tcl
-rw-r--r-- 1 phung users 1091 Aug 15 11:10 edit_pll_tuneable.tcl
-rw-r--r-- 1 phung users  721 Aug 15 11:01 pll.asy
-rw-r--r-- 1 phung users 2489 Aug 17 12:50 pll.gise
-rw-r--r-- 1 phung users 2547 Aug 16 01:28 pll.ncf
-rw-r--r-- 1 phung users 1944 Aug 15 11:02 pll.sym
-rwxrwxrwx 1 phung users 2546 Aug 15 11:01 pll.ucf
-rwxrwxrwx 1 phung users 6169 Aug 15 11:01 pll.v
-rwxrwxrwx 1 phung users 3890 Aug 15 11:01 pll.veo
-rw-r--r-- 1 phung users 7959 Aug 15 11:01 pll.xco
-rwxrwxrwx 1 phung users 2981 Aug 15 11:01 pll.xdc
-rw-r--r-- 1 phung users 4867 Aug 15 15:00 pll.xise
-rw-r--r-- 1 phung users  789 Jul 19 16:59 pll_ck.asy
-rw-r--r-- 1 phung users 1258 Aug 17 12:50 pll_ck.gise
-rw-r--r-- 1 phung users 2548 Aug 16 01:28 pll_ck.ncf
-rw-r--r-- 1 phung users 2092 Jul 19 16:59 pll_ck.sym
-rwxrwxrwx 1 phung users 2547 Jul 19 16:59 pll_ck.ucf
-rwxrwxrwx 1 phung users 5679 Jul 19 16:59 pll_ck.v
-rwxrwxrwx 1 phung users 3720 Jul 19 16:59 pll_ck.veo
-rw-r--r-- 1 phung users 7927 Jul 19 16:59 pll_ck.xco
-rwxrwxrwx 1 phung users 2982 Jul 19 16:59 pll_ck.xdc
-rw-r--r-- 1 phung users 4891 Jul 20 00:28 pll_ck.xise
-rw-r--r-- 1 phung users  793 Jul 19 17:22 pll_ck_180.asy
-rw-r--r-- 1 phung users 1270 Aug 17 12:50 pll_ck_180.gise
-rw-r--r-- 1 phung users 2552 Aug 16 01:28 pll_ck_180.ncf
-rw-r--r-- 1 phung users 2100 Jul 19 17:22 pll_ck_180.sym
-rwxrwxrwx 1 phung users 2551 Jul 19 17:22 pll_ck_180.ucf
-rwxrwxrwx 1 phung users 5712 Jul 19 17:22 pll_ck_180.v
-rwxrwxrwx 1 phung users 3732 Jul 19 17:22 pll_ck_180.veo
-rw-r--r-- 1 phung users 7939 Jul 19 17:22 pll_ck_180.xco
-rwxrwxrwx 1 phung users 2986 Jul 19 17:22 pll_ck_180.xdc
-rw-r--r-- 1 phung users 4923 Jul 20 00:28 pll_ck_180.xise
-rw-r--r-- 1 phung users 2028 Jul 19 17:22 pll_ck_180_flist.txt
-rwxrwxrwx 1 phung users 5827 Jul 19 17:22 pll_ck_180_xmdf.tcl
-rw-r--r-- 1 phung users  793 Jul 19 17:25 pll_ck_270.asy
-rw-r--r-- 1 phung users 1270 Aug 17 12:50 pll_ck_270.gise
-rw-r--r-- 1 phung users 2552 Aug 16 01:28 pll_ck_270.ncf
-rw-r--r-- 1 phung users 2100 Jul 19 17:25 pll_ck_270.sym
-rwxrwxrwx 1 phung users 2551 Jul 19 17:25 pll_ck_270.ucf
-rwxrwxrwx 1 phung users 5705 Jul 19 17:25 pll_ck_270.v
-rwxrwxrwx 1 phung users 3732 Jul 19 17:25 pll_ck_270.veo
-rw-r--r-- 1 phung users 7938 Jul 19 17:25 pll_ck_270.xco
-rwxrwxrwx 1 phung users 2986 Jul 19 17:25 pll_ck_270.xdc
-rw-r--r-- 1 phung users 4923 Jul 20 00:28 pll_ck_270.xise
-rw-r--r-- 1 phung users 2028 Jul 19 17:25 pll_ck_270_flist.txt
-rwxrwxrwx 1 phung users 5827 Jul 19 17:25 pll_ck_270_xmdf.tcl
-rw-r--r-- 1 phung users  792 Jul 19 17:20 pll_ck_90.asy
-rw-r--r-- 1 phung users 1267 Aug 17 12:50 pll_ck_90.gise
-rw-r--r-- 1 phung users 2551 Aug 16 01:28 pll_ck_90.ncf
-rw-r--r-- 1 phung users 2098 Jul 19 17:20 pll_ck_90.sym
-rwxrwxrwx 1 phung users 2550 Jul 19 17:20 pll_ck_90.ucf
-rwxrwxrwx 1 phung users 5698 Jul 19 17:20 pll_ck_90.v
-rwxrwxrwx 1 phung users 3729 Jul 19 17:20 pll_ck_90.veo
-rw-r--r-- 1 phung users 7934 Jul 19 17:20 pll_ck_90.xco
-rwxrwxrwx 1 phung users 2985 Jul 19 17:20 pll_ck_90.xdc
-rw-r--r-- 1 phung users 4915 Jul 20 00:28 pll_ck_90.xise
-rw-r--r-- 1 phung users 1969 Jul 19 17:20 pll_ck_90_flist.txt
-rwxrwxrwx 1 phung users 5795 Jul 19 17:20 pll_ck_90_xmdf.tcl
-rw-r--r-- 1 phung users 1792 Jul 19 16:59 pll_ck_flist.txt
-rwxrwxrwx 1 phung users 5699 Jul 19 16:59 pll_ck_xmdf.tcl
-rw-r--r-- 1 phung users 1615 Aug 15 11:02 pll_flist.txt
-rw-r--r-- 1 phung users 1094 Aug 15 11:11 pll_tuneable.asy
-rw-r--r-- 1 phung users 1276 Aug 17 12:50 pll_tuneable.gise
-rw-r--r-- 1 phung users 2556 Aug 16 01:28 pll_tuneable.ncf
-rw-r--r-- 1 phung users 2880 Aug 15 11:11 pll_tuneable.sym
-rwxrwxrwx 1 phung users 2555 Aug 15 11:11 pll_tuneable.ucf
-rwxrwxrwx 1 phung users 6017 Aug 15 11:11 pll_tuneable.v
-rwxrwxrwx 1 phung users 3885 Aug 15 11:11 pll_tuneable.veo
-rw-r--r-- 1 phung users 7949 Aug 15 11:11 pll_tuneable.xco
-rwxrwxrwx 1 phung users 2990 Aug 15 11:11 pll_tuneable.xdc
-rw-r--r-- 1 phung users 4939 Aug 15 11:40 pll_tuneable.xise
-rw-r--r-- 1 phung users 2146 Aug 15 11:11 pll_tuneable_flist.txt
-rwxrwxrwx 1 phung users 5891 Aug 15 11:11 pll_tuneable_xmdf.tcl
-rwxrwxrwx 1 phung users 5603 Aug 15 11:01 pll_xmdf.tcl

pll:
total 40
drwxr-xr-x  6 phung users  4096 Aug 15 11:02 .
drwxr-xr-x 10 phung users 12288 Aug 16 01:28 ..
-rw-rw-rw-  1 phung users  6131 Mar 14 23:41 clk_wiz_v3_6_readme.txt
drwxr-xr-x  2 phung users  4096 Aug 15 11:02 doc
drwxr-xr-x  2 phung users  4096 Aug 15 11:02 example_design
drwxr-xr-x  2 phung users  4096 Aug 15 11:02 implement
drwxr-xr-x  4 phung users  4096 Aug 15 11:02 simulation

pll_ck:
total 40
drwxr-xr-x  6 phung users  4096 Jul 19 16:59 .
drwxr-xr-x 10 phung users 12288 Aug 16 01:28 ..
-rw-rw-rw-  1 phung users  6131 Mar 14 23:41 clk_wiz_v3_6_readme.txt
drwxr-xr-x  2 phung users  4096 Jul 19 16:59 doc
drwxr-xr-x  2 phung users  4096 Jul 19 16:59 example_design
drwxr-xr-x  2 phung users  4096 Jul 19 16:59 implement
drwxr-xr-x  4 phung users  4096 Jul 19 16:59 simulation

pll_ck_180:
total 40
drwxr-xr-x  6 phung users  4096 Jul 19 17:22 .
drwxr-xr-x 10 phung users 12288 Aug 16 01:28 ..
-rw-rw-rw-  1 phung users  6131 Mar 14 23:41 clk_wiz_v3_6_readme.txt
drwxr-xr-x  2 phung users  4096 Jul 19 17:22 doc
drwxr-xr-x  2 phung users  4096 Jul 19 17:22 example_design
drwxr-xr-x  2 phung users  4096 Jul 19 17:22 implement
drwxr-xr-x  4 phung users  4096 Jul 19 17:22 simulation

pll_ck_270:
total 40
drwxr-xr-x  6 phung users  4096 Jul 19 17:25 .
drwxr-xr-x 10 phung users 12288 Aug 16 01:28 ..
-rw-rw-rw-  1 phung users  6131 Mar 14 23:41 clk_wiz_v3_6_readme.txt
drwxr-xr-x  2 phung users  4096 Jul 19 17:25 doc
drwxr-xr-x  2 phung users  4096 Jul 19 17:25 example_design
drwxr-xr-x  2 phung users  4096 Jul 19 17:25 implement
drwxr-xr-x  4 phung users  4096 Jul 19 17:25 simulation

pll_ck_90:
total 40
drwxr-xr-x  6 phung users  4096 Jul 19 17:20 .
drwxr-xr-x 10 phung users 12288 Aug 16 01:28 ..
-rw-rw-rw-  1 phung users  6131 Mar 14 23:41 clk_wiz_v3_6_readme.txt
drwxr-xr-x  2 phung users  4096 Jul 19 17:20 doc
drwxr-xr-x  2 phung users  4096 Jul 19 17:20 example_design
drwxr-xr-x  2 phung users  4096 Jul 19 17:20 implement
drwxr-xr-x  4 phung users  4096 Jul 19 17:20 simulation

pll_tuneable:
total 40
drwxr-xr-x  6 phung users  4096 Aug 15 11:11 .
drwxr-xr-x 10 phung users 12288 Aug 16 01:28 ..
-rw-rw-rw-  1 phung users  6131 Mar 14 23:41 clk_wiz_v3_6_readme.txt
drwxr-xr-x  2 phung users  4096 Aug 15 11:11 doc
drwxr-xr-x  2 phung users  4096 Aug 15 11:11 example_design
drwxr-xr-x  2 phung users  4096 Aug 15 11:11 implement
drwxr-xr-x  4 phung users  4096 Aug 15 11:11 simulation
[phung@archlinux ipcore_dir]$

#2, I dont use Xilinx, so I dont know.  However, it's not just a file to copy, I believe you need to 'generate' the lib file in ISE.

#1,  When crossing the clock domain boundary, the compiler does internally synthesize an equivalent multicycle command for each direction for both setup and hold.  The multicycle settings deals with fixed integers and going from DDR_CK to /2 or /4 would be a multicycle of 2 or 4 in one direction and the default 1 in the other while the hold is a bit more tricky and I'm not sure about it.  Just begin to play around and see what happens.

[promach]

When crossing the clock domain boundary, the compiler does internally synthesize an equivalent multicycle command for each direction for both setup and hold. 

If there is an equivalent multicycle command used internally inside the tool, why would there still be setup timing violation shown earlier ?

[BrianHG]

When crossing the clock domain boundary, the compiler does internally synthesize an equivalent multicycle command for each direction for both setup and hold. 

If there is an equivalent multicycle command used internally inside the tool, why would there still be setup timing violation shown earlier ?

It is a compiler intelligence issue, not that the compiler actually generated the multicycle commands.
It would be akin to when you generate a huge array in verilog, some compilers are smart enough to auto infer a generation of using ram blocks instead of logic cells for you.
Multiple evenly divided clock domain sourced from a single PLL multiple outputs allows the compiler to infer the allowable multicycle range from clk# to clk#.  While going from a clk input to any of the pll outputs incur unknowns/uncertainties which cannot be accounted for, so the compiler must treat the entire system with the worst possible conditions, or what you tell it in the .sdc file.