Accellera's ALF language lets designers control libraries

Accellera's ALF language lets designers control libraries
By Wolfgang Roethig, EEdesign
August 8, 2003 (6:47 p.m. EST)
URL: http://www.eetimes.com/story/OEG20030808S0014

A recurring theme in IC design is the gap between performance of silicon technology and the achievable design results. Whenever a gap opens, it is eventually closed by a new generation of EDA tools. Typically, the closure of such a gap is attributed to the integration of previously isolated design tasks, or the unification of previously fragmented design solutions.

For example, there was the “wall” between design and test, which has been removed by the concept of design for test. More recently, the wall between synthesis and layout has been removed by the concept of physical synthesis. The next proposed target is the wall between design and mask generation, which is expected to be replaced by the concept of design for manufacturing.

But the wall between library creation and design creation has resisted the tide of the times. In a similar way that data was thrown over the wall between front-end and back-end design applications, a predefined set o f library elements with predefined modeling views is still thrown over the wall between the supplier and the user.

The library elements are “as defined by the supplier,” and the modeling views are “as required by the EDA application.” The designer has no choice but to take the library elements as is, without the possibility of comprehending, let alone modifying, the contents of the library beyond the views that selected EDA applications need to know.

However, with ever increasing design complexity, performance and cost, the concept of a predefined library becomes questionable. For example, at the beginning of a design project, the user may want to find out whether it makes sense to implement a design in a particular technology, before a library for this technology actually exists.

In the middle of the design implementation, the user may want to create blocks that become re-usable library elements. At the end, the user might find out that the design could be optimized with minimal layout change to meet performance goals, if only there were a few more library elements available (for example, cells with the right drive strength). At any time in the design process, the user may want to evaluate timing, power, electrical performance, congestion, routability and other design characteristics at different degrees of abstraction and accuracy.

The Accellera Advanced Library Format (ALF), a newly completed IEEE standard, enables a design methodology wherein the user has more control and influence over the library and its usage in the design flow. Instead of being merely a data repository like conventional library formats, ALF is an intelligible, self-extensible modeling language with semantic support for functional, electrical and physical modeling of library elements, including technology rules, cells, building blocks and interconnect.

ALF supports a complete RTL to GDSII description of functional, electrical performance and layout views of an ASIC and SoC technology library, scalable from cells to complex hierarchical design blocks. ALF is a production-proven standard, supported by leading-edge silicon vendors and next-generation EDA tools targeting 0.13u and smaller process technologies.

ALF's range of abstraction is suitable for behavioral, RTL, gate-level and layout. Since ALF has not been developed in a vacuum, it is a true superset of existing library formats and easily translatable from such legacy formats. The construction principles of ALF are simple enough to create an ALF library with a minimal learning curve, while focusing on the contents rather than on the particularities and restrictions of the format.

Figure 1 gives an overview of the relationship between major language elements or objects defined in ALF.

Figure 1 -- Relationship between ALF language elements

From an application standpoint, the language elements can be associated w ith modeling domains, that is, a functional, an electrical and a physical domain. However, the descriptive power of ALF comes mainly from the domain-independent language elements, such as templates (for re-usable library descriptions) and arithmetic models (for calculation of a mathematically describable quantity).

Creation and characterization of a library element

ALF can be used to specify the desired functionality and characterization space of a library element, such as a cell, as shown in Figure 2.

Figure 2 -- Cell library creation flow

A specification of a cell in ALF includes at the name of the cell and its terminals — that is, pins and a formal description of the function performed by the cell. This formal description is sufficient for the purpose of generating hardware description language (HDL) simulation models in various languages, such as VHDL or Verilog.

Multiple HDL models can be generated for different purposes, where the difference is defined by the user's preference for modeling style rather than by the functionality of the cell. For example, one model can handle unknown logic states in a crude way, resulting in fast simulation, while another model can handle unknown logic states in a case-by-case way, resulting in a slow but more accurate simulation. The ALF model can serve as a common reference for all those HDL models.

A physical layout of a cell can be represented in the GDSII format. A transistor-level netlist of a cell in Spice format can be extracted from the physical layout. Such a transistor netlist includes parasitic electrical components.

Alternatively, a designer can create a transistor netlist by hand or by using an EDA tool that maps a functional specification described in ALF into a transistor level netlist. Such a transistor netlist will be less accurate than one extracted from layout, but it may be still be useful for prototyping a library.

Both the transistor netlist and the various HDL models can be compared against the functional specification described in ALF. More importantly, the transistor netlist can be used to characterize the performance of the cell, in order to measure timing, power, noise, and other electrical characteristics by running a Spice simulation.

The set of necessary Spice simulations is determined and controlled by a characterization tool. The characterization tool can infer pertinent information from the specification represented in ALF, as far as this information relates to the functionality of the cell itself. For example, the timing arcs that need to be characterized can be represented in, or inferred from, ALF. The output of the characterization tool is a library cell model, populated with characterization data, also represented in ALF.

