On line Design Rule Checking (DRC) is nothing new. The technology has been in use for years in a variety of different layout editors and yet nearly every Layout engineer has a love / hate relationship with it. Why? Well it really comes down to the use model and the responsiveness of the application.

At the beginning of the design process, layout engineers love on line DRC. But as the design progresses the relationship begins to sour. The problem is that as the layout gets bigger and more complex the performance invariably starts to fall off until it reaches a point where it becomes unacceptable and the layout engineer simply turns it off and resorts to running the occasional batch checks.

To really be effective, on line DRC has to be an interactive tool that is run often during the layout process, so as such it needs to have a simple use model and have a fast response. The engine needs to be ‘built in’ to deliver the required performance and the feedback needs to be comprehensive enough to enable the layout engineer to quickly fix the violation.

Custom Compiler’s In-Design assistants have been architected with both performance and use model in mind. The use model is simple. Whatever is visible in the active viewport is what gets checked. That way the layout engineer can easily control which portions of the design are being checked. In addition the In-Design assistant has a GUI to control which type of checks you want to do and also lets the layout engineer setup a group of checks and save them off in for future reuse. For example the layout engineer can save off a set of checks for Poly and another set for metals. The built in DRC engine is lightweight and extremely fast with results delivered in seconds.

Violations are viewed via an error viewer and the layout engineer can simply select which type of violation they want to view in more detail. Details of the type of violation and the objects associated with it are displayed in the Marker index panel. When an object associated with that violation is selected from that panel the error viewer automatically zooms to the error marker in the layout window. Holding the cursor over the marker in the layout window also gives the layout engineer details of the violation using the actual description of the violation that was specified in the rules file. Displaying the information in this way makes it easy to determine what to do to fix the violation. Figure (1) shows the violation marker and details of the metal violation.

Figure (1) violation marker and details of the metal violation

Custom Compilers’ In-Design Assistant for DRC is a fast simple to use checker that can be easily customized to check different rule categories and when used interactively during the layout process catches errors that can be quickly fixed while the design is evolving versus waiting for a batch DRC run to complete. Layout engineers love it.

Check out this video link to see the In-Design Assistant Design Rule Checking in action.

http://www.synopsys.com/Tools/Implementation/CustomImplementation/Pages/custom-compiler-webisodes.aspx

Register here for a webinar on Custom Compiler.

https://event.on24.com/eventRegistration/prereg/register.jsp?eventid=1164103&sessionid=1&key=A22830ADCEAF97FC2377CA08BC24B737&partnerref=CC-blog

Next we will take a look at another In-Design Assistant, but that’s another post.

Graham

In the last blog I detailed the symbolic editor layout assistant and showed how the layout engineer can make simple graphical choices of how the layout needs to look and then have the placement taken care of by a placement engine. In this post I will outline another layout assistant the router. The routing task is one that absolutely screams out for an automated approach however past efforts have required a great deal of text-based constraints to get anything near to what you really want.

The routing assistant is a perfect combination of user guidance and automation. It’s a visually assisted approach that allows the layout engineer to simply click on the starting point of the route and then drag the cursor in the direction they want the routing to follow. As the cursor moves along, under the hood the routing engine searches for connections that it can make. When it finds a connection it automatically taps to the pin without the layout engineer having to enter a mouse click. The user simply guides the router with the mouse and it fills in the routing details automatically.

The router is especially good for routing up arrays of FinFETs. FinFET designs have masses of identical common connections and the router understands that. So as it routes it clones the connections it has just completed to other parts of the layout. As connections are made in one part of the layout you see them also appear in other areas of the layout that require an identical hook up.

Figure (1) Interactive routing with automatic cloning and pin tapping.

Figure (1) shows the router connecting up the gates of an interdigitated fully matched differential pair. The yellow flightline shows the starting point of the route and the current cursor position. The router has automatically tapped to the pins and has cloned the routing to the devices in the rows below.

