Stats

  • Locked Locked
  • Replies 5
  • Subscribers 91
  • Views 17518
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DRC error correct!

Shankar P

Hi,

 Please help me in clearing these DRC errors. I use UMC180(0.18u) technology standard cells, design kit being obtained from Farday Corporation. I used Encounter to do my place and route and streamed in my instances in Virtuso editor and finished a clean DRC check in Assura too. When our design was passed on to our IP vendors (IMEC) they reported (the given three) nearly 550 violations.

1) RULECHECK 4.2B.a ............ TOTAL Result Count = 102 (102) Minimum N-Well to N-Well spacing for equal-potential is 0.9

2) RULECHECK 4.16B .............. TOTAL Result Count = 229 (266) Minimum space between two NPlus regions is 0.40um

3) RULECHECK 4.17B............... TOTAL Result Count = 227 (264) Minimum space between two PPlus regions is 0.40um

I could see filler cells near the location where Violation(1) occurs. Violation(2) and Violation(3) in the vicinity of fillers and no big observation did I make.

 Filler cells available in my library are FILLER1, FILLER2, FILLER4, FILLER8, FILLER16, FILLER32, FILLER64, FILLER2C, FILLER4C, FILLER8C, FILLERAC, FILLERBC, FILLERCC. Those which end with the letter 'C' have a built in decoupling capacitance constructed using MOS caps.

Please help me in clearing those violations. I suspect if these fillers with decoupling capacitance are causing the problem. I am not sure because I don't have the layout information for the standard cells. So I can't run a DRC check even after replacing fillers. Have anyone faced these sort of situations  My tapeout deadline is on Dec1 and I was replied with the following errors on Nov 29.  Please help me in solving this issue at the earliest.

 Thanks in advance

Shankar

  •  Hi Shankar,

    Sorry I'm only just getting to this, since you mentioned your deadline was yesterday! I hope you were able to find out the cause of the issue. It sounds like you don't have GDS for the library, is that correct? It will be very hard to debug in that case. But you said you streamed in to Virtuoso, so I'm wondering what your design looks like there if you don't have GDS. You can't run a signoff DRC without all the layers, so whoever IS running the signoff DRC and has access to the layouts will have to help you out a bit more. I'm sorry I'm not more help here. Let me know if I misunderstood the situation.

     - Kari

  • Hi Kari,

    Thanks for the reply. I haven't yet found out the cause of the problem. But the problem still exists. I replaced those fillers with the new ones and send them again. But still do they report DRC violations. So issues are not solved. I don't know if they would give me some more slack to clear the issues.  

     I have to import them to virtuso because, I share my design space in the padframe with some other analog blocks. I don't have the transistor level layout view of these standard cells. In Virtuoso, I would see a black box instance for the standard cells. If I enter inside that cell, I would see the metal layer information alone. So to the maximum, I can clear the metal layer violations and not the transistor spacing violations.

    Shankar

  •  Hi Shankar,

    I'd say that whoever owns the GDS of the cells is responsible for fixing these DRC violations (or obtaining waivers if they are false).

    - Kari 

  • Hi Kari

    Thanks a lot for your prompt reply. We just sorted out the problem. We insisted in sending the log messages of those people and also had a look at the log messages we had, when we streamed out the gds. Also did they tell this time clearly that Filler cells were missing(which aren't supposed to be. I added filler cells). The exact happening is below. 

    My design has two digital modules designed seperately in encounter. I had connected them manually in Virtusoso editor. While streaming out those designs along with other analog blocks, the cells (standard cells) common in both the digital modules get renamed as cellname_libraryname. Eg: filler1 was replaced as filler1_core and filler1_buffer like that. So these filler1_core would be replaced by black boxes there and when they run DRC, we get these errors.

    Now I manually corrected these common cells in both the designs to point out to one global cell.  Now there wont be any renaming because of having same cell name.  Thus the issue was sorted out.

     Shankar

  •  I'm glad you found and fixed the problem!

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.