Optionally, a library compiler can be used to combine all the library cell models into a binary file, as a data preparation step for an EDA application tool.

Basi c implementation and performance analysis of an IC

The ALF library can be used in an IC implementation flow which uses cells as building blocks, as shown in Figure 3.

Figure 3 -- Basic IC implementation flow

In this flow, an RTL design description is transformed into a netlist by an RTL synthesis tool. The netlist contains instances of cells, also called gates, rather than transistors. This application can use the ALF library to find the library elements needed to map the RTL description into a netlist containing instances of cells. The transistors inside the cells are not described in the ALF cell models.

An equivalence checking tool can compare the RTL design description with the netlist, in order to decide whether the RTL-to-netlist transformation has been done correctly. This application can use the same ALF library as the RTL synthesis tool. Also, an HDL simulation tool (not shown in Fig ure 3) can be used to decide whether both the RTL design description and the netlist behave as expected in response to a given stimulus. The simulation tool can use an ALF model or an HDL model derived from the ALF model.

The flow in Figure 3 is simplified. Special netlist transformations, such as creation of data path structures, creation structures related to design for test (DFT), and especially scan insertion, are not shown. However, the ALF cell models also contain information pertaining to these applications.

The process of cell placement and interconnect routing is summarily referred to as layout. Special layout operations, such as layout of a power supply structure, or layout of a clock network structure, are not explicitly shown in Figure 3. The ALF cell models contain abstract physical information, such as size and shape of the cell, location, size and shape of the cell pins and routing blockages, which are pertinent for layout.

Also, abstract information concerning the artwork within the cell can be represented in ALF — for example, area, perimeter and connectivity of artwork on specific layers. This information is pertinent for manufacturability, such as antenna rule and metal density check. In addition to cell models, technology rules for routing can also be represented in ALF, such as constraints for the width and length of routing segments, distance between routing segments, and distance between vias.

The implemented IC needs not only be correct in terms of functionality and layout; it also has to meet electrical performance constraints, predominantly timing constraints. Other aspects of electrical performance, such as power consumption, signal integrity, and reliability, have become increasingly important. Signal integrity aspects include the cleanliness of signal waveform shapes, immunity against noise induced by crosstalk, and voltage drop.

Reliability aspects include dependable long-term operation in the presence of electromigration stress, hot electron effect and t hermal instability. The cell models in ALF support characterization data for timing, power, signal integrity and reliability. For example, reliability data can be described as a limit for voltage, current, or operation frequency.

A particular feature in ALF is the representation of these data in the context of a stimulus, described by a vector expression. With this feature, the data can be related to particular environmental operation conditions, and a more accurate performance analysis can be performed.

Performance analysis happens within each step of the IC implementation process. RTL synthesis, cell placement and interconnect routing applications have embedded static timing analysis (STA) and other performance analysis capabilities. Also, after completion of each step, a standalone performance analysis can be applied, in order to measure the achieved performance more accurately.

Electrical performance depends not only on the interaction between instances of cells, but also on the parasitics i ntroduced by the interconnect wires. After netlist creation, parasitics can be statistically estimated using a wire load model (WLM). After placement, parasitics can be more accurately predicted by estimating the length of particular routing wires between pins of placed cells. After routing, actual parasitics can be extracted and represented in a file using the standard parasitic exchange format (SPEF).

An interconnect model in ALF can describe a statistical WLM, a rule for parasitic estimation based on estimated routes, or an interconnect analysis model. The interconnect analysis model specifies the desired level of granularity for the parasitics, and the calculation of timing, noise, voltage, or current based on instances of parasitics and on an electrical model of a driver cell. The data for the electrical model of a particular driver cell can be represented in ALF as a part of the cell characterization data.

Hierarchical implementation and prototyping of an IC

An IC implementation flow with cells as building blocks has its limits imposed by the number of objects, such as instances of cells and nets, that can be reasonably handled by designers and by application flows. For ICs exceeding the limits of objects that can be reasonably handled, the following approaches are used, possibly in combination with each other:

• Bottom-up design: Create larger building blocks from cells first, then use these blocks for IC implementation.
• Top-down design: Divide a design into sub-designs first, implement each sub-design as a block, then assemble the blocks.
• Prototyping: Do a simplified so-called virtual implementation of the entire design first, then partition the virtually implemented design into blocks, use the results of the virtual implementation as constraints for actual implementation of each block, implement and assemble the blocks.

The common denominator for all these methods is creation of blocks, in order to reduce the number of objects seen by the application. The appl ication for creation of a block is shown in Figure 4.

Figure 4 -- Block creation flow

A block can be created by using the basic IC implementation flow (see Figure 3). A block with a functionality that can be used and re-used is commonly referred to as intellectual property (IP). In case of a “hard” block, the primary output of the implementation flow — a gate-level netlist with placement and routing — is preserved and eventually transformed into a physical artwork. In case of a “soft” block, only the primary input of the implementation flow, the RTL design description, is preserved.

