Cadence Design Chain LSI's Kazim Shami issues a wish list ...
Shami set up the talk by describing three separate data communications designs, with highly disparate characteristics and requirements. The first circuit is a 24 + 2 gigabit Ethernet switch and router comprised of 5 M gates and 5 Mb of memory. This enterprise-class chip was about 25 percent existing circuitry and IP and 75 percent new design. The second chip is the ASP platform with 3 M gates of logic and 5 Mb of memory. This chip was about 80 percent existing IP and designs and 20 percent new. This chip is intended for use in high-volume and low cost products. The third design was an ADSL (Asymmetric Digital Scriber Line) modem consisting of 1.2 M gates and 1 Mb of memory. This chip has the worst case cost structure, it needs communications class reliability at consumer prices. The other aspect the three chips have in common is their very large software content necessary for operations. In all of these platform-based designs, the complexity is very high, with the number of IP blocks is going to over 100 blocks, and IP integration has become the biggest bottleneck. The increase in software content is both a development issue and also a design integration issue, since the chip cannot go to evaluation and characterization without all the software. The software component of the designs creates a need for different tools and approaches in the design flows. As a consequence, all their platform-based designs now include software development systems to be available with the first silicon. The platforms enable multiple applications by only changing software and a limited portion of the chip. LSI uses a 3-tier approach to verification. They extensively simulate the individual blocks through multiple runs with various testbenches and regression suites and also use tools like Specman for uncovering hidden behaviors. At the chip or system level, they run new IP on FPGAs and develop test suites that take advantage of the processor-dependent architectures. There is a lot of work in eVC (e Verification Component) and SVE (spec-based verification environments) to check the classes of test necessary to check the overall chip integration, performance, and system functionality. Finally, they have to create a FVE (Functional Verification Environment) which is a software development platform. They use the embedded CPU as the system brains and create multiple scenarios to stress the various parts of the design they also use FPGA implementations of the design for platform acceleration. All of the designs are very complicated, because the overall process must address multiple block interactions. To ameliorate the issue, they measure the quality of testing with functional and code coverage tools as well as traditional design reviews. The coverage metrics are not used to get to 100 percent coverage, but to put bounds on the completeness of the testing. In all phases of verification testing, they use software simulation as the main verification methodology. They have a legacy directed test environment, a constrained random verification environment with the use of reference models. In most cases, they didn't use emulation due to the lack of time and to the existence of analog/ mixed-signal components in the design. Verification strategies vary with the design. No single methodology works for all designs. The optimal verification strategy depends upon the design features. The applications need to address such characteristics as number and type of embedded CPUs and buses. The devices have distinct specifications and characteristics such as number of gates and clocks, number of new and old IP blocks, and unique or special specifications. In addition, the marketing requirements such as a unique part or part of a family of parts, time to market, software needs, and standards compliance and interoperability may be important. So LSI will pick from the various verification methodologies and flows to get a best one for each project. The tools will be matched to the team experience to minimize learning curve time and maximize verification throughput. Shami noted on his wish list, some tools that would make the jobs easier. One is a product specific tool flow that can generate device or product specific verification methodologies. There should be some base verification platforms and project management infrastructure. The project management challenges include the need and ability to schedule across multi-site verification teams with accurate progress monitoring and reporting. The data collection and management issues include the identification of non-standard IP offerings and the ability to manage simulation and verification loading. Because of the high software content, some form of software QA is becoming increasingly important. Project plans need greater abilities to predict schedules with accuracy. Because issues like bug discovery and fix times are open-ended, and late design requirement changes are a fact of life, the increased chip complexities just add to the overall uncertainty. Past project experience and expertise help verify the environmental effectiveness, but tools to capture the process knowledge and domain expertise are becoming necessary. A schedule estimator that has as input parameters design and verification complexity and expertise could more accurately predict and update design schedules. ******************************** November 8, 2005 Long time EDA industry observer Tets Maniwa can be reached at maniwa_at_sbcglobal.net
|