For FinFET based designs the router also ensures that all the routing adheres to the correct coloring rules and metal grids. The fact that you can see the routing appear in real time as you move the cursor, gives immediate feedback to the layout engineer as to the style of routing that is being generated and allows them to make changes on the fly. The router has some options for the style of connections you want to make, such as a fishbone style for routing in between rows where the connections can tap up or down to the pins but apart from that there are virtually no constraints to enter, no code to write and layout is done in minutes versus hours.

This powerful combination of user guidance and automatic routing really delivers on reclaiming the custom layout productivity loss that you incur when adopting a FinFET process.

Check out this video link to see the router in action.

https://event.on24.com/eventRegistration/prereg/register.jsp?eventid=1183786&sessionid=1&key=BAF1B1A007D9061280328E21093A914F

Register here for a webinar on Custom Compiler.

https://event.on24.com/eventRegistration/prereg/register.jsp?eventid=1164103&sessionid=1&key=A22830ADCEAF97FC2377CA08BC24B737&partnerref=CC-blog

Next we will take a look at another layout assistant, but that’s another post.

Graham

On March 30^th Silicon Valley was buzzing with excitement. Synopsys held the Silicon Valley SNUG event and revealed Custom Compiler, a fresh approach to custom design that employs visually-assisted automation technologies to speed up common design tasks, reduce iterations and enable reuse. During the event the R&D folks did a walkthrough of the technology ‘under the hood’ and showed the audience some cool layout assistants that leverage the graphical use model familiar to layout designers while eliminating the need to write complicated code and constraints.

One of the layout assistants that was shown was the symbolic editor. This really is a must have assistant when it comes to placing devices that need to be in a specific interdigitated pattern like for example a differential pair. In the schematic it is two symbols but in the layout it could be hundreds of devices. The symbolic editor allows device placement to be edited in an easy and graphical manner and comes with a rich collection of pre-defined placement patterns. If you find a placement pattern you like you can simply use it as is and the symbolic editor will generate a correct by construction placement that you can instantiate in you layout. If you don’t find an exact match you can easily use a pattern that is similar to what you need and rearrange the placement pattern graphically. No constraints to enter, no code to write and layout is done in minutes versus hours.

Example of patterns for a differential pair

Through the symbolic editor the layout engineer can make simple graphical choices of how the layout needs to look and then have the placement taken care of by the placement engine. You can easily add or remove placement rows and columns as well as insert dummy devices. The symbolic editor also supports device merging and splitting and is the fastest way to achieving correct layout. The symbolic editor is particularly well suited for FinFET based designs and is equally as good on planar CMOS nodes. Generating the devices and placing them such that they meet all the design rules and will produce a robust working design is about 30% of the layout time. Using a layout assistant like the symbolic editor really speeds this task up and allows the layout engineer to gain back some of the productivity that gets lost due to the complexity of the FinFET process.

Check out this video link to see the symbolic editor in action. https://event.on24.com/eventRegistration/prereg/register.jsp?eventid=1174158&sessionid=1&key=9B4BF1C7C70DED536D0B0902F844074E

Register here for a webinar on Custom Compiler.

https://event.on24.com/eventRegistration/prereg/register.jsp?eventid=1164103&sessionid=1&key=A22830ADCEAF97FC2377CA08BC24B737&partnerref=CC-blog

Next we will take a look at another layout assistant, but that’s another post.

Graham

The wait is over!

Remember the last few blogs where I was outlining the kind of tools you really need to tackle FinFET? Well they are here right now, because today Synopsys unveiled Custom Compiler and ushered in a new era of Visually-assisted Automation. Check out this link: http://www.customcompiler.info

It’s all the good stuff I was alluding to in prior posts, a new custom design solution that closes the FinFET productivity gap by shortening custom design tasks from days to hours.

This is not a revamp of the old constraint-based legacy approach, it’s a fresh approach to custom design that employs visually-assisted automation technologies to speed up common design tasks, reduce iterations and enable reuse. What’s Visually-assisted Automation you may ask?

