SpringSoft Verdi

Introduction to Verdi
http://www.ee.cycu.edu.tw/excellent/lab/book/Introduction%20to%20Verdi.ppt

Brief Introduction to EDA
http://140.113.87.143/course_web/96_2/Seminar/0423_Brief%20Introduction%20to%20EDA.pdf

Introduction to Challenges in System and SoC Debug
http://www.ocpip.org/pressroom/schedule/speaking/papers_presentations/DAC08_SoC-Debug_Keynote_Neal_Stollon.pps
(Not really about EDA or Verdi, but ICE/JTag related)
(There are some good architectural diagram)

Analog PDK 101
http://www.chipdesignmag.com/display.php?articleId=35&issueId=5

process design kit (PDK)

a foundry will provide designers in fabless companies with access to a PDK, the associated design libraries, and on-going applications engineering support. That PDK, coupled with software from various EDA providers, constitutes the basic design environment necessary to create an IC. Once the design is complete, GDSII files containing the IC’s electronic information are submitted to the foundry for reticle-build processing.

A technology file contains information for the EDA tools such as layer definitions, layer colors, and GDSII stream translation rules for a given process technology. Depending on the particular EDA vendor tool, the technology file may also contain process rules and associated information, as well as symbolic devices.

Device symbols obtained from the PDK are used to create schematic designs in a schematic-driven design flow. These symbols provide a graphical input for representing device terminal connectivity. Each device symbol contains fields for customizable properties such as width, length, and other parameters. Including proprietary computer code with the symbols will help enable more complicated resistance- and capacitance-based calculations.

The PDK includes information that allows the design to be netlisted. A netlist is a text-based representation of the connections and symbols in the schematic design.

A simulation consists of verifying the circuit design using a Spice simulator and foundry-provided models. Popular simulators currently in use include Hspice from Synopsys, Inc. (Mountain View, CA), Spectre from Cadence Design System, Inc. (San Jose, CA), Eldo from Mentor Graphics Corp. (Wilsonville, OR), SmartSpice from Silvaco International (Santa Clara, CA), and T-Spice from Tanner EDA (Pasadena, CA).

A schematic-driven layout (SDL) is generally part of the vendor’s tool suite, and takes advantage of correspondence between device symbols and device layouts. PDKs that use common names on devices, while their pins/terminals allow the physical design engineer to import all the devices, parameters, and connectivity found in the schematic netlist into the layout view as device layouts. This generated layout provides a correct-by-construction starting point, increasing the physical designer’s productivity.

Also included in the PDK, device layouts are used to establish a physical representation of the schematic design. Individual device layouts can be delivered in two formats. The simplest form of a device layout is a flat cell, which is the fixed physical layout of a device. This form allows accurate layout and modeling of devices, but is not conducive to scalability, which may limit design flexibility and the chip’s design density.

Additionally, in order to address scalability issues and enhance productivity, EDA vendors have introduced the parameterized cell (pcell) concept. Pcells allow devices to scale with specified parameters such as width and length, and also allow structural changes within the cell (for instance, the addition of contacts or changing the shape of a MOS gate). Some complex pcells require inclusion of additional code in the PDK.

Layout cells must be spaced according to design rules, and connected with metallization layers to match the connectivity of the established schematic design. In full-custom design, this procedure is implemented manually. Meanwhile, due to the manual nature of the construction, verification of this work is critical to the success of the chip design.

A key step in the design process is to perform physical verification on the layout design. It’s critical to verify that the layout does not violate any design rules, and that it matches the schematic design. Physical verification steps include design rule checking (DRC) and layout-versus-schematic (LVS) tools. These tools require a set of instructions, known as verification decks, which detail how to verify the process’ layout rules.

Popular verification tools include Mentor Graphics’ Calibre, Cadence’s Dracula, Diva, and Assura, Silvaco’s Expert, Synopsys’ Hercules, and Tanner’s HiPer. DRC tools verify that the physical designs meet the design rules and graphically identify rule violations. LVS tools first generate a netlist based on identifying devices in a physical layout and connectivity between those devices; this step is sometimes listed separately as extraction (EXT). The netlist is then compared to the schematic netlist to ensure the two views match-not only in terms of device connectivity but also device parameters.

Parasitic extraction tools also build a netlist similar to the one generated during LVS. They also extract device parameters and parasitic devices. The resulting netlist is then input into a Spice simulator to ensure that the physical layout of the design meets electrical specifications. This step becomes increasingly important as feature sizes break the sub-micron barrier.

Typically, foundries will run a final design rule check to sign-off on the manufacturability of the customer’s design. Errors found at this stage may require sign-off by both the customer and the foundry, often resulting in project delays. It’s therefore critical that the DRC deck found in the PDK should produce identical results to the foundry sign off deck.

Figure 2: The customer analog design process

The various options

A “bare-minimum�? PDK includes a document listing the various design rules, the layer information, and a GDSII example of devices included in that particular process. However, this type of kit does not typically include all components or building blocks and requires additional development to start a design.

In contrast, a fully integrated PDK includes all the necessary components to design, simulate, layout, and verify a chip design. These components include schematic symbols, Spice models, technology files (layer and color definitions), device layouts (pcells, if applicable), the code needed to check and calculate device parameters (if required), and the physical verification decks. (see Figure 2)

A PDK can obviously be quite complex, since each provider has their own way of developing, delivering, and describing the kits. In addition, EDA tool vendors may also define unique terminology for their tool functionality. This creates a steep learning curve for anyone attempting to use a PDK, and represents a significant challenge to customers striving to meet time-to-market opportunities.

