The problem I have is stated in the subject. I tracked this through a number of warnings at differnet phases in the flow.
1) The first trial route during pre-cts optimization issues the following warning:
**WARN: (ENCTR-2325): 42 nets connect a pad term to a fterm without geometry and will not be routed.
This however,does not stop the optimization engine and the flow continues. Trial route completes giving an accurate picture of how things should be.
2) When nanoroute is invoked a whole bunch of these warnings are issued:
#WARNING (NRDB-733) PIN AHB_ADDR_PAD in CELL_VIEW CHIP,init does not have physical port#WARNING (NRDB-733) PIN AHB_ADDR_PAD in CELL_VIEW CHIP,init does not have physical port#WARNING (NRDB-733) PIN AHB_ADDR_PAD in CELL_VIEW CHIP,init does not have physical port#WARNING (NRDB-733) PIN AHB_ADDR_PAD in CELL_VIEW CHIP,init does not have physical port#WARNING (NRDB-733) PIN AHB_ADDR_PAD in CELL_VIEW CHIP,init does not have physical port#WARNING (NRDB-733 Repeated 20 times. Will be suppressed.) PIN AHB_ADDR_PAD in CELL_VIEW CHIP,init does not have physical port#WARNING (EMS-27) Message (NRDB-733) has exceeded the current message display limit of 20
I found an earlier post here just now explaining what this warning means. In light of the previous warning, I think these re related but still no closer to a solution.
This issue passed the geometry and connectivity checks in EDI (run with default options) and came to light when I ran DRC with Calibre.
Any help is appreciated.
PS: I have pictures of the connectivity at the pad pins after TrialRoute and NanoRoute, but am not sure how to upload them.
Thanks for your question - this is a common area of confusion and I'll share some thoughts and perhaps follow-up with a more comprehensive blog entry on the subject.
First, I did some tests and I see NRDB-733 being issued in cases where it shouldn't be. But the fact that you're seeing ENCTR-2325 makes me think you might have a slightly different scenario than what I suspect.
The first thing I'd suggest to anyone dealing with this is they make sure the IO cell is marked CLASS PAD -or- CLASS PAD AREAIO in the lef file. The reason this is important is because it's what tells the software *not* to create IO pins for top-level module pins connected to pins on the IO cell. For example, in the following netlist we don't want an IO pin created for the logical top-level IO pin in the testcase module:
module testcase(in); input in; wire net; PDIDGZ i0(.PAD(in), .C(net)); BUFX1 i1(.A(net));endmodule
Next, a related area where confusion frequently arises is related to bumps. But I don't see anything about bumps in your message so let's set that aside and focus on your specific situation. It sounds like you discovered a real error in Calibre. If I had to guess it would be for an IO pin that wasn't connected and therefore failed minimum area? If not please correct me.
I see cases where NRDB-733 is generated erroneously and can be ignored. But I don't want to give that advice across the board - it sounds like you have a legitimate issue here that needs to be resolved to pass DRC.
Could you send me the picture and I'll post it here? email@example.com
In reply to Robert Dwyer:
Thank you for your quick response. I have confirmed that all the IO macro's are marked CLASS PAD INOUT. However, I think in this case the warnings I flagged must be erroneous, because the DRC errors flagged at the pads are related to min width and slotting. With virtually no experience with signoff (have mainly dealt with RTL stuff and verification in the past, but this is the first time I am handling a design till signoff) I could be wrong and if so, please correct me.
All the same I think it is interesting to know when, these warnings can be ignored and why the visualization is the way it is.