Well, Visually-assisted Automation is the collective term we use for a set of productivity aids that leverage the graphical use model familiar to layout designers while eliminating the need to write complicated code and constraints. The job of the assistants is to deal with routine and repetitive tasks automatically without extra setup. Custom Compiler provides four types of assistants: Layout, In-Design, Template and Co-Design. For now here’s quick outline of each assistant. I will talk about these in more detail in my next series of posts.

Layout Assistants speed layout with visually-guided automation of custom device placement and routing. The router is ideal for connecting FinFET arrays or large-M factor transistors. It automatically clones connections and creates pin taps. The user simply guides the router with the mouse and it fills in the details automatically. The placer uses a new innovative approach to device placement. It allows the user to make successive refinements, offering placement choices but leaving the layout designer in full control of the results—without requiring any up-front textual constraint entry.

In-Design Assistants reduce costly design iterations by catching physical and electrical errors before signoff verification. Custom Compiler includes a built-in design rule checking (DRC) engine, which is extremely fast and can be active all the time. In addition to the DRC engine, electromigration checking, and resistance and capacitance extraction are all natively implemented in Custom Compiler. Unlike other “electrically-aware” tools, Custom Compiler’s extraction is based on Synopsys’ gold-standard StarRC™ engine.

Template Assistants help designers reuse existing know-how by making it easy to apply previous layout decisions to new designs. Template Assistants actually learn from the work done with the Layout Assistant’s custom device placer and router. They intelligently recognize circuits that are similar to ones that were already completed and enable users to apply the same placement and routing pattern as a template to the new circuits. Custom Compiler comes pre-loaded with a set of built-in templates for commonly used circuits, such as current mirrors, level shifters and differential pairs.

Co-Design Assistants combine IC Compiler™ and Custom Compiler into a unified solution for custom and digital implementation. Users can freely move back and forth between Custom Compiler and IC Compiler, using the commands of each to successively refine their designs.  With the Co-Design Assistants, IC Compiler users can perform full custom edits to their digital designs at any stage of implementation. Likewise, Custom Compiler users can use IC Compiler to implement digital blocks in their custom designs. The lossless, multi-roundtrip capability of the Co-Design Assistants ensures that all changes are synchronized across both the digital and custom databases.

This is really exciting stuff and you can see it in action today at the Silicon Valley SNUG. So get yourselves along there and hear from customers and our R&D teams about Custom Compiler.

Oh and don’t forget to check back here for more details.

Graham

In the last of blog we outlined the kind of tool that the layout engineer needs in order to get a good placement that delivers robust working silicon within the confines of the FinFET process. We concluded that a guided / interactive approach that is fast and easy to refine such that you do get the result you want is the way to go.

So where else can we look for more efficiency during layout? Well once you have placed your devices the next step is to route up all the connections that cannot be completed by simple abutment. Again, because you could be dealing with hundreds of devices (remember the differential pair example? Click here to link to the article) the routing task is one that absolutely screams out for an automatic approach and there have been lots of efforts at automating custom routing in the past.

The downside with past custom routing solutions is that they require you to enter a lot of text-based constraints to get anything near to what you really want. Sure you need some level of constraints to tell the router which layers are valid and which direction they can route in. And of course, you do need to tell the router what the DRC rules are. But, you should not have to spend precious layout time teaching a router what to do for your particular layout topology only to find it does not give you exactly what you want and you have to go edit the results anyway.

So where does that leave us? Well I firmly believe that the guided / interactive approach is the best way to quickly converge on the routing style you need. But we could have hundreds of devices you may say. Are we going to have to do all the connections one by one?  Well, if you have the right kind of router the answer is no, you won’t have to do them one by one.

