cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
franko
Visitor
Visitor
13,608 Views
Registered: ‎04-06-2010

Plan Ahead PR Project cant MAP Ethernet Core

Hello everybody,

i implemented and EDK Project with an HARD ETHERNET MAC IP and tried to set up an Plan Ahead PR Project with it. When i implement it with EDK everything works fine and i can use my Software to send and recv. data witht he Ethernet core.  After that i create an PR Project and import everything from the EDK directory (like UG 744). My first Run (that implements the static part and one PRM) was ok. After that i started the secon run with the importet static part and got erros like this : 

 

ERROR:Pack:2780 - The register
   "Hard_Ethernet_MAC/Hard_Ethernet_MAC/V6HARD_SYS.I_TEMAC/SINGLE_GMII.I_EMAC_TO
   P/gmii/RX_DV_TO_MAC" has the property IOB=FORCE, but it did not join an IO
   component because it is not connected to any IO element.
ERROR:Pack:2780 - The register
   "Hard_Ethernet_MAC/Hard_Ethernet_MAC/V6HARD_SYS.I_TEMAC/SINGLE_GMII.I_EMAC_TO
   P/gmii/RX_ER_TO_MAC" has the property IOB=FORCE, but it did not join an IO
   component because it is not connected to any IO element.
....
I tried to find an Core specifi UCF file but i didnt found anything....
Does anyone know how i solve this problem??
thx for help

 

0 Kudos
9 Replies
woodsd
Xilinx Employee
Xilinx Employee
13,604 Views
Registered: ‎04-16-2008

Without all of the details it is hard to say for sure, but I can make some assumptions and try to guess what is happenning.

 

The issue is most likely that the IO register is being connected to PROXY logic, is no longer connected to  any IO element (as the message indicates), and cannot be packed into the IO logic.  This would occur if the IO register and the IO buffer are in different partitions (ie. buffer is in static and the registers is in the RP), and proxy logic is being placed in between the connection.

 

There is a UCF constraint (PARTITION_PIN_DIRECT_ROUTE=TRUE) to prevent the tools from inserting proxy on individual pins of a reconfigurable partition (see the PR User Guide), but this alone won't solve the issue.  You also need to ensure that the AREA_GROUP ranges that define your RP region include the IO Logic required by this register.

 

The other way to solve this is to make sure that the register and buffer are in the same partition so that no proxy gets placed between them, but assuming this EMAC core is a netlist from EDK this may not be an option.

0 Kudos
franko
Visitor
Visitor
13,586 Views
Registered: ‎04-06-2010

Hello,

i'll post the details if you tell me what will help?

 

ok but the Ethernet core isn't in the PRR. There is an other IP that should be reconfigured and has nothing to do with the ehternet core. But i'll try to set an defined static partition for the Ethernet core etc. 

0 Kudos
woodsd
Xilinx Employee
Xilinx Employee
13,575 Views
Registered: ‎04-16-2008

It is interesting that the EMAC core is not in the Reconfigurable Partition (RP), but that it is failing.  Some addtiional information to provide would be:

 

1. What logic is in the RP?  Does it connect to the EMAC core?  Does it have anything to do with the instance listed in the error message?

2. What is difference between the RM in the first configuration that passes, and the second configuration that fails?  Is the RM a black box in the first configuration?  What happens if you change the static partition back to "implement" instead of "import" for the second configuration?  Does map still fail?

3. What happens if you setup the exact same project in PlanAhead, but don't make it a PR project?  Add the same RM netlist that was causing the error in the second configuration as the netlist for this non-PR run.  Does Map still fail?

 

 

0 Kudos
franko
Visitor
Visitor
13,566 Views
Registered: ‎04-06-2010

hello, at the moment i cant answer all your question but i try to get the answer tommorrow..

 

1. no it doesnt... the prm looks similar to the one from  UG 744. just reading data out of the user_logic and adds or multiplies two registers...

 

2. the first run was the adder prm..the second run with an BB 

I'll answer the other questions on friday... 

0 Kudos
franko
Visitor
Visitor
13,526 Views
Registered: ‎04-06-2010

hello again..

i tested the other things you said...

i only get the error when i import the static part from the previous run...when i implement it in both runs everything is fine

0 Kudos
franko
Visitor
Visitor
13,440 Views
Registered: ‎04-06-2010

hello...

does no one have the same problem?

 

@woodsd i can send u my project to reconstruct the problem if this will help you to help me ...

 

 

0 Kudos
woodsd
Xilinx Employee
Xilinx Employee
13,437 Views
Registered: ‎04-16-2008

There must be some dedicated path that crosses the partition boundary.  An exmple would be in the first configuration the tools recognize that the path is dedicated and don't insert a PROXY LUT.  In the second configuration (black box) one side of the dedicated connection is missing and causes an error.

 

This probably isn't exactly right, but somethig along these lines.  At this point you should open a support case and submit your design to be examined.  If you post the case number here I'll try to follow up and make sure it gets resolved in a timely manner.

 

0 Kudos
franko
Visitor
Visitor
13,421 Views
Registered: ‎04-06-2010

hello again...

in fact that i'm a student i wont get acces to the "case" system...but I'll ask my professor to open one but this will take a week because he is on vacation atm..

0 Kudos
woodsd
Xilinx Employee
Xilinx Employee
13,414 Views
Registered: ‎04-16-2008

Okay.  While you are waiting, you can try to debug this yourself.

 

1. Change the IOB=FORCE constraint to IOB=TRUE (this will change the ERROR to a warning, and should allow the tools to complete). Rerun both configurations.  

2. Once you get the second configuration to successfully complete, compare the two designs (configuration1 and configuration 2) in FPGA Editor.  Try to figure out why the flop in question is not connected to an IOB in the second configuration where the RP is a black box.  

 

We already determined that the way static gets implemented in the first configuration is not compatible with the black box configuration, so you just need to figure out what that is.  FPGA Editor should allow you do this.  You may even be able to see this just using the completed first configuration and imagning how the black box configuration would differ.

0 Kudos