Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[Cadence Encounter] Macro Block Signal Pin Connections

Status
Not open for further replies.

cheesyfeet

Newbie
Joined
Apr 15, 2018
Messages
5
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
64
I have managed to place and route a ROM macro, however have issues when running verifyGeometry. This throws violations due to 'Short Violations' between the signal nets of the routed tracks and the blockage of the ROM. This only occurs on certain pins. On investigation, these pins are the input pins, with size (0.5x0.5) - the output pins of size (2x0.5) do not throw errors.

I think that the problem is that the signal tracks are of width 0.6, which means that the track exceeds the pin area and causes a violation. I tried to reduce the track width using a NONDEFAULT rule, however it appears that 0.6 is the minimum for the technology (ams C35B4) so throws errors when I try to route. The ROM is generated for the C35B4 tech, so i'm not sure why the pins are below min size, but does anyone have any ideas how this can be rectified? My thought was to try and instruct nanoRoute to not overlap the pins (ie. abut the signals to the pins and stop as soon as touching, thus not overlapping the OBS layer) but I'm not sure if this is a good idea or how to tell the router to do it.

Violations on side of macro:
violations.jpg

Close up of violation on single pin (error message at bottom):
violation.jpg
 

verifyGeometry is not a good way to verify drcs, it is known for giving false positives. check with real drc before trying crazy solutions
 

I've run the design through Assura and encountered the same issues... any suggestions for those crazy solutions? :grin:
 

I've run the design through Assura and encountered the same issues... any suggestions for those crazy solutions? :grin:

Whenever I encountered something like this the solution was always ugly. Here are some ideas:
- Edit LEF files by hand. The results... vary.
- Maybe you are supposed to drop a via on the problematic pins instead of routing to them with metal. You can instruct nanoRoute to do that with the droute options.
- Maybe you need to draw route blockages to force the router to adhere to a certain routing style.

Also make sure to read the IP documentation. There might be a hint somewhere about connectivity problems.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top