MIG v4.2 MPR read calibration fails on XC7K325T

[eugeth20]

Good morning,

I am experiencing some issues on the MIG v4.2 for DDR3 memories, implementing on a XC7K325T. I am working on Vivado 2019.2, and the following situation arises:

- phaser_in phase lock calibration done:

- phaser_in dqsfound calibration done;

- write leveling calibration done;

- MPR read leveling calibration error.

By following the UG586 DDR3 debug sections, the following results have been recollected:

- cal1_state_r = 0x1C = CAL_RDLVL_ERR

- cal1_cnt_cpt_r = 8

- dbg_cpt_first_edge_cnt_by_dqs = 0x08

- dbg_cpt_first_edge_cnt = 0x18920528F20

- dbg_cpt_second_edge_cnt_by_dqs = 0x23

- dbg_cpt_second_edge_cnt = 0x867BA7A6B9A3

- dbg_cpt_tap_cnt_by_dqs = 0x16

- dbg_cpt_tap_cnt = 0x5186D669D5D6

- dbg_dq_idelay_tap_cnt_by_dqs = 0x15

- dbg_dq_idelay_tap_cnt = 0x1FAD694AD275

As reported at page 251 in UG586, "if a DQS byte group failed this stage of calibration, cal1_cnt_cpt_r would equal the byte number that is failing as no further progress or increment on cal1_cnt_cpt_r occurred". In this case, this value equals 8. Nevertheless, only bytes 0-7 are present in the counters. How does the value 8 for the bytes group arises?

As also reported at page 251 in UG586, "check if the failing DQS byte has an dq_idelay_tap_cnt value of 31. This means the algorithm ran out of taps searching for the capture edges". The recorded value for this register is (as stated above): dbg_dq_idelay_tap_cnt = 0x1FAD694AD275. As 6 bits are reserved for each byte groups, this means the following values:

B0 = 0x35, B1 = 0x09, B2=0x2D, B3=0x12, B4=0x29, B5=0x35, B6=0x34, B7= 0x07. Remaining values are 0. How should I interpret this result?

Thanks in advance, best regards.

[kren]

Is it a new designed board? Please try with IP example design on board firstly and reger to general checks in UG586.

[eugeth20]

kren,

thanks for replying, and sorry for the delay: general checks on the board were ongoing.

Currently, the board is feeding the memory components with frequency of ddr3_clk=533Mhz (1066Mbps) instead of 800Mhz (1600Mbps), with reduced data width of 16 instead of the full DQ size of 72 bits.

The read leveling stage 1 is completed, nevertheless the following step of the calibration stage is stuck, with the results as follows in the attached picture.

Do you have any suggestions for the reason why the dbg_ocal_center_calib_start never rises?

Thanks in advance.

[kren]

Did you set up data rate as 533MHz and data width as 16 when you tested on your board now?

You got dbg_ocal_center_calib_start=0 because the previous calibration stage got stuck.

[eugeth20]

kren,

thanks for answering. Yes, we setup the MIG to work with a ddr3_ck at frequency of 533MHz and data width of 16 bits.

As per the previous calibration stage getting stuck, referring to UG586, v4.2, there is no specific recommendations for stuck situations, nor for understanding how to proceed. Would you please provide some other information or suggestions?

Thanks in advance, best regards.

[kren]

Is it a new designed board? Did you try with  the IP example design on the same board?

[eugeth20]

kren,

thanks for answering. I can confirm you this is a new designed board on which we are currently running the MIG example design.

