English
Licensable Processors - More than just design IP
By John Watters, StarCore
Abstract
Licensable Processor cores and subsystems include sophisticated IP in soft or hard form. The best licensable IP should be designed for easy reuse in the widest possible arena. This includes flexibility in meeting the final requirements with tool and technology independence wherever possible. Unfortunately, the tremendous value represented by some IP is locked up in methodology issues hampering adoption of OPIP (other people's intellectual property). The best quality IP should come with methodology collateral that is also designed for reuse including verification, synthesis for soft IP, place and route, parasitic extraction and timing analysis.
Introduction
Market requirements and the economics of SoC design force the reuse of IP blocks. Those blocks that are licensed from outside sources represent enormous value that can make or break SoC development depending on the efficiency with which the SoC design team can reuse them. While the IP itself, the result of years of effort, may be in perfect working order with all the views required to embed it into an SOC, the tasks of constructing and verifying an SoC are not helped much and in fact may be made more difficult by the reuse of outside IP. The lack of familiarity and the necessity of absorbing the IP into a design and verification flow go against the benefit of design IP reuse. The problem of familiarity is addressed by documentation and training, while the ease of design flow or methodology adoption depends on reusable scripts and tests that are as tool- and platform-independent as possible.
Along with reusable design IP then must come reusable methodology IP. The parallel efforts of construction and verification depend on synthesis, timing analysis, simulation, and equivalence checking tasks, each with associated tools and scripts that are tuned to the IP in question.
Verification IP Reuse
Considering that verification can dominate the development of a complex SoC, it is fortunate that reusing IP provides the advantage of highly verified blocks. High-quality IP should have been verified extensively using all the best state-of-the-art techniques, from high functional code coverage with billions of random simulations, to actual silicon validation. The end-users of such IP should not have to concern themselves with internal functional verification.
On the other hand, the integration of outside IP within a new SoC requires extensive checking to make sure that the interfaces are correct. There are the mechanical tasks of stitching the pins of the embedded IP block to the rest of the SoC, and the more difficult task of ensuring the communication protocols have been well-exercised by SoC-level simulation. Though there may be many ways of doing this, perhaps the best is through the use of RTL simulation monitors whose task is to observe the interfaces while logging activity, collecting statistics, and watching for protocol violations. Monitors constructed for this purpose, using standard RTL, do not rely on specialized tools and can run on all major simulators.
Once the monitors are in place, all that remains is to run sufficient amount of tests to fully exercise the interfaces. Unfortunately, creating these tests can be a daunting task. In the case of embedded processors though, the IP vendor can deliver a set of tests whose purpose is to walk the interfaces through their protocols. This is only a subset of the extensive test suite the vendor needed to completely verify the IP function. The tests should consist of self-checking processor instructions along with the verification environment elements (stubs) needed to run them, including means of starting the simulations, loading the instructions into memory, logging the monitor output, and providing the pass-fail assessment.
Once the interfaces are debugged, the SoC verification effort can focus on system behavior. he monitors can, in addition, help by providing an alternative to waveform viewing through an easily understood log of what is going on in and around the embedded IP block. Also, the tests provided with the IP can be a very useful starting point for developing system-level scenarios.
Therefore verification IP should consist of tool-independent tests, scripts, monitors, and test bench elements (stubs) designed for reuse and targeted at interface checking and at making debug at the system-level easier.
Synthesis IP Reuse
Soft IP represents a unique set of challenges corresponding to the added flexibility inherent in its form. The freedom to choose process technology and manipulate the tradeoffs between performance, power, and area is limited by the design team’s ability to navigate the maze of synthesis and optimization strategies. Every synthesis veteran knows that finding and scripting a good synthesis strategy that achieves the required results in the least amount of time, is the key to success. And every piece of IP will have its own idiosyncratic best strategy.
Nobody knows the best synthesis strategy for a licensed processor like the IP vendor. Their experience comes from hardening the IP in multiple technologies with different optimization goals. Therefore the end-user of soft IP should expect to enjoy the benefits of that knowledge in the form of reusable and configurable synthesis scripts. There are some methods of making such scripts reusable and configurable. Although the overall compile and optimization strategy may be relatively constant, there are many choices to be made in managing the tradeoffs of power, timing, area, and run time. The best scripts should allow for easy customization, not only regarding the process technology, but also the subtle choices concerning optimization constraints and effort, scan architecture, and floor planning. These scripts should isolate these choices in a separate section of user-selectable parameters with error checking and default settings representing the best mainstream approach. This way, the end-user can quickly make appropriate choices without having to reverse-engineer the gory details in the scripts and without risking introducing a bug into such scripts.
The timing goals for synthesis are driven by a set of constraints describing the clocks and boundary conditions for the IP block. If these constraints are incomplete then serious problems can remain undetected, since timing analysis depends on the boundary conditions completeness. Having a complete set of constraints that are customizable is an important part of the reusability of licensed IP. The scripts for timing analysis should share these constraints with the synthesis process and allow for the annotation of backend extracted parasitics for final sign-off. Having parameterized, flexible, and complete constraints for soft IP with built-in examples and error checking facilitates the entire implementation process.
Formal Equivalence Checking
At each stage of the synthesis process, it is wise to use formal equivalence checking tools to verify the resulting netlist. Clock-tree insertion and scan insertion often involve several steps and other tools. Occasionally, a catastrophic error can be introduced into the resulting netlist, that can be best detected by formal checking. This involves yet another set of scripts that contain some best-practice experience from the IP vendor. Formal checking of complex processor cores can be time-consuming at best and may involve subtle tricks to get through the complex logic. Again the IP vendor can assist the SoC design team by providing reusable equivalence-checking scripts that will save time and avoid critical bugs.
Documentation and Training
IP customers are well aware of the need for extensive documentation and training for the IP itself. They should also look for methodology documentation and training covering the integration and reuse tasks they face, to successfully incorporate the IP into their SoC design. Even the most reusable core will poses challenges in synthesis, verification, timing analysis and equivalence checking, that are understood by the IP vendor. This knowledge must be transferred to the end-users if they are to maximize the benefits of IP reuse.
Conclusion
Methodology issues, especially methodology differences between the IP vendor and SoC integrator, hurt the economics of IP reuse. Licensable IP must come with methodology IP designed for reuse in the form of scripts, documentation, and training, to ease the complex problem of integrating IP into SoC design flows. The IP vendor should provide verification assistance targeting the interfaces of the integrated processor core with reusable, extensible tests and monitors that can help debug the complete SoC. For soft cores, the IP vendor must supply reusable synthesis, timing analysis, and formal equivalence checking scripts. These tools are essential in order to unlock the full value of the licensed core.
About the author:
Mr. Watters has over 20 years experience in semicustom design methodology and IP reuse. He holds B.S.E.E. and M.S.E.E degrees from Syracuse University. His previous employers include GE Microelectronics, Compaq Computer, and Synopsys. He is currently managing StarCore Hardware Customer Support and IP Factory organizations.
Abstract
Licensable Processor cores and subsystems include sophisticated IP in soft or hard form. The best licensable IP should be designed for easy reuse in the widest possible arena. This includes flexibility in meeting the final requirements with tool and technology independence wherever possible. Unfortunately, the tremendous value represented by some IP is locked up in methodology issues hampering adoption of OPIP (other people's intellectual property). The best quality IP should come with methodology collateral that is also designed for reuse including verification, synthesis for soft IP, place and route, parasitic extraction and timing analysis.
Introduction
Market requirements and the economics of SoC design force the reuse of IP blocks. Those blocks that are licensed from outside sources represent enormous value that can make or break SoC development depending on the efficiency with which the SoC design team can reuse them. While the IP itself, the result of years of effort, may be in perfect working order with all the views required to embed it into an SOC, the tasks of constructing and verifying an SoC are not helped much and in fact may be made more difficult by the reuse of outside IP. The lack of familiarity and the necessity of absorbing the IP into a design and verification flow go against the benefit of design IP reuse. The problem of familiarity is addressed by documentation and training, while the ease of design flow or methodology adoption depends on reusable scripts and tests that are as tool- and platform-independent as possible.
Along with reusable design IP then must come reusable methodology IP. The parallel efforts of construction and verification depend on synthesis, timing analysis, simulation, and equivalence checking tasks, each with associated tools and scripts that are tuned to the IP in question.
Verification IP Reuse
Considering that verification can dominate the development of a complex SoC, it is fortunate that reusing IP provides the advantage of highly verified blocks. High-quality IP should have been verified extensively using all the best state-of-the-art techniques, from high functional code coverage with billions of random simulations, to actual silicon validation. The end-users of such IP should not have to concern themselves with internal functional verification.
On the other hand, the integration of outside IP within a new SoC requires extensive checking to make sure that the interfaces are correct. There are the mechanical tasks of stitching the pins of the embedded IP block to the rest of the SoC, and the more difficult task of ensuring the communication protocols have been well-exercised by SoC-level simulation. Though there may be many ways of doing this, perhaps the best is through the use of RTL simulation monitors whose task is to observe the interfaces while logging activity, collecting statistics, and watching for protocol violations. Monitors constructed for this purpose, using standard RTL, do not rely on specialized tools and can run on all major simulators.
Once the monitors are in place, all that remains is to run sufficient amount of tests to fully exercise the interfaces. Unfortunately, creating these tests can be a daunting task. In the case of embedded processors though, the IP vendor can deliver a set of tests whose purpose is to walk the interfaces through their protocols. This is only a subset of the extensive test suite the vendor needed to completely verify the IP function. The tests should consist of self-checking processor instructions along with the verification environment elements (stubs) needed to run them, including means of starting the simulations, loading the instructions into memory, logging the monitor output, and providing the pass-fail assessment.
Once the interfaces are debugged, the SoC verification effort can focus on system behavior. he monitors can, in addition, help by providing an alternative to waveform viewing through an easily understood log of what is going on in and around the embedded IP block. Also, the tests provided with the IP can be a very useful starting point for developing system-level scenarios.
Therefore verification IP should consist of tool-independent tests, scripts, monitors, and test bench elements (stubs) designed for reuse and targeted at interface checking and at making debug at the system-level easier.
Synthesis IP Reuse
Soft IP represents a unique set of challenges corresponding to the added flexibility inherent in its form. The freedom to choose process technology and manipulate the tradeoffs between performance, power, and area is limited by the design team’s ability to navigate the maze of synthesis and optimization strategies. Every synthesis veteran knows that finding and scripting a good synthesis strategy that achieves the required results in the least amount of time, is the key to success. And every piece of IP will have its own idiosyncratic best strategy.
Nobody knows the best synthesis strategy for a licensed processor like the IP vendor. Their experience comes from hardening the IP in multiple technologies with different optimization goals. Therefore the end-user of soft IP should expect to enjoy the benefits of that knowledge in the form of reusable and configurable synthesis scripts. There are some methods of making such scripts reusable and configurable. Although the overall compile and optimization strategy may be relatively constant, there are many choices to be made in managing the tradeoffs of power, timing, area, and run time. The best scripts should allow for easy customization, not only regarding the process technology, but also the subtle choices concerning optimization constraints and effort, scan architecture, and floor planning. These scripts should isolate these choices in a separate section of user-selectable parameters with error checking and default settings representing the best mainstream approach. This way, the end-user can quickly make appropriate choices without having to reverse-engineer the gory details in the scripts and without risking introducing a bug into such scripts.
The timing goals for synthesis are driven by a set of constraints describing the clocks and boundary conditions for the IP block. If these constraints are incomplete then serious problems can remain undetected, since timing analysis depends on the boundary conditions completeness. Having a complete set of constraints that are customizable is an important part of the reusability of licensed IP. The scripts for timing analysis should share these constraints with the synthesis process and allow for the annotation of backend extracted parasitics for final sign-off. Having parameterized, flexible, and complete constraints for soft IP with built-in examples and error checking facilitates the entire implementation process.
Formal Equivalence Checking
At each stage of the synthesis process, it is wise to use formal equivalence checking tools to verify the resulting netlist. Clock-tree insertion and scan insertion often involve several steps and other tools. Occasionally, a catastrophic error can be introduced into the resulting netlist, that can be best detected by formal checking. This involves yet another set of scripts that contain some best-practice experience from the IP vendor. Formal checking of complex processor cores can be time-consuming at best and may involve subtle tricks to get through the complex logic. Again the IP vendor can assist the SoC design team by providing reusable equivalence-checking scripts that will save time and avoid critical bugs.
Documentation and Training
IP customers are well aware of the need for extensive documentation and training for the IP itself. They should also look for methodology documentation and training covering the integration and reuse tasks they face, to successfully incorporate the IP into their SoC design. Even the most reusable core will poses challenges in synthesis, verification, timing analysis and equivalence checking, that are understood by the IP vendor. This knowledge must be transferred to the end-users if they are to maximize the benefits of IP reuse.
Conclusion
Methodology issues, especially methodology differences between the IP vendor and SoC integrator, hurt the economics of IP reuse. Licensable IP must come with methodology IP designed for reuse in the form of scripts, documentation, and training, to ease the complex problem of integrating IP into SoC design flows. The IP vendor should provide verification assistance targeting the interfaces of the integrated processor core with reusable, extensible tests and monitors that can help debug the complete SoC. For soft cores, the IP vendor must supply reusable synthesis, timing analysis, and formal equivalence checking scripts. These tools are essential in order to unlock the full value of the licensed core.
About the author:
Mr. Watters has over 20 years experience in semicustom design methodology and IP reuse. He holds B.S.E.E. and M.S.E.E degrees from Syracuse University. His previous employers include GE Microelectronics, Compaq Computer, and Synopsys. He is currently managing StarCore Hardware Customer Support and IP Factory organizations.
|
||||||
Related Articles
- Debugging complex RISC-V processors
- It's Just a Jump to the Left, Right? Shift Left in IC Design Enablement
- A closer look at security verification for RISC-V processors
- Radiation Tolerance is not just for Rocket Scientists: Mitigating Digital Logic Soft Errors in the Terrestrial Environment
- Using edge AI processors to boost embedded AI performance
New Articles
Most Popular
|
E-mail This Article | 
|
|
Printer-Friendly Page |