What’s required is the kind of router that allows you to simply click on the starting point for the route and drag the cursor in the direction you want the route to go.  An ideal router would automatically handle the connections to the array of FinFETs including any common routing and the end result would also adhere to the correct coloring rules and metal grids. This approach would not be just pretty cool; it would also give the layout engineer control of what the route looks like and would take the tedium out of having to do the connections one by one. Because the feedback would be visual (you would see the routing appearing and in real time) the layout engineer would be able to make informed decisions as to whether to keep the current routing topology or change it to a different style.

This powerful combination of user guidance and automatic routing would be another surefire way to reclaim custom layout productivity. And there is more.

But that’s another post.

Graham

Over the last series of blogs we have looked at what tools the layout engineer has available to him/her to help them deal with the complexity of doing layout with FinFETs. Even though there are tools that help, the fact is there is still a productivity hit when comparing the time it takes to do a FinFET based layout versus a planar CMOS layout. When I asked my layout colleagues “how much longer does it take to do a FinFET based design versus planar CMOS?” they said it takes 2-3X more time.

So if we are to recoup layout productivity when doing a FinFET based design, which areas should we focus on? Well let’s start at the very beginning, which according to Julie Andrews in The Sound of Music, is a very good place to start. The task of generating the devices and placing them such that they meet all the design rules and will produce a robust working design is about 30% of the layout time. So if we can speed this task up then we will gain back some of the productivity we lost due to the complexity of the FinFET process.

Because one device in the schematic can translate to hundreds of devices in the layout, the layout engineer needs a fast yet simple way to generate the device and get the individual transistors grouped together such that the device will work properly and adheres to the strict layout dependent rules that the FinFET process requires. Take a differential pair for example. In the schematic it is two symbols but in the layout it could be hundreds of devices. To ensure good analog layout that will work it is typical for these devices to be interdigitated in a specific pattern. Doing this by hand is a time consuming tedious and error prone task. This is where you need some automation. Not the ‘push the button’ and see what I get kind of automation, but a guided / interactive approach that is fast and easy to refine such that you get the result you want. This approach is especially important when implementing ECO changes.

Having the layout engineer make simple graphical choices of how the layout needs to look and then having the placement taken care of by the placement engine is the fastest way to achieving correct layout. Using this user guided interactive approach cuts the layout time from hours to minutes.

So where else can we look to claw back some layout productivity?

Well that’s another post.

Graham

What is Electro-migration and why is it something we should care about?

Here’s the definition of Electro-migration from Wikipedia: “Electro-migration is the transport of material caused by the gradual movement of the ions in a conductor due to the momentum transfer between conducting electrons and diffusing metal atoms.”

Put simply, when the current density gets too high for a given wire width, you get problems. These problems manifest themselves in two ways, either a void in the metal wire that creates an open circuit or a hillock that creates a short to another wire. Either way your chip fails. Electro-migration is made worse by temperature and mechanical stresses.

Electro-migration in the FinFET process is now a first order effect and has a huge impact on the Mean Time To Failure (MTTF) of a metal wire. So as you can imagine to ensure you have a robust design that will last, great care has to be taken when choosing wire widths for interconnect and power grids.

So what tools do we have to help us in determining the correct wire widths for our interconnect?

There are a variety of tools that will help you check on EM compliance. They range from full blown ‘sign off’ tools to fast static checkers that can be run whilst doing the custom physical layout.

For sign off, Synopsys’s CustomSim can calculate current densities in narrow signal nets to determine their susceptibility to EM. Bidirectional current flow is correctly considered, including calculation of the RMS currents required for monitoring Joule heating within the design. CustomSim can also include all of the design’s extracted coupling capacitors in addition to the grounded capacitors. This provides a high level of precision in determining the current entering or leaving segments of signal net interconnect, enhancing the quality of results. The results are presented as GDSII files which can be overlaid on the design for visualization of the errors.

For the layout engineer, having the ability to run a fast static check interactively during layout is an easy way to catch errors up front. To run EM checks you need to set up the design with the sheet resistance models for the individual layers. The data for these models comes from the Interconnect Technology File (ITF) that is delivered as part of the iPDK. Once that data is processed you then set up the current density constraints and the current values on the ports and pins of blocks and devices. The current values can be average, peak and RMS. Now with this information at hand any net you route to these pins can be checked for EM compliance. To run an EM check you simply select the routed net of interest and invoke the checker. Any EM errors are flagged in the layout with a blinking error marker and an error browser gives detailed information on the type of error and how to fix it.

