NanoRoute: DRC / LVS issues

 Kul,

Make sure you have antenna fixing turned on in nanoroute:

setNanoRouteMode    drouteFixAntenna    true
setNanoRouteMode    routeInsertAntennaDiode    true
setNanoRouteMode    routeAntennaCellName        "ANTENNA"  (put your antenna cell here)

If you only want to do layer-hopping and not diode insertion, then omit the last 2 lines.

The samenet spacing is interesting. Check the metal3 spacing rules in your LEF and also look for a SAMENET spacing section. I have seen LEF files where a SAMENET rule was set up, but violates the main spacing rule. Usually the SAMENET rule can be removed.

A postRoute opt  should fix your max tran and max fanout violations. You don't need to go back to preCTS unless there's a fundamental problem.

optDesign -postRoute

 - Kari

Hi Kari,

Thanks for your valuable suggestion.

1. i have given two tech lef fiiles and there is different spacing rule for the same net exa: 

samenet (metal 3) spacing 0.7 (in one file ) & 0.5(other file), so thats why i was getting the same net violation.

 2. For Antenna violation , it has cleared all except 2 violation and it is showing violation like

  Process antenna report created by VERIFY ANTENNA.

EEPROM_DO_eep0[3] (2)
  u_eeprom_dft_mux/U510  (mx22_b) I1
[1]    metal3:  Area:  303.68  S.Area:  729.65  G.Area:    0.70  D.Area:    0.00
                                  CAR:  454.19   Ratio:  300.00       (C.Area)
EEPROM_DO_eep2[3] (2)
  u_eeprom_dft_mux/U851  (mx22_b) I0
[1]    metal3:  Area:  292.80  S.Area:  707.62  G.Area:    0.70  D.Area:    0.00
                                  CAR:  422.65   Ratio:  300.00       (C.Area)

Total number of process antenna violations: 2
   Number of pins violated: 2
   Number of nets violated: 2

-- what is workaround this because again these violation on Metal3 (max layer) and i have specified tool to add the ANTENNA cells and  i cant do the metal hogging for this.

please suggest.

3. Actually after CTS, i have solved hold violation manually because tool was adding lot of buffers (3000) in the optimization, so i did manually and i checked only hold time and i have not checked for setup and DRV checks and directly proceed for the routing.

then i realize that may be cause, after fixing hold vioaltion, i did the refine placement and then check for the setup & DRV vioaltion there i found lot of DRV violation with setup and then i optimized the design only setup & DRV checks by tool then it clears all the violation and i checked for the hold also. there were no hold violation. fianlly i did routing.

is it correct way of doing ?? may be i am doing wrong way or putting extra efforts? any other method because i dont know the eco flow, can you suggest any smoothen alternate way?

Please suggest.

Thanks & Regards,

Kul

Hi Kul,

I'm glad you got some of your issues resolved! For the remaining antenna violations, try adding an antenna cell by hand. Since you only have 2 left, it shouldn't be too bad. You may first want to run your signoff DRC/Antenna deck though - the results can sometimes be different than the output of Verify Antenna. The signoff check may show that those last two violations aren't real antennas, or it may show that you have a few more.  

 Your flow for fixing holds/setups sounds pretty typical, except that we normally let FE do the first round of hold fixing. But it is normal for hold fixing to break some setups/DRVs, then you go back and fix those, check holds again to make sure those are still good, etc. You may go back and forth like this a couple of times until things settle down. This isn't really an ECO flow - when we talk about an ECO, it usually means a functional netlist change. What you are going through is timing optimization. I would try to figure out why FE is adding so many buffers when you first try to fix holds. If you can get to the root of that issue, you would save yourself a lot of time doing hand-fixes. But if you have something scripted up, it may not be that big a time-hit.

 - Kari

 Hi Kari,

Thanks for your valuable suggestions.

Actually i have gien the antenna cell name as "ANTENNA" and it was not taking tthis option (in my library there is no antenna cell), so i changing the option in the nanoroute (only insert the diode option) and run the nanoroute then it cleans all antenna violation and some other DRC violation cleaned manually.

now the databse is clean and started working on calibre checks (DRC/LVS) using caliber and i have cleaned all DRC violation.

while running LVS, i am getting lot of violations (missing nets violation), i have given the input like

1. i dont have spice format file to give input, so i dumped verilog file from layout database and given input the tool and the GDS database. calibre has verlog translator option, here i have given ".cdl" file, instead of spice format libraries and run the command, and it is showing lot of missing nets vioaltion.

I thoght there may be netlist problem and i tried different command to dump the netlist and i got different results in caliber  

1. saveNetlist design_db/backend.lvs.v -excludeLeafCell -includePowerGround

2. saveNetlist design_db/backend.lvs.v -includeLeafCell -includePowerGround

2. saveNetlist design_db/backend.lvs.v -phy

3. saveNetlist design_db/backend.lvs.v  

