Favorite method to calculate an estimated time for mask layout completion
- Thread starter RLHooper
- Start date
Daniel Payne
Moderator
Well, it depends on several factors:
- Type of schematic: Memory, digital logic, analog, IO pad, datapath, RF
- Technology node
- The chance of IP re-use
- Experience of the layout designer
- Use of EDA tools (i.e. Schematic-driven layout, compilers, generators, P-cells, etc.)
<!--[if gte mso 9]><xml> <w:WordDocument> <w:View>Normal</w:View> <w:Zoom>0</w:Zoom> <w
oNotOptimizeForBrowser/> </w:WordDocument> </xml><![endif]--> Hi Daniel,
I agree with your assessment.
It is very important for a company to know when a product will be out the door
or in the case of R&D brought into "tape out" mode.
So how does one answer the question posed?
How do you specifically go about go about this issue at your company?
What is the basic process that you use to determine how long it will take to get the layout done for a schematic?
My experience tells me the answer to this question is that IT DEPENDS.
It depends on whom you ask, just like you indicated
It depends on the "Experience of the layout designer"
It depends of if the standard leaf cells and Pcells are already created.
It depends on if it can be automatically routed or must be routed by hand.
It depends on the process you are using and how ready the process flow is.
That is the Floor plan and DRC / LVS May still need some tweaks.
Etc.
It depends on a lot of things.
Then I got to thinking perhaps someone out there has a general flow chart.
A flow chart that works for basic layout applications.
A good flow chart would be the key to answering this question.
Feel free to share your method.
Rick
oNotOptimizeForBrowser/> </w:WordDocument> </xml><![endif]--> Hi Daniel,I agree with your assessment.
It is very important for a company to know when a product will be out the door
or in the case of R&D brought into "tape out" mode.
So how does one answer the question posed?
How do you specifically go about go about this issue at your company?
What is the basic process that you use to determine how long it will take to get the layout done for a schematic?
My experience tells me the answer to this question is that IT DEPENDS.
It depends on whom you ask, just like you indicated
It depends on the "Experience of the layout designer"
It depends of if the standard leaf cells and Pcells are already created.
It depends on if it can be automatically routed or must be routed by hand.
It depends on the process you are using and how ready the process flow is.
That is the Floor plan and DRC / LVS May still need some tweaks.
Etc.
It depends on a lot of things.
Then I got to thinking perhaps someone out there has a general flow chart.
A flow chart that works for basic layout applications.
A good flow chart would be the key to answering this question.
Feel free to share your method.
Rick
Yes definitely things like schematic changes and process changes can cause delays.
I am looking for a first pass method or flow chart for the timing a layout cell build from a schematic.
Bill Martin
Member
As Daniel mentioned, many factors determine how long it will take for tape out.
Of all the ones mentioned, the experience of the team developing the design is probably the most important. This experience is not only technical (functionality, how to perform synthesis, how to floorplan/route, etc) but the learning cycles for a given process node. Each node has its own learning curve. While at VLSI Tech, we honed the methodology and as we worked with each customer, we understood strengths and weaknesses of their teams. This allowed us to add some safe guards to minimize complete respins but the best predictor was the team's previous performance. Migrating from one process node to another usually allowed 2X density but also required either 2X time or 2X staff to complete with same schedule.
If the design was a derivative, it depended on how much of the old design (including floorplan) could be used on next generation products.
Good luck but the team owning the implementation probably has the best understanding to provide a schedule.
Of all the ones mentioned, the experience of the team developing the design is probably the most important. This experience is not only technical (functionality, how to perform synthesis, how to floorplan/route, etc) but the learning cycles for a given process node. Each node has its own learning curve. While at VLSI Tech, we honed the methodology and as we worked with each customer, we understood strengths and weaknesses of their teams. This allowed us to add some safe guards to minimize complete respins but the best predictor was the team's previous performance. Migrating from one process node to another usually allowed 2X density but also required either 2X time or 2X staff to complete with same schedule.
If the design was a derivative, it depended on how much of the old design (including floorplan) could be used on next generation products.
Good luck but the team owning the implementation probably has the best understanding to provide a schedule.
As has been said, the calculation is dependent on many factors, the type of block being designed, the size and number of transistors, the automation tools such as pcells and routers. It can be calculated but only by using empirical data. One of the measurements used is number of transistors per hour, a client tracked this for several designs and developed an estimate for the different blocks. They could calculate the number of transistors based on the gates in the schematic and, based on the feedback from the LVS and DRC run logs, figure the time it took to get the block completed. After they had gathered this data for several chips, they used it to estimate the layout time fairly accurately, track the layout designers' productivity and identify engineering changes which caused the greatest impact. They understood that a small engineering change could reek havoc with the schedule and didn't blame the layout designers for every schedule slip.
Bill Martin
Member
physical layout
Daniel hit it correctly by the type of silicon design you are designing. Designing and laying out a memory or analog/mixed signal design is much more complex than 'digital' logic.
If you are just using an IP block (memory or A/MS), there might be some layout integration guidelines that must be followed but the majority of the complex issues have already
been resolved by the original design team. Just ask any team that creates SERDES IP that is contained in any PHY how easy this is from a design or implementation perspective.
Especially after they have taken their product to any USB, PCI Ex, SATA, XAUI certification lab for exhaustive testing. Or memory teams that must ensure that Vbump, or nearby
bits do not affect each other or alpha sensitivity, etc. Bit cells along with their row/column logic is non trivial to design for the various environments that they must work in.
To my it depends on the hierarchy of the schematic, it is not really related to the kind of products.
Deeper hierarchy = faster layout and iterations.
That's why I always think that you don't need more layouters but a good hierarchy (and floorplan)
Daniel hit it correctly by the type of silicon design you are designing. Designing and laying out a memory or analog/mixed signal design is much more complex than 'digital' logic.
If you are just using an IP block (memory or A/MS), there might be some layout integration guidelines that must be followed but the majority of the complex issues have already
been resolved by the original design team. Just ask any team that creates SERDES IP that is contained in any PHY how easy this is from a design or implementation perspective.
Especially after they have taken their product to any USB, PCI Ex, SATA, XAUI certification lab for exhaustive testing. Or memory teams that must ensure that Vbump, or nearby
bits do not affect each other or alpha sensitivity, etc. Bit cells along with their row/column logic is non trivial to design for the various environments that they must work in.