ERROR:u_ibufg_sys_clk pin I has an invalid driver c0_sys_clk_p_BUFG_inst

Status
Not open for further replies.

rahdirs

ERROR: [Drc 23-20] Rule violation (REQP-61)

While i was implementing my project,i'm getting a DRC error.
Full error(could not post in title bcoz of length constraint).

ERROR: [Drc 23-20] Rule violation (REQP-61) ibufds_connects_I_active - IBUFDS /.../.u_ibufg_sys_clk pin I has an invalid driver c0_sys_clk_p_BUFG_inst

The signal that he mentions c0_sys_clk_p is an i/p to my top module.Invalid driver ?How do i drive my i/p ?

Digging down into his ip core my input clock goes into:

Code:
  c0_u_ddr3_clk_ibuf : mig_7series_v2_3_clk_ibuf
generic map
(
SYSCLK_TYPE      => SYSCLK_TYPE,
DIFF_TERM_SYSCLK => C0_DIFF_TERM_SYSCLK
)
port map
(
sys_clk_p        => c0_sys_clk_p,
sys_clk_n        => c0_sys_clk_n,
sys_clk_i        => c0_sys_clk_i,
mmcm_clk         => c0_mmcm_clk
);
and in mig_7series_v2_3_clk_ibuf

Code:
IBUFGDS #
(
.DIFF_TERM    (DIFF_TERM_SYSCLK),
.IBUF_LOW_PWR ("FALSE")
)
u_ibufg_sys_clk
(
.I  (sys_clk_p),
.IB (sys_clk_n),
.O  (sys_clk_ibufg)
);

- - - Updated - - -
Looking into my UCF file,

set_property VCCAUX_IO DONTCARE [get_ports {c0_sys_clk_p}]
set_property IOSTANDARD DIFF_SSTL15 [get_ports {c0_sys_clk_p}]
set_property PACKAGE_PIN E16 [get_ports {c0_sys_clk_p}]

set_property VCCAUX_IO DONTCARE [get_ports {c0_sys_clk_n}]
set_property IOSTANDARD DIFF_SSTL15 [get_ports {c0_sys_clk_n}]
set_property PACKAGE_PIN D16 [get_ports {c0_sys_clk_n}]

i also get a critical warning: CRITICAL WARNING: [Drc 23-20] Rule violation (IOSTDTYPE-1) IOStandard Type - I/O port c0_sys_clk_n is Single-Ended but has an IOStandard of DIFF_SSTL15 which can only support Differential

I'm thinking this may be the error & i should change io standard but this constraint was generated by xilinx,so should i do it/not ?

Last edited:

std_match

IBUFGDS is not like other logic elements, which can be connected freely. The inputs are connected directly to physical pins, so you must use pins that have an IBUFGDS.

Super Moderator
Staff member
As I recall I think the I/O standard is only applied to the _p side not both.

Your error at the top indicates a BUFG was inserted and you're connecting a BUFG to the input of an IBUFDS or vice-versa, which can't be done.

Without seeing the entire path of the clock in your code it's hard to tell what happened.

vGoodtimes

This might be an issue with IP integrator or using a hierarchical design. I recall seeing some issues like this in the past, but I don't think I worked directly on it until it was time to just get things done. A year ago, some of the Xilinx cores were not ready for ip-integrator and we would routinely use the HDL source and modify the clocking scheme to match our FPGA (which would have been overmapped on MMCMs, PLLs, and BUFGs).

In this case, it is possible something uses the pad as a clock in the fpga top level. This would infer the BUFG from that pin. When the pre-synthesized MIG netlist was merged with the top level, the input to the ibufgds now appears to come from a bufg.

There is probably an answer record for this problem somewhere.

rahdirs

In this case, it is possible something uses the pad as a clock in the fpga top level. This would infer the BUFG from that pin. When the pre-synthesized MIG netlist was merged with the top level, the input to the ibufgds now appears to come from a bufg.

pad as a clock in fpga top level ?

My design uses MIG ip core for DDR3.The example project that xilinx gives along with ip core got implemented succesfully.The only change i did in his example_top given by xilinx was to add my user_logic(fsm) & some fifo's & a adc interface & comment out his traffic generator.

rahdirs

Your error at the top indicates a BUFG was inserted and you're connecting a BUFG to the input of an IBUFDS or vice-versa, which can't be done.

Without seeing the entire path of the clock in your code it's hard to tell what happened.

The signals c0_sys_clk_p & n are input to my top module.I did not insert any IBUFG in its path.The signal flow in entire path comes down to code in #1.
There are 2-3 modules with just port mapping clk signal & finally modules shown in #1.

Attached is the implementation log file(Log_file.txt) & XDC file provided by xilinx which i'm using(uploaded as mig_7series_0.txt).

Attachments

• Log_file.txt
33.7 KB · Views: 2
• mig_7series_0.txt
91.7 KB · Views: 2
Last edited:

Super Moderator
Staff member
Did you look at the Log_file.txt?

There are warnings about the c0_sys_clk pin and their placement and that the tools don't think it's connected to the correct pin or connected to the top level.

You also have warnings of invalid attributes being used.

rahdirs

Your error at the top indicates a BUFG was inserted and you're connecting a BUFG to the input of an IBUFDS or vice-versa, which can't be done.

After synthesizing my design, i opened the schematic of my design.
I see that my input c0_sys_clk_p is connected to IBUFG, the output of which is connected to BUFG which is getting connected to IBUFDS in i/p core.(which is what the tool's complaining about)

I noticed that this additional IBUFG & BUFG are coming onto signal path because i was giving c0_sys_clk_p (input) to ip_core & two other modules(fifo & fsm module) for which i want to have the same clock.

How can i do this ?To have same clock for ip_core & those two other modules.
One method is give c0_sys_clk_p only to ip_core & have another input clock which has same period as c0_sys_clk_p which drives those other modules.

Is there any other way,which does not involve incorporating an additional clock input onto my top module ?

Super Moderator
Staff member
I believe the core has output user clocks, that you are supposed to use.

Status
Not open for further replies.

Replies
7
Views
4K
Replies
1
Views
3K
Replies
0
Views
2K
Replies
2
Views
1K
Replies
1
Views
2K