As I was reading this old thread (https://forums.xilinx.com/t5/Memory-Interfaces-and-NoC/Vivado-2014-4-DDR3-MIG-7-Series-v2-3-OCLKDELAYED-Calibration/m-p/556801), I was concerned that state machine is not inserted on the chipscope probes anymore.

Supposing the issue raised in the thread was solved (opened for Vivado 2014.4, about 5 years ago), how can I proceed to understand the stuck situation as no signals are present?

Best regards.

[eugeth20]

kren,

a quick update: the timing analysis reveals a failed timing closure on the example design. Constraints are included in the design, nevertheless the PAR tool fails. Are there additional constraints to add?

[kren]

What's the error message you got during PAR? Did you check the memory interface pins within the MIG IP?

[eugeth20]

kren,

thanks for replying. We are exploiting the example design for MIG v4.2 with debug cores and signals. Timing failures are reported for ILA and VIO cores.

As reported in a thread previously open by us (https://forums.xilinx.com/t5/Memory-Interfaces-and-NoC/ILA-and-VIO-dropped-in-Hardware-Manager-for-MIG-v4-2/m-p/1071968#M16213),we had to edit the example design feeding the ILA and VIO cores with the free running clock, so they will not be dropped during implementation (they cannot be fed from MMCM/PLL primitives).

Nevertheless, we noticed that in simulation, the clock feeding the debug cores is set to 133MHz, while we are using a 200MHz oscillator - this is why timing failures occur. What is the correct clock frequency for the ILA and VIO cores in the example design?

Thanks in advance, best regards.

[eugeth20]

kren,

a quick update: we inserted a BUFR macro to divide the 200MHz free running clock frequency by 2, thus feeding the ILA and VIO cores with a 100MHz clock frequency. Nevertheless, placement fails with the following error arising:

[Place 30-512] Clock region assignment has failed. Clock buffer 'BUFR_inst' (BUFR) is placed at site BUFR_X0Y25 in CLOCKREGION_X0Y6. Its loads need to be placed in the area enclosed by clock regions CLOCKREGION_X0Y6 and CLOCKREGION_X0Y6. One of its loads 'CHIPSCOPE_INST.u_ila_ddr3_native/U0/ila_core_inst/u_ila_regs/MU_SRL[84].mu_srl_reg/cnt_reg[2]' (FDRE) is placed in site SLICE_X25Y42 in CLOCKREGION_X0Y0 which is outside the permissible area.

Any workaround?

[kren]

BUFR is used only for regional clock. So please use a BUFG instead.

[eugeth20]

kren,

the following solution was adapted:

IBUFDS_inst : IBUFDS
   generic map (
      DIFF_TERM => FALSE, -- Differential Termination 
      IBUF_LOW_PWR => TRUE, -- Low power (TRUE) vs. performance (FALSE) setting for referenced I/O standards
      IOSTANDARD => "DIFF_SSTL_15")
   port map (
      O => sys_clk_i,  -- Buffer output
      I => sys_clk_p,  -- Diff_p buffer input (connect directly to top-level port)
      IB => sys_clk_n-- Diff_n buffer input (connect directly to top-level port)
   );
   
   BUFGCE_inst : BUFGCE
   port map (
      O => sys_clk,   -- 1-bit output: Clock output
      CE => sys_clk_ce, -- 1-bit input: Clock enable input for I0
      I => sys_clk_i    -- 1-bit input: Primary clock
   );
   
   BUFG_inst : BUFG
   port map (
      O => sys_clk_mig, -- 1-bit output: Clock output
      I => sys_clk_i  -- 1-bit input: Clock input
   );

being sys_clk_p/n the differential clock on the input I/O ports (200MHz), sys_clk_mig the bufferized clock in input to the MIG, and sys_clk_ce the clock enable signal for the BUFGCE macro, behaving as follows for reducing the frequency by half:

    ce_p:process(rst,sys_clk_mig)
        variable counter : natural range 0 to 1;
    begin
        if (rst='1') then
            counter := 0;
            sys_clk_ce <= '0';
        elsif (rising_edge(sys_clk_mig)) then
            if (counter=1) then
                counter := 0;
                sys_clk_ce <= '1';
            else
                counter := counter+1;
                sys_clk_ce <= '0';
            end if;
        end if;
    end process;

The following clock constraints were also applied (by referring to this thread: https://forums.xilinx.com/t5/Implementation/Deriving-a-slow-clock/m-p/672350#M14258) :

create_clock -period 5.0000 [get_ports sys_clk_p]
create_clock -period 5.000 -waveform {0.000 2.500} [get_nets sys_clk_i]
create_generated_clock -source [get_pins u_mig_7series_0/sys_clk_i] -multiply_by 1 [get_nets -hierarchical *sys_clk_mig*]
create_generated_clock -source [get_pins bufgce_inst.i0] -divide_by 2 -duty_cycle 0.25 [get_pins bufgce_inst.O]

Nevertheless, the tool refers the following critical warning on synthesis:

[Vivado 12-4739] create_generated_clock:No valid object(s) found for '-source [get_pins bufgce_inst.i0]'. ["C:/SeQBO/example_top_16_checked.xdc":33]

and implementation:

[Timing 38-282] The design failed to meet the timing requirements. Please see the timing summary report for details on the timing violations.

 as the generated clock is still considered at a frequency of 200MHz instead of 100MHz.

So what is the correct way to generate a clock constraint for this clock?

Thanks in advance, best regards.

[kren]

Are you runing the IP example design? It seems you made modification on the RTL and constraint file.

Did you have any problem on the IP example design implementation without any modification?

[eugeth20]

kren,

yes. As I described in a previous thread (https://forums.xilinx.com/t5/Memory-Interfaces-and-NoC/ILA-and-VIO-dropped-in-Hardware-Manager-for-MIG-v4-2/m-p/1071968#M16213), I was not able to capture signals from the ILA cores for the MIG, as the free example does not feed them with a free running clock, but from the output of a MMCM/PLL primitive.

[kren]

Only the period constraint for sys_clk_p is required. Vivado will run analysis on the generated clocks.

[eugeth20]

kren,

the solution you propose leads to a failing timing closure as follows:

Can these paths be safely ignored?