1 2 First Previous 21 Replies Latest reply on May 31, 2012 6:18 AM by chris_balcom

    HCELL selection for LVS


      HCELL selection can be a controversial topic. I would like to describe a few different techniques, the rationale behind those techniques, and hopefully generate some discussion based on your experiences.


      One technique focuses on performance. In the interest of fastest turnaround time, we can choose cells based strictly on the potential time savings that choosing any particular cell may bring. Any cell containing just a few devices, and then placed just a few times, would offer little value from the standpoint of performance. On the other hand, a cell that contains several thousand devices, and placed multiple times, is a good candidate for the hcell list. Calibre Interactive can help create an hcell list of this nature. From the command line, it can be invoked with "calibre -gui -lvs". Several fields will need to be filled in for netlist names, top cell names etc. The process is described in the "Calibre Interactive User's Manual" in the section titled "Performing Hcell Analysis in LVS". A high performance hcell list may have a surprisingly small number of hcells... Possibly less than 10 or 20 cell names. While the performance aspect of this method seems clear enough, I do sometimes wonder if the small number of hcells ever has a negative side effect of increased difficulty for LVS debug.


      Another technique focuses on "design methodology" instead of performance. Some people use hcells as a means of enforcing a design methodology where hundreds or thousands of cells with the same name in the layout and source are expected to match at the cell level. The "-automatch" switch, or an exhaustive hcell list of practically all the layout and source cells may be used for this method. It's not necessarily best for performance, and can lead to nuisance errors in many cases, but many people use this method. I would be interested to hear your opinions related to this method.


      A third technique begins with listing all the standard cells, and adding certain other cells based on some criteria. I presume that familiarity with the design is necessary for this method. I haven't used this method myself so I'm a little vague on the details. If you have had good or bad experiences with this third method, please share.


      I have often wondered if Calibre could offer a simple and automatic hcell selection option that gives optimum performance, avoids false errors and promotes easy debug. Maybe our collective discussions will lead to the answer.




      I will collect and summarize replies for this thread into a document we can refer to. Here's a link to that document: HCELL selection methods

        • 1. Re: HCELL selection for LVS

          Well, if parasitic extraction of a standard cell design is needed, your

          hcell/xcell list will need to contain all of your standard cells. This tells

          LVS and Extraction that these cells must match.


          In a Standard Cell design, the parasitics internal to each Cell is included

          in the library model.



          • 2. Re: HCELL selection for LVS


            Hi Chris,  My experience with -automatch was never very good. I tried it several times on various designs and technologies, but it would always guess incorrectly and caused me to waste time a lot of time trying to debug issues as the results misled me. It could be that my design styles were just never a good fit for automatching. I designed mixed signal designs with routed standard cells and full custom analog. Automatch would always try to find matches inside of my analog references.



            I really like the first technique you describe, but it does assume that one knows their design well enough to know what cells match the criteria you describe. It seems like it would be pretty easy to do some "up-front" processing of the layout and/or the source netlist to determine good HCELL candidates. From the layout perspective, some simple placement statistics could be a good first cut that could be refined for subsequent LVS jobs. I'm thinking of a simple DESIGNrev script to process the database for this information, has anyone come up with these automated HCELL selection methods?






            • 3. Re: HCELL selection for LVS


              Hi Chris,



              I made our default flow to use The "-automatch" switch with mild success.



              For our latest taped out design (semi-custom design with a mixture of memories, custom layout cells, and standard cell),  I only have to have 23 'LVS EXCLUDE HCELL' statements.



              The latest performance improvement has come from hyperScaling.



              Just my 2 cents.



              David Guan


















              • 4. Re: HCELL selection for LVS


                Hi Chris,



                We typically use -automatch until we get to the top level and some of the blocks at the top level of the chip. At that point layout designers will put together an HCELL file which reflects the layout hierarchy of the chip relative to how the schematic netlist is structured. Building the HCELL file does require detailed knowledge of the layout and schematic structure but we have found this gives the best results. I have experimented with automatically generating the HCELL file using the Calibre Query Server and it does work most of the time.



                I felt that the main advantage of using the Query Server was that it can determine a potentially better HCELL file that makes use of Calibre hierarchy optimizations. However, in the end, the time improvement was small compared to the big picture of chip completion which involved many different flows such as DRC/DFM/ANTENNA/ERC/LVS/LFD. The long pole in the tent is still typically getting the chip DRC clean considering that DRC now encompasses more than every before. LVS with hyperscaling on our current best hardware (4 3Ghz quad cores) takes less than an hour on one of our medium size chips.






                • 5. Re: HCELL selection for LVS



                  Thx for initiating this topic for discussion.   You state, "Any cell containing just a few devices, and then placed just a few times, would offer little value from the standpoint of performance."



                  From a methodology viewpoint for Calibre LVS, I find it easiest to simply include all 3rd party IP (stdcells, IOs, memories, etc.) in the hcell list.  (Kinda like roll call.)  But, does this hurt LVS performance?



                  In other words, does listing those cells which contain just a few devices placed just a few times actually add to runtime and/or increase memory usage, ... as compared to limiting the no. of entries in the hcell list to cells with a large no. of devices that are placed multiple times?

                  • 6. Re: HCELL selection for LVS


                    Hi Michael,



                    I'm glad to see interest in this thread from so many people. Thanks to you and everyone else that is contributing. I appreciate all the input.



                    I think the question of performance (as affected by a large number of hcells) has two parts... One being "connectivity extraction" and the other being "LVS comparison".



                    The connectivity extraction side of things is triggered by the "-spice" switch for instance and only applies when the hierarchical LVS is starting from a graphical layout database such as gds or oasis. During this phase, having too many hcells can hurt performance because they prevent Calibre from manipulating the hierarchy even when that may be better for performance. This is data dependent. Some chips may not suffer at all while other chips may experience a very noticable performance problem.



                    LVS comparison (as from netlists after the connectivity extraction phase is completed) seems not to be negatively impacted (in my experience) from the extra hcells. If someone has seen different then let us know!



                    This seems to be something where there isn't one best answer for everyone. At least by comparing notes we can all have a better chance to make informed decisions and also have alternatives ready in case of difficulty.



                    Thanks again everyone for your thoughts,




                    • 7. Re: HCELL selection for LVS


                      We are using hcell for LVS during XRC extraction. Because of the extraction of WPE paramters, the MOS devices are promoted to the upper



                      level, and H-LVS can be failed. How to solve this problem?



                      Thank you.



                      Jianming Chen



                      PMC Sierra.






                      • 8. Re: HCELL selection for LVS


                        Hi Jianming, Karen has much more xRC experience than I do. I think she is going to give us some good input on this. Glad you brought it up.




                        • 9. Re: HCELL selection for LVS

                          Hi Jianming. Have you tried using LVS PUSH DEVICES SEPARATE PROPERTIES before? This command specifies whether hierarchical device recognition should attempt to recover from seed promotion situations by pushing promoted devices back down the hierarchy. Seed promotion is an internal process used to assist device classification in a hierarchical structure by pushing seed polygons up the hierarchy. (Seed polygons are polygons on the *device_layer *parameter in the Device operation.) Reversing this process is called device pushdown.


                          Device pushdown causes equivalent, promoted devices to be pushed down the hierarchy as low as possible, but never below the level where the original seed polygon resides. Devices that are equivalent typically have the same component type, subtype, properties, and property values. Such devices are candidates for pushdown, which occurs by default.



                          Let me know if this helps with your testcase.






                          • 10. Re: HCELL selection for LVS


                            I will try the LVS PUSH DEVICE. Thank you Karen.












                            • 11. Re: HCELL selection for LVS

                              This is actually on HCELL for DRC.


                              I just went through 4 days of intense debugging to figure out why my full chip run (drc or lvs) went from 3 hours to over 30 hours.



                              On my chip, there are 3 major P&R blocks, (mpq, mpq_c and mpq_lite).  None of them were speficied as HCELL for DRC runs.




                              (As I said before, our LVS run has -automatch, and so they match.)




                              mpq is instantiated 4 times, mpq_lite 4 times and mpq_c is instantiated 2 times.




                              Somehow, Calibre starts to only keep mpq, and no longer keeps mpq_c and mpq_lite. This made:





                              053008h/chip/griffin/ml_only_BB/griffin.drclog:M1 (HIER TYP=1 CFG=3 HGC= 3996226 FGC=862771473 HEC=19578971 FEC=4814974926 VHC=F VPC=F)

                              060411h/chip/griffin/ml_only_BB/griffin.drclog:M1 (HIER TYP=1 CFG=3 HGC=11282260 FGC=862339405 HEC=54953746 FEC=4812770923 VHC=F VPC=F)





                              A 3x increase in HGC which in turn results in over 10x increase of run time.





                              I did not know HCELL statement had that much impact on DRC jobs. It still mystifies me though.





                              I tried both 2007.4 and 2008.2 released on 6/24.










                              PS: breath easier now ...

                              • 12. Re: HCELL selection for LVS

                                Hi David, I want to look into this further. It's an important issue and I would like to do what I can to save time and frustration for you and other users in the future. It might take me a few days to come up with a good plan and response but I'll work on it.


                                Thanks for bringing this up.



                                • 13. Re: HCELL selection for LVS


                                  Hi All,



                                  When we generate Hcell list using query server, we are talking about the % savings in memory if we use these cells as hcells. Can someone please eloborate on % memory savings and how we calculate % memory savings for each cell.



                                  Looking forward to this discussion.






                                  • 14. Re: HCELL selection for LVS


                                    Hi Satish,



                                    For a simple example, I wonder about a layout that is created from just two placements of the same cell (and nothing else). If that lower level cell had 1 million transistors, and the cell was placed two times, the top level would have two million transistors during an LVS with no HCELLs. If that lower level cell were declared as an HCELL, then the top level would have just two devices (the HCELL placed twice) while the HCELL itself has 1 million devices. So for this simple case, the HCELL could be estimated to provide 50% memory savings because approximately one million devices were checked, instead of two million.



                                    I hope my understanding is accurate, though drastically simplified. I wonder if anybody else has other perspectives on this?






                                    1 2 First Previous