With the increasing popularity of the foundry model and the growing number of fabless and fab-lite companies, much time and energy has been spent understanding the differences in PDKs provided by foundries. Today, it appears that we are at a crossroad. The industry is obviously prepared to embrace a certain level of PDK standardization, however there’s an obvious challenge in any standardization strategy that requires PDK developers to change their implementation methods to come into compliance with those standards. This is especially true of full-custom analog PDKs.

The Fabless Semiconductor Association (FSA) is striving to avoid the standardization of every detail of the PDK. Instead, FSA is making an effort to define standards for PDK components using tool-neutral terminology. These definitions will be used to define the “FSA mixed-signal/RF PDK checklist.�?

The effort attempts to bypass some of the more contentious issues involved in developing a standard, those which would require a major overhaul in PDK implementation. The current proposal intends to provide value to the IC design community by letting end-users know quickly and precisely what they have when they receive a PDK. When the checklist is complete, FSA will move to resolve the many issues that face the foundries, fabless companies, EDA and IP vendors, and design-service providers in the development, distribution, and use of PDKs.

Coincident with the FSA efforts, Accellera is spearheading the Open Kit (OK) Initiative and attempting to define a design-kit standard to facilitate more efficient and automated custom IC design. The goals of Accellera’s OK Initiative are more in-depth and far-reaching then the FSA checklist. If the Accellera standard becomes widely adopted, it’s actually conceivable that a designer would be able to use a single PDK across all EDA vendors contributing to the flow. That would contrast sharply with the situation today, where each and every vendor requires their own tool-specific PDK. (see Table 1)

There are so many hurdles to overcome when developing a PDK. The current lack of standards forces PDK providers to develop their own implementation methodologies, while at the same time satisfying customer desires and adapting to continuously evolving EDA tools. Finding a balance between fulfilling individual customer expectations and meeting time-to-market requirements is the biggest challenge in PDK development today.

Add to those concerns, the pressure of meeting customer needs in a timely manner and it’s easy to see that a speedy PDK release often forces a compromise between conflicting requirements. Several possible solutions exist for limiting the scope of the PDK including: reducing the number of vendor platforms initially supported; decreasing the number of features in the PDK, and providing DRC and models only as an initial offering

A Team Effort

The PDK developers’ responsibilities do not end once the PDK is released, however. When the PDK is in the hands of customer design teams, the development effort then becomes a multi-tiered support effort.

The most common support issues occur when a bug is found in the PDK. Serious bugs are often the easiest to deal with for the PDK developer. Because they are show stoppers, these bugs are fixed straight away and a new PDK released. The issue is trickier when the bugs are less severe. Bug fixes are often released according to a release schedule to limit the number of releases. This saves time for both the PDK user and developer, and helps to avoid the confusion caused by frequent releases.

Handling feature requests from customers can be also complicated and must be dealt with on a case-by-case basis. Some feature requests are impossible to implement due to the manner in which a legacy PDK is implemented. Others may cover the design style and desires of one design group but may not fit in with that of other groups.

The goal of the PDK is to make the designer more productive, so that he or she may implement design ideas quickly and accurately. To this end, it’s in the best interest of the PDK developer to add the features that are requested. At the same time, it’s important to clearly understand the request, and the implications to other users . Through the use of automated systems, it’s possible for a PDK user to have a custom feature added to the PDK by the developer. In this case, of course, the developer needs an efficient revision control and PDK-generation system to ensure that any “branched�? PDKs stay current with the standard copy.

Typically, PDK component files are created manually, which makes a PDK difficult to maintain. There’s no common repository to hold data that is shared across the files. The increased effort often introduces bugs into the PDK if the developer fails to update a component. In order to create a more accurate PDK, therefore, some EDA groups have developed their own methodology for retaining all process data in one single file.

Shorter development cycles, insufficient in-house resources, lack of foundry PDK, and limited experience with a particular EDA vendor or tool may prompt a company to consider outsourcing PDK development. Most EDA vendors offer consulting services to perform such contract work.

The decision to outsource a PDK development is not one that should be taken lightly. Risks are greatly increased when outsourcing PDKs prior to the completion of process development, since rules and models may still be in flux. Similarly, developing a PDK for a mature process via a third party is not as simple as sending off documentation and waiting for a high quality kit to come back. Often, the third party developer and its customer work closely to interpret process design rules and understand any legacy that must be maintained in order to support design activity and keep the new tool compatible with previously existing designs.

Quality counts

Of course, the PDK development effort doesn’t stop once it is completed. Flaws are frequently uncovered in the PDK’s construction, even when built by the most experienced consultants. Despite these challenges, contracting PDK developments through a third-party EDA vendor has its benefits, especially when an organization lacks the design resources or experience in a new tool set or process technology. And, adopting this methodology may allow an organization’s internal resources to gain the background and experience that will be necessary to support the PDK once the outsourced PDK is accepted.

To make the process work, it’s important to be very specific about what is expected of each party, and to be equally realistic about the resources and time required for PDK development. Although these attitudes and perspectives are an extension of good software engineering practices, their importance can’t be emphasized enough to ensure meeting time-to-market schedules.

The quality of a PDK has significant impact on a design organization. If a PDK contains all of the necessary components for a design and supports all the right tools, a team can begin designing immediately. For those foundries that provide less than adequate PDKs, however, a design team must build additional weeks, even months, into their schedule for developing the PDK development or resign themselves to the use of less efficient tools and flows. The PDK-its quality, features, tool support, and capabilities-can have a dramatic impact on first-silicon success. Well-built PDKs can have a tremendous impact on IC designers, providing them with the tools necessary to build IC circuits and compete in today’s aggressive markets.