09-09-2018 07:22 PM
I used IDDR in my design,simultaneity,IDDR input signal was connected to registers.
these registers used ILOGIC adjacent to PAD, IDDR is too far from PAD. in result ,the signals is not completely rout.
why iddr placement is so far from its pad,how to design my XDC file.
09-09-2018 08:02 PM
I don't understand your question. Maybe some images would help.
The IDDRs are (and can only be) in the ILOGIC - in fact, the ILOGIC is simply a boundary for containing the IDDR and the ISERDES. Furthermore, the only legal connection to the D input of the IDDR is the O output of the IBUF it is adjacent to - there is no other legal connection. So, by definition, the IDDR is always close to its PAD - it cannot be anywhere else...
09-10-2018 01:52 AM
for example , pad_rb_0_in[2:0] is original signals. ss_pad_rb_0_in registers pad_rb_0_in.
and pad_rb_0_in is input signal to oddr module.
09-11-2018 09:19 AM
Admittedly, I don't understand the structure shown here - maybe if we saw the code and/or a schematic.
But it appears that the input is being sampled in two places - one in an FDRE in an IFF (so an IOB flip-flop) and again in an IDDR. I have no idea how this is being done, since this is supposed to be structurally impossible - both the IDDR and the IOB FF are supposed to be able to be driven only by the IBUF in the same IOB (although you can drive an IDDR as well as a fabric flip-flop with the same input).
09-11-2018 07:25 PM
You are right，both the IDDR and the IOB FF are driven only by the IBUF in the same IOB in my design.
Is there any problem with this?
ODDR iddr_odata( .Q(iodata_mux), .C(iodata_out), .CE(1), .D1(iodata_out), .D2(iodata_out), .R(0), .S(0));
IDDR iddr_idata( .Q1(iodata_in) .Q2(iodata_in), .C(iodata_out), .CE(1), .D(iodata_buf), .R(0), .S(0));
assign iodata_in = iodata_buf;
ss_iodata_in[2:0] <= iodata_in[2:0];
ss_iodata_in be placed in ILOGIC,but i want IDDR to be placed in ILOGIC and ss_iodata_in be placed in slice,
How to design my XDC file?
thank for your replay!
09-11-2018 08:14 PM
So, there doesn't appear to be anything wrong with your code - it is legal for the IBUF to drive both the IOB FF/IDDR/ISERDES as well as make a connection to the fabric.
What is odd here is the connection from the output of the IBUF in one IOB to the input of the IDDR in another IOB. This is just illegal, and the tools should not be able to do this - this should be an unroutable connection. Did the router actually complete without error?
Since this situation is not supposed to be possible, I can't really advise you on how to fix it. You could try
set_property IOB TRUE [get_cells iddr_data]
set_property IOB FALSE [get_cells ss_iodata_in_reg]
(The IOB property can be set on the register instead of/as well as the port).
But I don't know if this will make a difference...
09-13-2018 08:13 PM - edited 09-13-2018 11:18 PM
The router actually complete with error.Thinks you for your explains, i get some clues.
I add negligible combination logic between ss_iodata_in_reg and PAD,This problem may be resolved?