which one is the correct format or command to dump the verilog netlist for LVS??

we are checking on caliber dabase option not on heirarical mode and i tried to convert this verlog file into spice format by using following command:

 v2lvs -v backend.lvs.v -s library.spi -o bakend.spice > v2lvs.log

there is license issue for this command.

i used ".cdl" files as explained above, verilog library files are necessery for these conversion?

any command which converts verlilog into spice format using ".cdl" library file.

Thanks & Regards,

Hi Kul,

I'm glad you're antenna clean now! I'm not the best LVS expert, but here is what I typically do:

1. output a physical verilog from Encounter, excluding "empty" filler cells (if your fillers are also decap cells, leave them in):
   
   saveNetlist design.phys.v -phys -excludeCellInst FILL1 -excludeCellInst FILL4 -excludeCellInst FILL8
   
2. run v2lvs:
   
   v2lvs -v design.phys.v -s library.spi -o design.source.spice
   
   where library.spi looks something like this: (your files may be .cir, .spi, or .cdl)
   
   .INCLUDE /proj/phoenix/libs/CDL/std_cells.cir
   .INCLUDE /proj/phoenix/libs/CDL/rams.cir
   .INCLUDE /proj/phoenix/libs/CDL/io_cells.cir
   
3. use the spice output from v2lvs in your lvs run

I'm not sure I've answered your question, but I hope some of this helps.

- Kari 

Hi Kari,

Thanks for all responses.

Actually there was a problem in the netlist and the netlist has the assign statements and caliber doesnt undersatand (i beleive) the asssign statements, so it was showing the errors. again i dumped netlist withought assign statements (asssign converted into permanant buffer) then its working fine. 

how to work on the metal fill & via fill? first with default setting i added metal fill and then trimmed and i saw no violation (metal density & DRC violations too). next i have added via fill with same tool default way, but this time i got lot of connectivity error on the VDD antenna net (all violations are on metal1(via12), then i have disabled (VIA12) option and try to insert the via but the error remains same.

is thier any flow to use these two steps(MEATL Fill & VIA fill) and both are necessry to do (basically technolgy >0.18u)?

what is difference between these two and adding filler cell also. is thier white paper or technical paper for details about this and the flow. 

Thanks & Regards,

Kul 

Hi Kul,

I'm glad you got your LVS working!

It sounds like your metal fill works well too. Are you sure you even need via fill for your technology? I have never had to add via fill to a design. Do you have DRC errors saying your via layer density is too low?

Filler cells are for continuing wells, std cell rails, etc. Metal fill is to achieve a minimum metal layer density across the whole chip. It's usually checked by stepping a check-box of a certain size across the chip and making sure the density in each check box meets the required percentage. You can also have max density errors in some technologies (too much metal).

I don't have any links to white papers on these topics, so I hope my explanations are of some help.

- Kari

Hi Kari,

Thanks for reply. Actually i was not aware of the VIA fill should done if we have any error, i thought both (metal filling & VIA fill) used for the density errors, so i added both and run the verification i got the DRC on the metal1.

i reloaded the routed design (i am not aware how to remove both metal fill & Via fill) and first i used metal fill to solve density vioaltion and there was no errors, so i have not done VIA fill.

what is basic differnce between metal fill & via fill and when to use the commands.

one more query: while routing nanoroute is adding filler cells and due to this it is creaing some DRC, how to disable this and can we add filler after routing also. After routing, if i have to remove or add the cell then what are the steps or commands to follow. i tried to see in the user guide, i was no able to find out, i think basically routing eco steps.

Thanks & Regards,

Kul   

 Hi Kul,

I would do as you did, and save the design right before metal fill. That way you can always go back. If you do want to delete the metal fill, I think you can do it by hitting "d" to bring up the select/delete form, and delete shapes of type FILLWIRE. I did not try this, so let me know if it works.

Via fill is just like it sounds - it will add cut shapes to meet a minimum cut density, if your fab has specified one. None of the chips I have done needed via fill, so it may not be common.

If nanoroute is adding filler cells, then you must have used setFillerMode somewhere in your session. This should not be creating DRC violations; could you explain what kind of violations you are seeing, or post a picture? You can add filler cells after routing, as long as they are "empty" fillers; that is, they do not contain any devices or other metal that would interfere with signal routing.

You've posted a lot of good questions in this thread. However, it's probably a good idea to start new threads for new topics, so that other folks searching the forum can find this information too. :-)

- Kari 

 Hi Kari

I have a similar problem. When I'm running a verifyGeometry I get about 46 samenet spacing violations - all on VIAs. When I run verifyGeometry with -allowDiffCellViols, all these violations are cleared. So someone advised that its probably not the routing that's causing the violations but the cell design. But those are the standard cells for First Encounter and I have no clue why they might be causing the problem. Any advise on this would help me a lot.

Thanks,

Priyatham.