02-22-2011 12:55 PM
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 :
02-22-2011 01:39 PM
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.
02-22-2011 11:19 PM
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.
02-23-2011 08:15 AM
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?
02-23-2011 11:26 AM
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...
02-25-2011 08:14 AM
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
03-07-2011 12:13 PM
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.
03-08-2011 02:03 AM - edited 03-08-2011 02:08 AM
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..
03-08-2011 07:50 AM
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.