Good stories often start over a beer. While sharing a libation or n + 1 with several friends from the industry, one of them mentioned a problem with their fab supplied PDK. Another had a similar problem with a different PDK, by the end next round, I had collected a list of common problems that design groups were having with their PDKs.
A process design kit (PDK) models a specific fabrication process for a set of tools used in the design flow blessed by the fab. Using this PDK and following one of the fab supported design flows, the designers can create and verify a design that is manufacturable in that process. The PDKs available from the fabs not only reflect the specific manufacturing process but can be tailored for markets with the addition of processing steps and devices. This generic PDK works very well for many of the design groups. You can create a design and it can be manufactured.
With the competition in some markets, the design groups must take any advantage it can over its competitors. They choose the tools and methodologies specific to their design market and design style, these may deviate from the supported flows. These groups want to enhance the PDK to meet their needs. It isn’t just a drinking problem; these issues are industry wide. An industry wide problem can be solved with a collaboratively developed solution.
What You’ll Learn
In this tutorial, we will explore ways of customizing PDKs to support the tools and devices in your design flow without rewriting the existing PDKs. We will jump in with parameters, resetting defaults and other control and adding new parameters. On to PCells, customize the shapes, connectivity and properties without source code. Add new tools to the flow, integrating the technology and supporting new parameters and models. Integrate your own devices into the PDK and not have them overwritten on an uprev from the fab.
These solutions addressed many of the problems seen by the PDK Users. They represent what can be done by working collaboratively to solve common problems yet allowing each user to customize the implementation. Working together to address common issues, under the anti-trust protections provided by Si2 membership, SIG members create ideas, write white papers, conduct surveys, and develop prototypes; unique solutions sharing a common understanding of the problems.
Energy and power concerns continue to grow and become more challenging in all design phases. Increasing attention is being paid to modeling techniques for system- and software-level power management. Today, multiple modeling standards are being developing and evolving to address these challenges, covering the full range from low-level hardware to high-level software. Each standard is evolving to address particular problems, but the modeling space is sufficiently large that different capabilities are needed to cover highly varied applications and methodologies.
Due to the wide range of design and application scenarios, one modeling technology does not fill all power modeling needs. Software-level power modeling, representing a system’s power characteristics, forms a programmer’s view of power behavior. In this approach, all major hardware functions and how to control their power characteristics are abstracted. Functions can be put into low-power states as often as possible by real-time power management software. System-level power modeling tends to focus on the hardware description of the system and its power behavior.
The system may be described in System C or RTL, or even in spreadsheets during the earliest design phases. It often focuses on meeting localized thermal constraints. Both of these modeling approaches differ from conventional gate-level modeling in which process-voltage-temperature (PVT) specific power models are built only for primitive logic cells, such as Nand and Nor gates, multiplexors, and flip-flops.
This tutorial will present the latest state of the IEEE 1801, 2415, and 2416 power standards, and show why multiple standards are required to cover the broad design and operational space. Speakers will explain the features of these three standards and how they enable new capabilities and power management methods. Early users of the standards and underlying technologies will describe how the new modeling capabilities impacted their design processes and end products.
• Developers and users of the 1801 standard for Power Intent will describe recent extensions for Power State modeling. These enhancements enable the description of the power state space for IP Blocks and hardware systems.
• Developers of the 2415 standard, currently in development, will describe their work on a power hardware abstraction and layer based upon the Linux Device Tree. Prototype usage of this hardware abstraction will also be presented.
• Developers of the 2416 standard for Power Data modeling, also currently in development, will describe their power contributor approach for PVT independent power modeling.
They will also describe how such models can be used with conventional gate- level tools and system-level modeling, including detailed electro-thermal analyses. This tutorial is intended for engineers concerned about power (software, EDA, IP, and SoC developers) who want to understand advanced power modeling, and which standard is best applied to different applications.