This seems to be a popular topic and I hope we can hear about different experiences and perspectives from other people besides me, but I would like to offer one perspective to help with the discussion.
Many people recommend against running -automatch for LVS. You may find it very difficult to second-guess the extraction tool to get a clean run easily with -automatch.
Do you mind if I ask why you want to use -automatch?
>Do you mind if I ask why you want to use -automatch?
Our verification methodology is driven by the CAD department
I work on large RF/Analog IPs, which is handed off to the digital P&R guys, who put together the entire chip.
I am new to SupportNet, do you have a verification recommendation style?
I hope other LVS users can comment on different styles and their experiences that lead to choice of verification style.
LVS comparison based on -automatch is a style that may be easiest to start with but also most prone to nuisance problems.
If I knew why the CAD department desires -automatch, I would be interested to see if I could recommend an alternative to meet their needs that will cause fewer nuisance problems for you.
Working through nuisances from -automatch might be more frustrating than changing to a different methodology.
Many people recommend using a fairly small list of hcells that truly offer hierarchical benefit. There is an hcell selection tool available in the Calibre query server and Calibre Interactive GUI. That tool can be used to find the cells that will really make a difference in performance, rather than just using all cells in the design.
If you have to use -automatch for some reason, you might check to see if you are also using LVS EXPAND SEED PROMOTIONS YES.
If you are seeing lots of seed promotion, then you might want to check to see if you are calculating certain properties unnecessarily. Properties such as AS/AD/PS/PD or any other properties that are likely to be different from one placement of a device to another can cause alot of seed promotion. If you truly need those properties then you might consider using LVS PUSH DEVICES SEPARATE PROPERTIES so that they aren't so problematic during LVS.
I was reading through one of your appNotes, which is very good at:
It seems that there are some polygons that are defined as "seeds" somewhere in the rule file. And these seeds are used to indentify devices. And in certain situations as documented in the AppNote, these seeds will be promoted "up" in the hierarchy to form properly. So it seems that seed promotion, when it occurs, always means pushing the devices up in the hierarchy. And should that be at a different level than your schematic, the device "push down" capability will bring the devices back down in the hierarchy to correct this.
1 of 1 people found this helpful
Thanks for pointing to that AppNote, it's great.
Upon re-reading your original post, something struck me that we haven't discussed yet. You mentioned how decoupling caps at the top level could end up in a cell as extra devices. This is one of the things that an hcell list would solve... If the cell was listed as an hcell then Calibre should not have pushed the decoupling caps into it and they shouldn't have appeared as extra devices.
I know the cell was purposely not listed as an hcell because you were using automatch but I wanted to point that out as an example of how automatch can become a nuisance during LVS comparison.
>If the cell was listed as an hcell then Calibre should not have pushed the decoupling caps into it and they shouldn't have appeared as extra devices.
This is an excellent point, and I will keep this in mind for next time.
So I think I am starting to understand more. Is my previous post accurate about the "seed promotion" always meaning, when it occurs, that the device is pushed higher in the hierarchy and the "push down" pushes it back down?
Additionally, I have also seen when I have an instantiated cell (call it CELLA) with two pins (call them A and B). And those two pins get shorted one level higher (call that level TOP). And let's say those shape pins are in Metal 6. And then at the TOP level there is a Metal 6 rectangle that shorts them together. What happened with I ran hierarchical lvs with the automatch (no Hcell list), is that it said that the CELLA was lvs incorrect because two pins were shorted. The reason it seemed this occured seemed to be because the Metal 6 rectangle at the TOP level was placed over the instance of CELLA, so it seemed to "push down" that Metal6 rectangle when running Calibre LVS.. The way I corrected it I believe was to edit the TOP cell and move the metal6 rectangle (that shorts pins together) off of the CELLA, and short it to the side of CELLA. Could you comment on this? And perhaps I can do a search for an AppNote, although I am not sure where this behavior is covered.
Thanks for the input and feedback
> The reason it seemed this occured seemed to be because the Metal 6 rectangle at the TOP level was placed over the instance of CELLA, so it seemed to "push down" that Metal6 rectangle when running Calibre LVS.
I think this may benefit from the same idea as above. If CELLA was listed as an hcell then the metal may not have been pushed.
This may be another example of how -automatch can be a nuisance for comparison while an hcell list can make things go more smoothly.
> Is my previous post accurate about the "seed promotion" always meaning, when it occurs, that the device is pushed higher in the hierarchy and the "push down" pushes it back down?
I agree. For Calibre commands and messages, seed promotion always means up while pushing always means down.
I have gotten some clarification on this issue. The boss's preference is to not use hcell if at all possible, but the boss will allow it, if it can not be fixed otherwise.
ALSO, I have a question on the hcell list. Someone above me said that the hcell does not affect the pushing/pulling and lvs extraction stage (spice netlist creation), but only affected as to which cells get compared. However, reading an earlier post, the hcell does seem to affect the extraction stage and subsequent spice netlist generation. Could you please clarify?
> the hcell does seem to affect the extraction stage and subsequent spice netlist generation. Could you please clarify?
Yes, the hcell list is applied during extraction as well as comparison but in a very different way. This may have been what the other advisor had in mind. The hcell list tells hierarchical comparison which cells to match to one another but that sort of idea doesn't apply during extraction. A smaller hcell list is better than a large hcell list because the hcells are protected from hierarchical optimization during extraction. Worst case would be to list every cell as an hcell. This would prevent Calibre from using hierarchical optimization on every cell.
It's not so much that the list needs to be arbitrarily small, rather it's best to have a list of cells that truly make sense to be used as an hcell. Some cell that is small and used only one time is not likely to be very helpful as an hcell. A cell with hundreds or thousands of devices, that is placed many times is a much better example of a cell that is likely to be a good choice. From this perspective It's all about performance. A well chosen hcell list helps performance during extraction because you allow Calibre to hierarchically optimize the highest practical number of cells. A well chosen hcell list helps performance during comparison because it describes cells that will truly contribute to more efficiency by saving the most time during comparison, by taking advantage of repeated cells.
Hope that helps, and by the way thanks very much for contributing an answer to the other person's post regarding an LVS problem with capacitors and resistors having a leading X from Cadence. It's great to have company!
Is it okay to say that, roughly speaking, if the hcell is used along with the -spice option of Calibre, that the cells listed in the hcell will not be effected by the promotion and push-down, but would in a sense be closer to the layout view in Cadence. Or in other words, a cell listed in the hcell will not have its devices being pushed up a level, OR devices one level above will not be brought into that cell.
And no problem with helping out in the forum. Most of the stuff, I am not able to answer, but when I login, I try to see if I can effectively take a question or two.
Thank you for your input.
Yes, I agree with the assessment, with one important exception.
Sometimes devices can not be legally formed in a cell and must be pushed up. For instance, if a property such as AS or AD were calculated for a device in a cell, and that cell is placed twice, and the property is different in each placement, then the device must be pushed up and out even if it is used in the hcell list. (LVS PUSH DEVICES SEPARATE PROPERTIES can usually help in a case like this).
So just to be as precise as possible, I might say that listing the cell in the hcell list prevents the pushing and promotion and hierarchical injection and selective flattening that are related to hierarchical database optimization but you might find a corner case here and there that might require a bit of investigation to find why something moved even if it was in the hcell list.
By the way, do you think all customers realize how desirable it is for them to contribute answers and opinions here in the Calibre Community forum? Or do you think there may be a mistaken impression that the answers are supposed to come mainly from Mentor folks? I like to talk about Calibre issues and discuss problems and solutions but I think it's much better when several people get involved and share different experiences and alternative solutions.
Thanks for the post..
As to answering your question at the bottom of your post -- I am not sure.
I suspect most people are aware that it is a community and all can contribute. I further suspect that a lot of people are pretty busy and focused in on accomplishing their own tasks, and are looking for help. Others that do contribute, outside of Mentor employees, are those who like a good puzzle. So they contribute for the fun of solving a new and interesting puzzle, so it is important for posters to reply after getting feedback as to the course of action they took and what happen. And others like the colloboration and help, and also try to provide some input back and help back, because they value the forum, and want to see it continue.
I ran into the same problem as the grand parent. I could not move the metal that connects pins A and B. I was wondering it is worth creating hcells. Since the called through several higher levels. Will each succeeding level need an hcell created? I use this cell anumber of times, do I need to create an hcell for each instantiation? Will other designers pick up the hcells automatically?
Thanks for your help,