The output of the implementation flow serves only for the purpose of block characterization, that is, creation of an abstract model for the block. The block characterization consists of a repeated application of performance analysis within the range of desired characterization followed by abstraction. Abstraction i ncludes reduction of the physical implementation data and association of the performance analysis data with a specified model. Both the specification of the model and the model itself can be represented in ALF.

Variants to this flow include partial IC implementation, such as doing only RTL synthesis and placement without routing. This can be used especially in the case of a soft block, where the implementation data is not preserved. The rationale for not preserving the implementation data of a block is the possibility of achieving a better overall IC implementation result by implementing the block later in context of other blocks instead of implementing the block standalone up front.

Depending on whether a block is used as a hard block or a soft block, the ALF model can represent a different level of abstraction. An ALF model for a hard block can have similar features as an ALF model for a cell (see 2 and 3). In addition, the netlist and the parasitics representing the output of the implementation f low can be partially preserved in the ALF model, especially at the boundary of the block.

This enables accurate analysis of the electrical interaction of a block with adjacent blocks in the context of an IC implementation. On the other hand, an ALF model for a soft block can represent a statistical range, or upper and lower bounds for characterization data rather than “hard” characterization data. That's because there is a degree of variability in the implementation of actual instances of the block. Also, a statistical WLM can be encapsulated within the model of the block.

ALF supports specific modeling features for parametrized blocks, that is, blocks which can be implemented in various physical shapes or sizes and with variable bit width and performance characteristics. The ALF constructs group, template, static, and dynamic template instantiation can be used for this purpose.

Independent of whether a block is a hard block or a soft block, the application for creating the IC can now use the abstract model of the block as a library element rather than a cell. In a similar way, because an ALF model of a cell does not reveal transistor-level implementation details, an ALF model of a block does not reveal gate-level implementation details. However, the ALF model of a block still provides enough information for an application to implement or explore the implementation of an IC and analyze the performance and the compliance to logical and physical design constraints.

An IC is designed in the context of a specific environment with specific constraints. Environmental constraints include the characteristics of the package, the pc-board, and the range of process, voltage, and temperature (PVT) conditions. Other constraints are given by globally applicable physical design rules, such as the available routing layers, the amount of routing resources reserved for the power distribution, and the available locations for I/O pins at the boundary and in the center of a chip.

The prototyping approach can be used to evaluate whether a design can be implemented within these constraints. The electrical characterization data in ALF —, timing, power, noise, physical and electrical rules, estimation models for parasitics — can be represented as mathematical functions of environmental conditions and constraints.

A conceptual flow for the prototyping and hierarchical implementation of an IC involving ALF models at different levels of abstraction is shown in Figure 5.

Figure 5 -- IC prototyping and hierarchical implementation flow

The design planning and prototyping application uses predefined models of blocks as library elements, referred to as “library block models.” The design is partitioned into sub-designs. In the block creation flow (Figure 4), a combination of block implementation and block characterization is applied to each sub-design. The applicable library elements for each block are cells.

The outputs of the block creation flow are the characterized models of the sub-designs, referred to as “design block models.” The design block models can be used to iterate on the design planning application, resulting in a possible refinement and re-partitioning of the design. Once the evaluation of each block against the sub-design constraints and the evaluation of the virtually assembled blocks against the global design constraints are satisfactory, the block implementation results — the netlist with placement and routing for each block, — can be actually assembled to form the IC.

The design of an IC can use a combination of cells, hard blocks and soft blocks, blocks with fixed specifications, and parameterized blocks as library elements. Some of the library elements are available independently of the design, while others are created during the design and only for the purpose of the particular design. An abstract model for a soft block can be used in conjunction with a more d etailed model for a hard block. The abstract model can be replaced with a more detailed model during implementation of the block. Technology rules and interconnect models are used throughout the flow.

Conclusion

The ALF standard provides a comprehensive modeling language for library elements, technology rules and interconnect models. ALF models at different levels of abstraction can be used concurrently by EDA applications for planning, prototyping, implementation, analysis, optimization and verification of complex ICs. Without ALF, EDA tools could only use “de-facto” standards as a common denominator and could not overcome the deficiencies by proprietary, tool-specific and fragmentary library extensions.

ALF enables unification instead of fragmentation. ALF offers creativity in library modeling, opportunity for EDA software development, flexibility, interoperability and choice in the design flow.

Wolfgang Roethig has over 9 years of industrial experience in Electronic Design Au tomation, and he holds 5 patents in that domain. He is currently Senior Design Engineering Manager at NEC Electronics America. His responsibilities include the specification, development and deployment of next generation design tools and flows for high-end IC design. He is also NEC's representative on the Accellera Board of Directors and chairman of the IEEE ALF working group.