Design Migration Tools
Design migration tools enable the transfer of electronic designs between different EDA platforms, technology nodes, and design environments. As organizations evolve their tool chains, adopt new semiconductor processes, or integrate acquired designs, the ability to migrate existing work becomes critical to preserving engineering investments and maintaining business continuity. These tools bridge the gaps between proprietary formats, translate design intent across different paradigms, and ensure that migrated designs maintain their original functionality and performance characteristics.
The design migration landscape encompasses a broad spectrum of challenges, from straightforward format conversions to complex technology recharacterization. Whether moving a schematic from one capture tool to another, porting a layout to a new process node, or consolidating designs from multiple acquisitions onto a common platform, migration tools provide the technical foundation for these transformations while minimizing manual rework and reducing the risk of introducing errors.
Schematic Translation
Schematic translation converts circuit designs between different schematic capture tools, preserving connectivity, component attributes, and design hierarchy. This process goes beyond simple file format conversion to address fundamental differences in how various tools represent electronic circuits, manage component libraries, and handle design metadata.
Format Conversion Fundamentals
Different EDA vendors employ proprietary file formats optimized for their specific tools. Schematic translation tools parse these native formats, extract the underlying design information, and reconstruct the design in the target format. This process must handle varying approaches to representing wires, buses, hierarchical blocks, off-page connectors, and graphical annotations.
Intermediate representation formats facilitate multi-platform translation. Rather than maintaining direct converters between every possible pair of tools, translation systems often use neutral interchange formats as intermediate steps. EDIF (Electronic Design Interchange Format) has historically served this role, though its complexity has limited widespread adoption. Modern alternatives include XML-based formats that capture schematic structure while remaining human-readable for debugging.
Symbol Mapping and Translation
Component symbols represent the most challenging aspect of schematic translation. Each EDA platform maintains its own symbol libraries with different naming conventions, pin designations, and graphical representations. Migration tools must map source symbols to equivalent target symbols while preserving electrical connectivity and component identity.
Automated symbol mapping uses various techniques to match components across libraries. Part number matching links components with identical manufacturer part numbers. Function-based matching identifies components with equivalent electrical characteristics even if named differently. When automated matching fails, interactive mapping interfaces allow engineers to specify correspondence between unmatched symbols.
Symbol geometry translation handles the graphical aspects of schematic representation. Pin positions, symbol shapes, and annotation placement must adapt to target tool conventions while maintaining schematic readability. Some translations preserve source geometry exactly, while others reformat schematics to conform to target tool standards.
Connectivity Preservation
Maintaining correct electrical connectivity represents the fundamental requirement of schematic translation. Wire connections, net names, and bus structures must transfer accurately regardless of differences in how tools represent these elements internally. Translation tools typically extract a netlist-level representation of connectivity that remains valid across format boundaries.
Net naming conventions vary significantly between tools. Some tools assign automatic net names while others require explicit naming. Net name prefixes, suffixes, and special characters may have different meanings across platforms. Translation tools must map these naming schemes while avoiding conflicts and preserving design intent.
Bus handling presents particular challenges due to varying conventions for bus width specification, bit ordering, and member signal naming. A bus defined as DATA[0:7] in one tool might appear as DATA[7:0] or DATA[7..0] in another. Translation tools must recognize these variations and maintain consistent bit ordering throughout the design.
Hierarchy and Design Structure
Hierarchical schematic designs use block symbols to encapsulate subcircuits, enabling design reuse and managing complexity. Translation must preserve these hierarchical relationships while adapting to different tools' approaches to hierarchy. Some tools use separate files for each hierarchical level while others embed hierarchy within single files.
Interface definitions between hierarchical levels require careful translation. Port directions, naming conventions, and the relationship between block pins and internal nets must transfer correctly. Mismatched interfaces can cause open connections or shorts that appear only after translation.
Flat versus hierarchical conversion may be necessary when source and target tools have incompatible hierarchy models. Flattening expands all hierarchy into a single level, which simplifies translation but loses design structure. Selective flattening preserves some hierarchy while expanding levels that cannot translate directly.
Layout Migration
Layout migration transfers physical design data between different layout tools or technology processes. Unlike schematic translation, which deals primarily with logical connectivity, layout migration must handle precise geometric information, layer mappings, and technology-specific design rules while preserving the physical implementation intent.
Geometry Translation
Layout geometry consists of polygons, paths, and other shapes that define circuit structures on different layers. Translation must preserve exact coordinates, dimensions, and layer assignments while adapting to different tools' internal representations. Coordinate system differences, unit conventions, and precision limits can all affect geometric accuracy.
Database unit conversion handles differences in how tools represent physical dimensions. Some tools work in microns, others in nanometers or database units that require scaling. Translation must maintain dimensional accuracy while avoiding rounding errors that could accumulate across complex designs to cause design rule violations.
Polygon representation varies between tools. Some represent shapes as Manhattan polygons with only orthogonal edges, while others support arbitrary angles. Text handling, via representations, and cell reference mechanisms also vary. Translation tools must recognize these different representations and convert appropriately.
Layer Mapping
Layer mapping translates between different layer naming and numbering conventions. Each EDA platform and semiconductor foundry uses different layer identifiers for metal layers, via layers, implant layers, and other process elements. Comprehensive layer mapping tables define how source layers correspond to target layers.
Purpose layers and layer-purpose pairs add complexity to layer mapping. Some tools use separate layers for different purposes (drawing, label, pin) while others combine these into single layers with attributes. Derived layers created through Boolean operations on base layers may need to be regenerated rather than directly translated.
Technology-specific layers present particular challenges during technology migration. A design from one foundry may use layer types that have no direct equivalent in another process. Layer merging, splitting, or functional substitution may be required, often guided by process engineers familiar with both technologies.
Cell and Instance Management
Layout designs consist of cell definitions instantiated multiple times throughout the hierarchy. Translation must maintain this cell structure, preserving the relationship between cell definitions and their instances. Cell naming conventions, library organization, and view management all require careful handling.
Reference library management addresses the challenge of cells that reference external libraries such as standard cells, I/O pads, or IP blocks. These referenced cells may need separate migration, replacement with equivalent cells from the target library, or abstraction to black boxes pending later resolution.
Instance transformations including rotation, mirroring, and magnification must translate correctly. Different tools may use different conventions for specifying these transformations, and slight differences in transformation order or coordinate origin can cause placement errors.
Design Data Integrity
Verification of migrated layouts ensures that translation has not introduced errors. Geometric comparison tools overlay source and target layouts to identify differences. Connectivity extraction and comparison verifies that electrical equivalence has been maintained. Design rule checking in the target environment catches issues that may arise from translation.
Property and attribute translation preserves non-geometric design information. Net names assigned to shapes, device parameters, and custom properties all carry design intent that must survive migration. Some properties may require value translation when source and target tools use different property conventions.
Technology Node Migration
Technology node migration adapts designs from one semiconductor manufacturing process to another, typically to take advantage of smaller feature sizes, improved performance, or reduced power consumption. This form of migration extends beyond format translation to include fundamental redesign of device structures and interconnects to match new process capabilities and constraints.
Process Technology Mapping
Mapping between process technologies requires understanding the electrical and physical characteristics of both source and target processes. Transistor sizes, threshold voltages, metal layer properties, and design rules all differ between nodes. Migration tools must account for these differences when transforming designs.
Device scaling applies geometric transformations to adapt designs to smaller feature sizes. Simple linear scaling rarely works due to different scaling factors for various design elements and non-linear effects in advanced nodes. Intelligent scaling considers device physics to maintain electrical characteristics rather than just geometric proportions.
Metal stack mapping addresses changes in available routing resources between nodes. Different processes offer varying numbers of metal layers with different pitch, thickness, and resistance characteristics. Via structures and routing patterns must adapt to utilize target process metal stacks effectively.
Design Rule Adaptation
Design rules constrain how physical layout structures may be placed and spaced. Each process node has unique rules reflecting manufacturing capabilities and reliability requirements. Migration must transform layouts to satisfy target process rules, which may be more restrictive, more permissive, or simply different from source rules.
Rule-based transformation engines automatically modify layouts to meet new design rules. Spacing adjustments expand or contract gaps between features. Width modifications ensure that all shapes meet minimum width requirements. Via enclosure adjustments modify metal overlap around vias to satisfy new enclosure rules.
Complex rule handling addresses advanced design rules that go beyond simple spacing and width checks. Density rules require balanced distribution of features across the die. Antenna rules constrain charge accumulation during manufacturing. Via coverage rules ensure reliable connections between layers. Migration tools must understand and enforce all applicable rules.
Performance Recharacterization
Migrated designs must be recharacterized to determine their performance in the new technology. Transistor characteristics change with process, affecting timing, power, and signal integrity. Interconnect parasitics differ due to different metal and dielectric properties. Complete recharacterization validates that migrated designs meet requirements.
Standard cell library mapping replaces source technology cells with equivalent cells from the target library. Cell functionality must match, but timing, power, and area characteristics will differ. Library characterization data for the target technology enables accurate analysis of migrated designs.
Timing closure after migration typically requires iteration. Initial migration may result in timing violations due to changed device and interconnect characteristics. Optimization techniques including gate sizing, buffer insertion, and routing adjustments bring designs back into timing compliance.
IP Block Migration
Intellectual property blocks such as memories, PLLs, and analog circuits often require special handling during technology migration. These blocks may be available as hard IP specifically designed for the target process, requiring replacement rather than migration. Alternatively, they may need complete redesign by specialists familiar with the specific IP type.
Analog and mixed-signal circuits present particular migration challenges. Device matching, noise characteristics, and parasitic sensitivity make these circuits highly process-dependent. Successful migration often requires circuit redesign rather than geometric transformation, guided by analog design expertise.
Tool Interoperability Formats
Interoperability formats define standardized representations for design data that multiple tools can read and write. These formats enable design exchange between different tools, organizations, and supply chain partners without requiring direct tool-to-tool converters. Understanding available interchange formats helps engineers select appropriate formats for different migration scenarios.
GDSII and OASIS
GDSII (Graphic Data System II) has served as the de facto standard for IC layout interchange for decades. This binary format represents layout geometry in a hierarchical cell structure with support for various geometric primitives. Nearly all layout tools can read and write GDSII, making it the most universally supported format for layout exchange.
OASIS (Open Artwork System Interchange Standard) provides a more efficient alternative to GDSII for large designs. OASIS offers improved compression, eliminating the file size explosion that occurs with GDSII for modern high-density layouts. Support for OASIS has grown steadily as design sizes have increased beyond practical GDSII limits.
Limitations of these formats include their focus on geometry at the expense of design intent. Net connectivity, device parameters, and design constraints do not transfer through GDSII or OASIS. Additional format exchange or manual reconstruction may be needed to recover this information.
LEF and DEF
LEF (Library Exchange Format) and DEF (Design Exchange Format) together provide interoperability for physical design at a higher level of abstraction than GDSII. LEF describes cell libraries including pin locations, obstructions, and routing information. DEF captures placed and routed designs including cell instances, routing, and design constraints.
These formats serve well for place-and-route tool interoperability. Designs can move between different routing tools or between front-end and back-end flows from different vendors. The formats preserve essential information for physical design while abstracting internal cell details.
Version compatibility requires attention when using LEF and DEF. Format specifications have evolved to support new design requirements, and tools may support different format versions. Ensuring version compatibility between exporting and importing tools prevents information loss or parsing errors.
OpenAccess
OpenAccess provides a comprehensive design database infrastructure used by multiple EDA vendors. Rather than a file format, OpenAccess defines APIs for accessing design data, with implementations available from various sources. Tools built on OpenAccess can share designs directly through the database without explicit export and import.
The OpenAccess database model supports schematic, layout, and abstract views within a unified framework. Cell-level interoperability allows mixing cells from different tools within a single design. This native interoperability eliminates many translation challenges when working within the OpenAccess ecosystem.
Adoption of OpenAccess varies among EDA vendors. Some major vendors have embraced OpenAccess as their native database, while others maintain proprietary formats with OpenAccess import/export capability. Understanding which tools share native OpenAccess compatibility helps plan efficient workflows.
Verilog and VHDL
Hardware description languages provide interoperability for digital design at the register-transfer and gate levels. Structural Verilog or VHDL netlists describe connectivity between instances, enabling design exchange between synthesis, simulation, and verification tools. These text-based formats are human-readable and widely supported.
Behavioral descriptions in HDL capture design intent at higher abstraction levels. While behavioral HDL is tool-independent in principle, synthesis results may vary between tools. Migration of behavioral designs typically involves re-synthesis rather than netlist translation to optimize for the target tool's capabilities.
SPICE Netlists
SPICE netlist format provides interoperability for analog and mixed-signal circuit descriptions. Device connectivity, model references, and simulation directives transfer through SPICE netlists between different simulation tools. Subcircuit hierarchies and parameter definitions support complex design structures.
SPICE dialect variations create compatibility challenges despite the format's widespread use. Different simulators extend base SPICE with proprietary syntax for advanced features. Translation may require adjusting dialect-specific constructs when moving between simulators.
Library Mapping
Library mapping establishes correspondences between component libraries across different platforms, technologies, or vendors. Successful design migration depends on correctly mapping every component in the source design to an appropriate target equivalent. This process requires understanding component characteristics, availability, and the acceptable tolerance for differences between source and target components.
Component Matching Strategies
Exact matching identifies components with identical specifications between source and target libraries. Manufacturer part numbers, when present and consistent, provide the most reliable matching basis. This approach works well when migrating between tools from the same organization that share component databases.
Parametric matching identifies equivalent components based on electrical characteristics when exact matches are unavailable. Resistance values, capacitance, voltage ratings, and package types define equivalence criteria. Tolerance matching allows components with slightly different values when the difference falls within design margins.
Functional matching applies to complex components like ICs where equivalents may come from different manufacturers or represent different generations. Pin compatibility, functional specifications, and timing characteristics all factor into determining acceptable substitutes.
Library Mapping Tables
Mapping tables document the correspondence between source and target components systematically. These tables capture not just the component mapping but also any parameter adjustments, footprint changes, or design considerations associated with each mapping. Well-maintained mapping tables become valuable assets for recurring migrations.
Automated mapping table generation extracts component information from source designs and searches target libraries for matches. Scoring algorithms rank potential matches based on how closely they meet matching criteria. Engineers review and approve suggested mappings, adding manual mappings where automation fails.
Mapping table maintenance addresses ongoing changes in component availability. When components become obsolete or unavailable, mapping tables require updates. Version control for mapping tables tracks changes over time and enables consistent migrations across related projects.
Library Quality Assurance
Target library quality directly affects migration success. Incomplete or incorrect library entries cause design errors that may not surface until manufacturing. Library verification before migration identifies potential issues with footprints, symbols, or component parameters that could affect migrated designs.
Symbol verification ensures that target symbols correctly represent component functionality. Pin counts, pin names, and electrical types should match component specifications. Symbol graphics should conform to organizational standards for schematic readability.
Footprint verification confirms that target footprints match component physical specifications. Land pattern dimensions, hole sizes, and courtyard spacing should match manufacturer recommendations or organizational standards. 3D model availability and accuracy support mechanical integration verification.
Constraint Preservation
Design constraints capture critical requirements that guided original design decisions. Timing constraints, placement constraints, routing rules, and other specifications must transfer accurately during migration to ensure that migrated designs maintain intended characteristics. Constraint migration often receives insufficient attention, leading to designs that pass format translation but fail to meet original requirements.
Timing Constraint Translation
Timing constraints specify required performance for digital designs. Clock definitions, input/output delays, multi-cycle paths, false paths, and other timing exceptions must migrate to the target environment. SDC (Synopsys Design Constraints) format has become widely adopted, but variations in tool support require careful validation.
Clock tree constraints specify how clock signals should be distributed. Clock source definitions, generated clock relationships, and clock uncertainty specifications affect synthesis and timing analysis. Accurate translation ensures that target tools apply equivalent timing budgets and optimization goals.
Constraint file syntax differences between tools require translation even when conceptual timing requirements are identical. Path specification syntax, wildcard patterns, and constraint precedence rules may differ. Translation tools must interpret source constraints and generate functionally equivalent target constraints.
Physical Constraints
Physical constraints guide placement and routing decisions. Floorplan constraints specify where major blocks should be located. Placement constraints pin specific cells to defined locations. Keep-out regions prevent routing or placement in sensitive areas. These constraints reflect design intent that must survive migration.
Routing constraints specify how signals should be routed. Layer constraints restrict certain nets to specific metal layers. Length matching constraints ensure that related signals have equal routing lengths. Shielding constraints specify that sensitive signals be surrounded by grounded conductors.
Power constraints define power distribution requirements. Power domain specifications identify which cells operate on which supplies. Level shifter placement constraints ensure proper signal crossing between domains. IR drop constraints specify maximum allowable voltage loss in power distribution.
Design Rule Constraints
Custom design rules beyond basic process rules may constrain specific design elements. Net class definitions assign rules to groups of related nets. Differential pair constraints specify matching requirements for paired signals. Via style constraints control via stacking and arrangements.
Signal integrity constraints specify requirements for high-speed signals. Maximum length limits prevent excessive propagation delay. Crosstalk spacing rules ensure adequate separation from aggressor nets. Impedance targets specify required trace geometries for controlled impedance routing.
Constraint Validation
Validation ensures that migrated constraints correctly represent original requirements. Constraint comparison tools identify differences between source and target constraint sets. Missing constraints indicate translation gaps that require manual intervention. Conflicting constraints suggest translation errors that could affect design quality.
Equivalence verification confirms that migrated designs meet the same requirements as original designs when analyzed against migrated constraints. Timing analysis comparison shows whether timing margins have been preserved. Power analysis comparison verifies that power distribution remains adequate.
Verification After Migration
Comprehensive verification confirms that migration has not introduced errors or degraded design quality. Verification spans multiple levels from basic format integrity through functional equivalence to full performance validation. The verification strategy should be planned before migration begins, with success criteria defined to guide acceptance decisions.
Structural Verification
Structural verification confirms that migrated designs contain the same elements as source designs. Component counts should match, accounting for any intentional substitutions documented during mapping. Connectivity comparison ensures that all nets have been preserved with correct terminal assignments.
Hierarchy verification confirms that design structure has been maintained. Block boundaries, instance names, and port connections should match the source design organization. Hierarchy changes during migration should be intentional and documented rather than artifacts of translation errors.
Attribute verification ensures that component parameters and design properties have transferred correctly. Resistance and capacitance values, voltage ratings, and other specifications should match source values or approved substitutes. Custom properties carrying design intent should be present in migrated designs.
Equivalence Checking
Formal equivalence checking mathematically proves that two designs have identical logical behavior. This technique is particularly valuable for digital design migration, where it can exhaustively verify that migrated netlists match source netlists under all possible input conditions. Equivalence checking catches errors that might escape simulation-based verification.
Schematic to schematic comparison verifies that captured schematics produce equivalent netlists. This check catches symbol mapping errors, missing connections, or property translation problems that affect circuit behavior. Automated comparison tools flag differences for engineering review.
Layout versus schematic verification extended across migration confirms that physical layouts match translated schematics. This cross-domain check ensures that geometry translation has not introduced shorts, opens, or device parameter errors that would cause functional failures.
Design Rule Verification
Design rule checking in the target environment verifies that migrated layouts comply with target process rules. Clean DRC results confirm successful geometric translation and rule adaptation. Violations indicate translation problems or incompatibilities between source design and target process requirements.
Electrical rule checking validates that migrated schematics meet target tool's electrical requirements. Unconnected pins, conflicting net assignments, and other electrical issues should be resolved before proceeding with downstream design steps.
Functional Verification
Simulation verification exercises migrated designs to confirm functional correctness. Testbenches from original verification should produce identical results when applied to migrated designs. Regression testing with comprehensive test suites provides confidence in migration quality.
Mixed-signal verification addresses designs with both analog and digital content. Analog simulation must confirm that circuit behavior matches original design. Digital simulation verifies logic function. Co-simulation validates interactions between analog and digital domains.
Performance Verification
Timing analysis validates that migrated designs meet timing requirements. Setup and hold violations indicate potential functional failures. Timing margin changes from source to target show migration impact on performance. Timing closure may require optimization after initial migration.
Power analysis verifies that migrated designs meet power requirements. Static power estimates should be comparable to source designs for equivalent technology. Dynamic power under representative workloads should meet product requirements. Power integrity analysis confirms adequate power distribution.
Signal integrity analysis validates high-speed design characteristics. Eye diagram analysis shows whether signal quality meets receiver requirements. Crosstalk analysis identifies potential noise coupling issues. Return loss and insertion loss meet channel requirements for high-speed interfaces.
Migration Workflow and Best Practices
Successful design migration requires systematic planning, execution, and validation. Established workflows and best practices help organizations migrate designs efficiently while managing risk. These practices apply whether migrating single designs or undertaking large-scale platform consolidation projects.
Migration Planning
Assessment of migration scope identifies what needs to migrate and the challenges involved. Design inventory catalogs all designs requiring migration with their complexity, dependencies, and priority. Tool and technology analysis identifies specific translation requirements. Resource estimation determines staffing and schedule needs.
Risk identification highlights potential problems before they derail migration projects. Designs with unusual features may require special handling. Missing libraries or undocumented constraints can cause delays. Identifying risks early enables mitigation planning and appropriate contingency.
Success criteria definition establishes measurable standards for migration acceptance. These criteria should address structural correctness, functional equivalence, and performance requirements. Clear criteria prevent disputes about whether migration has been successfully completed.
Pilot Migration
Pilot projects test migration processes on representative designs before full-scale execution. Pilots reveal tool issues, library gaps, and process problems that can be resolved before they affect many designs. Lessons learned from pilots improve procedures for subsequent migrations.
Pilot selection should include designs representative of the broader migration population. Simple designs validate basic processes. Complex designs stress migration capabilities. Designs with known challenges test handling of difficult cases. Results from diverse pilots provide confidence in migration readiness.
Execution Management
Systematic execution applies proven processes consistently across all designs. Checklists ensure that all required steps are performed. Status tracking monitors progress and identifies bottlenecks. Issue management captures and resolves problems as they arise.
Version control for migrated designs enables rollback if problems are discovered. Clear labeling distinguishes source, intermediate, and final migrated versions. Archives preserve source designs in original formats for reference and potential remigration.
Quality Assurance
Independent review validates migration quality before release. Review by engineers other than those who performed migration catches errors that executing engineers might overlook. Formal review gates prevent release of inadequately verified migrations.
Documentation captures migration details for future reference. Translation decisions, mapping choices, and known limitations should be documented. This documentation supports ongoing maintenance and future migrations that might build on current work.
Post-Migration Support
Support processes address issues discovered after migration completion. Clear procedures define how to report problems, investigate causes, and implement corrections. Feedback mechanisms capture lessons learned to improve future migrations.
Training ensures that design teams can work effectively with migrated designs. Tool differences from previous environments require learning. Design data organization may have changed. Training investment helps teams become productive quickly with migrated design assets.
Challenges and Limitations
Design migration inevitably encounters challenges that require engineering judgment and problem-solving. Understanding common limitations helps set realistic expectations and enables proactive mitigation of potential issues.
Information Loss
Some design information may not transfer through migration processes. Design intent captured in tool-specific features may not have equivalents in target tools. Optimization choices made for source tool characteristics may not apply in target environments. Accepting some information loss while preserving critical requirements requires careful prioritization.
Documentation can preserve information that cannot be captured in migrated design files. Design notes, constraint rationales, and known issues should be documented to guide engineers working with migrated designs. This documentation becomes part of the design asset alongside the migrated files.
Tool Capability Differences
Source and target tools may have different capabilities that affect migration. Features available in source tools may not exist in targets, requiring workarounds or design changes. Target tools may offer capabilities not present in source tools, creating opportunities but also requiring learning and adaptation.
Workflow differences between tools extend beyond file format differences. Design methodologies, verification approaches, and collaboration models may differ. Migration projects may need to address process changes alongside technical data migration.
Scalability Considerations
Large-scale migrations face different challenges than individual design migrations. Processing thousands of designs requires automation, parallelization, and systematic exception handling. Infrastructure capacity for storage, processing, and verification must scale with migration volume.
Consistency across large migrations requires strict process discipline. Variations in how different engineers handle similar situations create inconsistency that complicates future maintenance. Standardized procedures and automated checking help maintain consistency at scale.
Conclusion
Design migration tools provide essential capabilities for transferring electronic designs between platforms, technologies, and organizations. From schematic translation through layout migration, technology node conversion, and comprehensive verification, these tools address the complex challenges of preserving design value while adapting to new environments.
Successful migration requires more than just conversion tools. Comprehensive library mapping, constraint preservation, and thorough verification ensure that migrated designs maintain their original functionality and quality. Systematic workflows with proper planning, execution, and validation manage risk and deliver consistent results.
As the electronics industry continues to evolve with new tools, processes, and organizational changes, design migration capabilities remain essential. Organizations that develop strong migration competencies protect their design investments, respond flexibly to changing requirements, and maintain competitive advantage through effective management of their design asset portfolios.