This is a fast and easy way to ensure EM compliance whilst implementing the layout.

So there we have it. Yes FinFET is complex and there are lots of rules and regulations that you have to abide by to ensure a robust and functioning design. But help is at hand and as we have discussed in these last few posts, the layout engineer can call on a good number of tools to help automate the physical layout process.

So the next question is do we need more automation? What do the layout engineers really want?

Well that’s another post.

Graham

PCells for custom layout have been a ‘no brainer’ for decades. They have done all the heavy lifting with respect to generating correct by construction layout and are the most important ‘power’ tool for custom layout engineers. Now however, given the complexity of the FinFET process, they become absolutely vital.

Generating a FinFET device is easy when you have a PCell. When coded correctly, it will automatically generate the device such that the fins are properly spaced on the requisite ‘fin grid’ and that all the rules for Poly width/length, Diffusion width/length, Poly cuts and the like are adhered to. In addition to constructing the device design rule correct, the PCell will also ensure that the metals in the device are colored correctly and abide by the color related rules. As you can imagine, there is a lot of stuff going on in a FinFET PCell, but there is more. FinFET PCells have to be ‘smarter than the average PCell’ and they have to be in tune with the layout methodology.

So what’s so different about the layout methodology for FinFET? Well first and foremost, the layout methodology for FinFET is geared around ensuring that the design is routable. There is no point in having a correct by construction device if when you place it, it can’t be routed to.  Remember my previous post ‘Hurricane FinFET – part 3’ when I was talking about the fact that although the pitch for the base layers has shrunk considerably the metal pitch has not shrunk as much? Well that’s been done deliberately to make sure that there is sufficient space to make the design routable.

Routability is paramount such that it becomes the first rule of placement. So how do we go about placing a device such that it is routable and also meets the rules for ‘fin grid’ spacing? Well it’s simply a matter of ‘metal grids’, ‘fin grids’ and ‘smart’ FinFET PCells.
The ‘fin grids’ are defined in the process technology file which is delivered as part of the Interoperable Process Design Kit (iPDK) from the foundry. The ‘metal grids’ are defined by the layout methodology and the type of design you are doing, e.g. memory, serdes, DDR, etc… When you open up your layout editor and point to a specific iPDK the tool automatically generates the requisite ’metal grids’ and ‘fin grid’. These grids can be displayed and the display can be toggled on and off. So now you have a visual aid as to where to place your FinFET PCell. However, the last thing you want to be doing is zooming in and out to see where to place your device. That’s where the ‘smart’ FinFET PCell comes in.

The PCell is coded such that when the device is placed the layout tool snaps the metal contact in the device to the nearest appropriate ‘metal grid’. This ensures that you can connect to the cell on that metal layer and you don’t need to zoom in to get a correct placement. Although we now have a device that we can route to, we don’t necessarily have a manufacturable design. You see the PCells are coded in isolation and have no knowledge of the spacing between ‘metal grids’ and ‘fin grid’ in the layout. That’s because the grid is not always a uniform grid. This means that you can end up with the fins in the device not aligning with the ‘fin grid’. To overcome this a  ‘call back’ is triggered to snap the diffusion to the ‘fin grid’ so that the design is both DRC clean and routable.

So, let’s recap. We can use schematic PCells to deal with the mapping of one schematic device to potentially hundreds of physical devices and make parameter changes easy to incorporate. We can use ‘smart’ FinFET PCells to ensure we have a routable and manufacturable design. But what do we have to help us with Electromigration and density checks?

Well, that’s another post.

Graham

So, what tools do we have in our FinFET toolbox that can help layout engineers manage the complexity that FinFETs inherently bring?

