cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
rayhaynes
Adventurer
Adventurer
2,029 Views
Registered: ‎02-08-2013

IODELAY_GROUP problem with a block design NOT SOLVED - HELP!

Jump to solution

I posted this topic previously and @shameera responded with an AR that addressed and I prematurely marked it as solved (can't unmark it?). The problem is I'm using the AXI Chip2chip IP in 2 places in this design and because they share common code base they also share the same grouping name for IODELAY_GROUP=C2C_PHY_group. This causes an error in implementation. The AR that shameera pointed me to suggested modifying the HDL to change the group name in one of the files. The problem is that for this IP all the HDL is encrypted. I have this sinking feeling that I'm at a dead end and not being able to fix this will cause a major architecture change late in the game. Can anyone offer a suggestion? 

 

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
0 Kudos
1 Solution

Accepted Solutions
vemulad
Xilinx Employee
Xilinx Employee
2,852 Views
Registered: ‎09-20-2012

Hi @rayhaynes

 

You can apply the property from XDC file. Open the synthesized design, get the names of IDELAYCTRL/IODELAY cells inside one of the IP's mentioned in the error and then set the IODELAY_GROUP property on these cells to a different value in XDC.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)

View solution in original post

4 Replies
austin
Scholar
Scholar
2,019 Views
Registered: ‎02-27-2008

r,

 

I believe you can 'create HDL wrapper' for the block, and you may then rename that wrapper to whatever you want, and create another wrapper with a different name for the next use.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
rayhaynes
Adventurer
Adventurer
2,014 Views
Registered: ‎02-08-2013

The hierarchy is not part of the group naming specifically so the groups can reach across hierarchies and tie common elements together which in this case does not help (I could be and hope I'm wrong). If there is a way to make groups local to specific hierarchical levels that would help. This is the exact error I receive:

 

  • [DRC PLIDC-3] IDELAYCTRLs in same group have conflicting connections: IDELAYCTRL cells 'u_axi_block_wrapper/axi_block_i/axi_chip2chip_master/inst/master_fpga_gen.axi_chip2chip_master_phy_inst/master_sio_phy.axi_chip2chip_sio_input_inst/idelayctrl_gen.IDELAYCTRL_inst' and 'u_axi_block_wrapper/axi_block_i/axi_chip2chip_slave/inst/slave_fpga_gen.axi_chip2chip_slave_phy_inst/slave_sio_phy.axi_chip2chip_sio_input_inst/idelayctrl_gen.IDELAYCTRL_inst' have same IODELAY_GROUP 'C2C_PHY_group' but their RST signals are different
Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
0 Kudos
vemulad
Xilinx Employee
Xilinx Employee
2,853 Views
Registered: ‎09-20-2012

Hi @rayhaynes

 

You can apply the property from XDC file. Open the synthesized design, get the names of IDELAYCTRL/IODELAY cells inside one of the IP's mentioned in the error and then set the IODELAY_GROUP property on these cells to a different value in XDC.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)

View solution in original post

rayhaynes
Adventurer
Adventurer
1,950 Views
Registered: ‎02-08-2013

Ok, the suggestion from @vemulad did fix the problem. But let elaborate on the steps to do so.

In my case I had 2 idelay blocks who's IODELAY_GROUP parameters where named the same. I needed to change one of the names.

 

Open the synthesized design

Following the path listed in the error message to one of the offending elements, navigate down the Netlist tree to that element. Click on that element. 

Then in the Cell Properties box click on the Properties tab. In that listing of properties you should see the offending property and assigned name. Just change the name, say by adding a 1 to it.

Click on Run Implementation and select Reset and Re-run.

It will then prompt you to save the new constraint created by the name change above. Then I think you'll be good to go.

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
0 Kudos