11-11-2019 10:27 PM
sir! I encounter a problem.
I generate a ddr4 controller , but there are two error in my project.
[Route 35-19] Driver is not a routable pin (driver inst term u_top/ddr_axi_controller/inst/u_ddr4_mem_intfc/u_mig_ddr4_phy/inst/u_ddr_iob/genByte.u_ddr_iob_byte/genBuf.genBuf.OBUFDS/O, cell type OBUF, site type HPIOB_M). design will not pass DRC check. Router will skip the net .
This the message given by VIVADO201801 . I can't generate bitstream.
Please help me , thank you very much!
11-12-2019 09:06 AM
Have you generated the DDR4 example design (right-click on the DDR IP and click "Create IP Example Design...")?
That will show a working design and how the controller should be routed.
Have you changed anything in the layout/clocking/pinout of the DDR controller? Can you provide more information on your design and what exactly you have done to generate this issue?
11-12-2019 10:07 PM
I haven't change any thing about the ddr4_controller.
The picture is the config about the controller, System Clock Option is Differential,
the c0_sys_clk_p is 250M CLK from xcvu9p (GCIO).
11-13-2019 08:31 AM
In the future can you use the "Snipping Tool" on Windows, or on Linux there are plenty of screenshot tools that can be used for free. This will help with our ability to read the images sent.
Otherwise, the error you show looks to be in Synthesis or Implementation, where exactly are you seeing that error show up?
In Synthesis you will need to determine the pin planning for the eventual pinout of the DDR. This means you will need to have additional steps in Synthesis before you will be able to get the design to complete Implementation.
Is this design the example design? If not, please try with the example design using the configuration of your DDR controller.
Have you tried with the default clocking and not choosing your own MMCM ratios? Does that allow you to get passed this issue?
11-13-2019 10:48 PM
I close the my MMCM ratios, but it apperas the same error.
The error not the pin out, it is in the blackbox, the rtl uses the generation to produce some genBuf[*], but only the genBuf have error, others are right.
Please help me , thank you very much.
11-14-2019 08:24 AM
Please try running the DDR example design. This should pass routing, but I want to make sure before going any further. Otherwise, this isn't a particular issue with the DDR controller as the controller has been able to route properly in many designs. Here is an AR which talks about how to debug routing issues: https://www.xilinx.com/support/answers/53854.html
I would also be interested in how you are constraining the design. Can you try setting the DONT_TOUCH property like in this forum post? https://forums.xilinx.com/t5/Implementation/Implementation-Complete-but-many-unroute-nets/td-p/825198
11-18-2019 03:06 AM
DONT_TOUCH can't solve the problem. The error is the follow:
Name Cell Pins Flat Pins Driver Route States
CK_C 1 2 _ Routable but not routed
CK_T 1 2 _ Routable but not routed
I just only creat a clock on the CK_C pin, haven't constained ohters.
11-18-2019 07:34 AM
Is your input differential clock to the DDR IP coming from off the FPGA? Can you show the block diagram of your design?
11-18-2019 11:44 PM
The CLK_n come from xcvu9p D12, CLK_p come from xcvu9p E12.
I just find the differential clock from SLR2 with DDR4_C1.
The CLK_n/p just only connect to the DDR4_controller without through any pad and buf.
Does CK_T need constrain ? The error show the CK_T/CK_C can routable but not route, is it need special constain?
The picture is the block diagram of my design.
11-19-2019 07:51 AM
Having the differential clock connected from off-chip is correct. What do your constraints look like? I don't believe you should need a special constraint. The error looks to be like you have multiple BUFGs connected in series for the CK_T/C.
The DDR controller should do the constraining properly for the interface clock if given a proper clock and the correct placement of all the DDR pins. Can you double check with the PG150 pin guides (this starts on page 104)?
11-20-2019 06:52 PM
11-21-2019 08:55 AM
We have a maximum frequency that you can run the AXI interface, but you can also run slower. 100 MHz is an acceptable rate to run the AXI interface at if desired.
In terms of a cell for reset, have you looked at the IP titled Processor System Reset? That takes in a clock input and provides a reset output that is synchronous to that clock domain.
11-22-2019 02:06 AM - edited 11-25-2019 02:20 PM
The i.MX 6DualPlus/6QuadPlus Multi Mode DDR Controller (MMDC) can be used to program the
DDR3/DDR3L device for proper operation. This is achieved by an initialization sequence of specific
register writes prior to accessing the external DDR device. Programming of the DDR3/DDR3L memory
device is dependent on various factors such as:
• DDR memory timing and speed grade
• Memory layout (Fly-by, T topology) https://redtube.vin
• Bus width (x32, x64)
• Drive Strength and Board layout
Since the above factors are dependent on the customer’s DDR memory selection, use case and board
design, common programming recommendations cannot be provided as they will be unique for each
customer design. NXP provides a DDR3 MMDC register programming aid to help in configuring these
specific parameters. Contact your NXP field engineer or sales representative for the i.MX
6DualPlus/6QuadPlus DDR3 Register Programming Aid.
11-22-2019 08:17 AM - edited 11-26-2019 08:32 AM
I think you responded to the wrong thread as this is related to a DDR4 controller and device.
If you are trying to run the DDR controller at a slower speed that would mean a slower clock speed and you can find how to change that in PG150 page 88. I will say that will be absolutely detrimental to your performance, and you probably will be better off using an AXI Smartconnect to perform clock conversion to a higher frequency that the DDR Controller desires.
In terms of timing failures, that is likely something in your design that would cause that as the DDR Controller would not fail timing. I am not sure what your design is doing so I cannot say what would get you to pass timing. I would suggest confirming that all required pin rules are met based on PG150 page 104.