Well for my money, the best and most powerful tool we have to tackle FinFET complexity is the good old parameterized cell or PCell. PCells are not new, they have been around since the CALMA GDS days and along with Schematic Driven Layout, have been instrumental in boosting layout productivity as I have mentioned in my previous posts. PCells have typically been used to generate physical layout of pretty much all the devices needed for custom layout, from resistors to inductors, capacitors and of course the transistor. That is still the case for FinFET designs; however the role of the PCell has now been expanded to include the Schematic PCell.

So what’s the big deal about a schematic PCell you might ask? And why didn’t we have them before?

Well some companies did use schematic PCells, but mainly to generate symbols. With FinFET there are a lot more reasons that a schematic PCell should be used. It boils down to three things, complexity, aesthetics and productivity.

First off let’s tackle complexity. Because of the very restricted rules for W and L in the FinFET process, it becomes necessary to create arrays of ‘legal’ transistors and stack them connected in series and parallel to generate your desired W and L. In effect this means that a single transistor symbol in the schematic can map to tens or even hundreds of transistors in the physical layout as in Figure – 1.

Figure – 1

The nice thing about the schematic PCell is that it will automatically create a sub-circuit of this array, instantiate the symbols and make all the necessary connections for you.

Second is aesthetics. A single symbol in the schematic is easy to understand, takes up less room and is easy to see and select. It keeps the top level of the schematic neat and uncluttered. Yes, you could accomplish the same with a sub-circuit one level down in the hierarchy but what if there are changes required.

That brings me to the third point of productivity. Let’s say you need to change either the W or L of a transistor. Well it’s very easy to simply select one schematic symbol and change a parameter and have the PCell re-generate the sub-circuit with the required changes, than it is to have to descend in the hierarchy and edit the sub-circuit to reflect the changes.

So in my opinion schematic PCells are pretty much a ‘must have’ for FinFET.

PCells for layout have been a ‘no brainer’ for decades. They have done all the heavy lifting with respect to generating correct by construction layout and are the most important ‘power’ tool for custom layout engineers.

They become vital for FinFET for a whole variety of reasons, not least of which is dealing with ‘fin grids’.

But that’s another post.

Graham

So, what do you have to do for routing? Well again, drawing on the experience of my layout colleagues who are still ‘in the business’ and dealing with FinFETs, here are a few landmines you will have to deal with.

One particular issue they encounter is the fact that although the base layers have shrunk considerably, the shrink of the routing layers has not kept pace. Each new node has brought us smaller transistors but the minimum metal pitch has not really changed. This really impacts layout floor planning because designs that were once dictated by device area are now dictated by the ability to route the required signals. Double / triple patterning compounds the issue even further.

Planning which metal shape goes on which color (mask) is key, especially when propagating connections through the layout hierarchy. Highly matched signals such as complementary clocks must be assigned to the same color, as routes on different masks have different resistances. In addition designers now need to be aware of spacing rules for opposite-mask routes and same-mask routes whilst still meeting color density rules. And there’s more.

Strict rules for metal direction may also include a restriction on the ability to add a notch or a turn into the route. Couple that with limited metal width and via combinations and you have to rethink how you make a strong well connected route that meets reliability criteria. Topologies that were ok on planar nodes like in Figure 1 may now have to be redesigned as in Figure 2.

Figure 1 – multiple vias in a planar process.                                  Figure 2 – multiple vias in a FinFET process

And then there is the little matter of electro migration (EM). Because the resistivity of the lower level metals is much higher in a FinFET process, you have to be acutely aware of EM and IR drop. Care must be taken when planning which metals to use and in fact track planning becomes essential for a design to pass EM and IR checks.

So there we have it. Designing with a FinFET process is like a game of snakes and ladders. You need to roll the dice carefully and avoid the snakes whilst climbing the ladders to FinFET heaven.

So what tools and techniques do today’s designers have at their disposal to deal with FinFET?

Well there are quite a few.

But that’s another post.

 Graham