Platform to Validate SoC Designs and Methodologies Targeting Nanometer CMOS Technologies

Platform to Validate SoC Designs and Methodologies Targeting Nanometer CMOS Technologies.
Samuel Picchiottino, Mario Diaz–Nava*, Benoit Foret, Sylvain Engels, Robin Wilson
STMicroelectronics, Crolles, France
*STMicroelectronics, Grenoble, France

Abstract:

Given the complexity of System on Chip (SoC) development in nanometer CMOS technologies, it has become essential to validate all design aspects and methodologies to be used prior to a SoC product development. Until now point tool validation has been the main approach used, validating independently each tool, method and concept used in SoC development. At ST, we have developed a dedicated test vehicle TC4SoC to allow a complete validation of a SoC development environment. In this paper, we will describe the TC4SoC, review the validation made using this design and comment on the advantages of this new approach over and above traditional ones.

1. Introduction

Given the complexity of System on Chip (SoC) in nanometer CMOS technologies, it is necessary to validate SoC development systems (design flow, methodologies, IPs and technology) in advance of their usage for real product design. Without validation, the development times become unpredictable as design teams struggle with tool and methodology issues rather than advancing their product design.

Today SoC design flows cover a very wide range of tools and methodologies requiring also a wide range of expertise, starting from system level entry and verification environments, architectural exploration, software development platforms, application board development, hardware emulators, through to the full range of IC design back-end tools and methodologies. Furthermore with nanometer CMOS technologies there is also a wide choice of technology options (low power, high speed, low leakage, etc.), libraries (basic cells, memories, …) and complex IP available. In our view to insure first time silicon success for a SoC product development for a new introduced technology, it is necessary to show that the complete development system works well and that it has been validated on a real design example.

Furthermore, during the development life cycle of a SoC, new tools and methods will become available, it is often necessary to evaluate if adoption of new methods or adaptation of existing methods would benefit a project. Therefore it is necessary to have a solid benchmarking capability that allows rapid evaluation to determine whether to adopt a new technology on a project.

An important aspect addressed using the TC4SoC was the possibility to validate complex IPs in an easy way before they were released to the product SoC developers. This allowed an in situ validation of IP in a realistic environment, allowing the uncovering of any remaining bugs not found via standalone validation. This approach insures high IP quality and allows reduce time and consequently development costs and time to market.

To that end, it was necessary to choose a design, for SoC design and development methodology, satisfying the following criteria: 1) The design had to be representative of a SoC in terms of performance (complexity, speed), architecture, and content. 2) The design had to be simple in such way that it could be understood easily by the different development teams that would work with it. 3) The design had to be easily adaptable allowing the addition or removal of IP as required. 4) We also wanted to validate specific technology aspects such as process options and performance. In fact, there was no design that satisfied all of the above requirements, hence we developed the Test Chip for System-on-Chip (TC4SoC), described in detail below.

Figure 1: TC4SoC macro-architecture

2. TC4SoC Description

TC4SoC is a SoC platform [4] based on a STBus1 architecture [3]. The different IP's are directly connected to the STBus. They can be grouped into 2 families: Initiators and Targets. As initiators, there is an ST230, a 32 bits VLIW CPU with a 400 MHz clock and 4-issue per cycle providing up to 1.6 GOPS. Other initiator IP's are a PCI interface, a DMA and an I/O STBus port, giving a direct access to the on-chip bus from the external world. As for targets, there are a DDR interface with a data rate of 256Mbytes/s at 266MHz, a PCI interface as well as 2 UART ports and finally a STBus port configured in target mode. Embedded memories (8Mbits eDRAM, 2Mbits eSRAM and 4Mbits eROM) are also connected to the bus as target blocks.

To monitor the on-chip bus ports, a system bus analyzer with trace messages is instantiated, providing traffic information as bandwidth, latency and priorities. A debug port is also implemented, providing a debug link interface to the core. A block diagram of TC4SoC is given in Figure 1.

3. SoC Integration Solutions

Following a platform based-design, we have assembled all the required IP's prior to system integration. The first step was to build the central on-chip bus. The STBus development system includes a powerful and versatile toolkit allowing to define and implement a STBus interconnect system in an easy way. The STBus toolkit is composed of two main tools, the System Level Design tool allowing the definition of the STBus architecture from the specifications and the Silicon Design tools allowing the generation of the RTL view (VHDL) and the gate level netlist based on the STBus interconnect architecture. The System Level Design tool is based on CoWare N2C, an environment that helps SoC designers to bring an idea or concept from its specification to its implementation on silicon. In this step, the designer specifies the system, the partitioning and the hardware implementation. The Silicon Design tool is based on Synopsys CoreAssembler. This tool takes, from the System Level Design phase, the interconnect specification in terms of interfaces and hardware implementation including the choice of IP's and their parameters. Then, the Silicon Design flow assembles the IP's constituting the interconnect. These IP's are, the node or arbitration unit (arbitrates requests/responses and routes the information on the bus), type converters (as STBus supports three protocols), size converters (in order to let communicate IP's of different bus sizes), frequency converter and register decoder. Once the tool has assembled and generated the interconnect RTL, the gate netlist can be produced. Other plugins are present in the flow such as Formality, Timing Analysis and verification Testbenchs for Verisity.

Once the interconnect is built, the system assembly remains. This step was manual for TC4SoC but to increase productivity in the future, a tool to rapidly create, configure and verify platform based SoC designs will be used. During this project, two tools from different vendors were benchmarked to establish a design flow: Platform Express from Mentor Graphics and Magillem from Prosilog.

The Platform Express environment enables design teams to build and configure a platform core and its corresponding peripherals and software in a virtual prototype. Platform Express automatically creates the necessary connections between components depending on the STBus standard protocol. Simultaneously, it generates a custom verification environment and displays automatically the system memory map. This Platform-Based Design methodology supports and generates complete hardware and software SoC designs, as well as a verification environment required to validate the design implementation.

The Magillem [5] environment targets the specification, verification and implementation of complex SoC. It handles system description both at transactional and RTL levels. The benefit of using these tools are that a platformbased SoC can be implemented very rapidly free of connection errors as interfaces respect to a standard protocol. These tools also allow the creation of hardware and software verification environments quickly and thus validate easier the embedded processor and the logic surrounding it. By shrinking design development time, the team can emphasize its focus on product differentiation.

TC4SoC has proven to be an ideal vehicle to validate the design and development flow and tools from specification through to gdsii.

4. TC4SoC Verification

a) Key IP verification

IP's with a STBus interface are first of all verified and validated in a stand-alone mode using two tools: Specman from Verisity and property checking with Rule base. However an IP must be put in the context of a real system to be exhaustively validated. TC4SoC has been used to put in a real context a number of IP's under development at the time of the integration, for instance, the eSRAM/eROM and the eDRAM with its pipeline interface. The TC4SoC design enabled us to directly plug-and-play an eSRAM/eROM or an eDRAM on an STBus interconnect. Executing programs, in the ST230 core, and validation scenarios on the testbench platform enabled the uncovering of three bugs that were not detected in a stand-alone mode.

A big advantage provided by the TC4SoC platform is the possibility to validate, in a real SoC environment, any IP compatible with the system bus.

b) SoC verification

To functionally verify the TC4SoC, software and hardware platforms have been used. The software platform is mainly based on Specman from Verisity and the ST200 cross development tool-set to develop and validate by simulation, the ST230 programs. A common testbench was built, incorporating STBus, PCI and UART eVCs as well as a DDR behavioral model. From STBus and PCI initiators eVCs, all the stimuli required to validate the SoC can be driven. Different scenarios have been created in order to excite all IP. To stress the system, all initiators have to generate stimuli simultaneously. The ST230 boots from an external memory plugged on the STBus target port and then the program is executed. ST230 programs were written to facilitate the test of the different IP's and the complete TC4SoC architecture.

To validate more exhaustively the TC4SoC design, two hardware platforms (Palladium from Cadence and Xtreme from Axis) were used to emulate the SoC and execute complete programs. An essential point was the validation of the ST230 debugger interface.

TC4SoC was mapped in less than three weeks by the emulation vendors themselves with minimal support from the TC4SoC design team, allowing to quickly develop software on TC4SoC platform. Previous experience of mapping SoCs to design emulators required a minimum of two months work to map such a design, with significant design support required, thereby showing that TC4SoC being an ideal vehicle to evaluate such technologies.

5. Bus Monitor / ST230 Debugger

On-chip interconnects are no longer just simple buses, they are much smarter. Features have been added to dynamically configure the interconnect in term of arbitration algorithm scheme, priority, bandwidth and latency schemes. In order to have an observability on the on-chip bus (OCB) and on performance of the chip following the configuration, we have developed at ST an On-chip STBus Traffic Analyzer called SBATM [2]. Traffic is generated by executing programs and then the bus performance can be monitored. The bus analyzer embedded in the system generates trace messages that are sent to an external acquisition board and stored on a host for later processing. Post processing, the OCB traffic is characterized in term of priority, bandwidth and latency. All this information is precious to software team in order to have application programs that really fit the SoC implementation requirements and thus maximize the performance.

To facilitate the bring-up of the complete system, an STmicro-connect (ST proprietary micro debugger) can be plugged on a JTAG port accessing the ST230 core DSU, Debug Support Unit. TC4SoC can be configured in debug mode, which is a privileged mode where the machine operates in supervisor mode, allowing full access to DSU registers and other privileged resources from the external debug unit. The host, STmicroconnect, can read from or write data to the ST230 memory space using peek and poke operations. The DSU allows ST230 code and hardware to be debugged from the host by giving debuggers direct access to the ST230 core, and thus to the system.

Such technologies will be used when a real application is run on the TC4SoC application board.

6. Test Methodology

TC4SoC has been used to evaluate new DFT methodologies such as deterministic logic BIST (LDBIST) and the new P1500 protocol. SoCBIST from Synopsys has been used to implement LDBIST and CoreTest which enables P1500 protocol by wrapping IP's.

The DFT strategy adopted on TC4SoC has been the following: three IPs have been wrapped using CoreTest: ST230, DMA and PCI interface. This methodology of wrapping IPs provides access to an IP from the top level and enables the direct application of test patterns. Thus, test patterns for IPs can be reused for different products. The remaining logic, have been wrapped and LDBIST has been implemented on this so called User Defined Logic (UDL in Figure 2). Compared to full scan, SoCBIST provides significant savings in test cost by reducing test time and data volume, while deterministically retaining scan's very high fault coverage regrouped under scan collar, transition and bridging faults. For TC4SoC, LDBIST shows a pattern compression ratio of thirty in terms of data volume and a test time reduced by five. Figure 2 shows the different DFT techniques used in the TC4SoC.

The TC4SoC was an ideal vehicle to validate these new technologies as due the scale of the design we were able to complete all steps from design through to layout and test pattern generation in a reasonable timeframe, in line with the development schedules of the tools being developed and in advance of deployment of these technologies on other products.

Figure 2: mixed LDBIST, CoreTest and scan

7. Technology Demonstrator

The TC4SoC was designed to demonstrate the major features of a state of the art nanometer (90nm) CMOS technology and the design system required integrate these features.

The major features that we wished to demonstrate were the following, Triple Well, Dual Gate Oxide, Multiple Vt's, dense SRAM and DRAM, Multilevel metal. It was though careful choice and specification of this design that the above issues could be stressed and thereby validated. The important point here is that decisions on technology choice have to be made at the outset of a project. To achieve this, all the necessary information to take these decisions has to be available at the specification stage. We have demonstrated this approach through TC4SoC, in that area, speed, power and cost targets set at project outset were met.

The target performance for speed and leakage was met through the appropriate usage of multiple Vt transistors. Memory requirements and die area targets were met using an embedded DRAM technology. Dual Gate Oxide has allowed the integration of the high speed I/O's and analog IP's, multi-levels of metal were used to both meet the required area and voltage drop targets.

Furthermore in modern processes that allow the integration of large quantities of memory, it is also necessary to integrate sophisticated memory redundancy schemes. Here again, we have shown that the ST 90nm Memory Platform was production ready and all IP and fusing technologies available and were be seamlessly integrated on this chip.

The TC4SoC has proved beneficial in the development of the 90nm CMOS design platform in that it is demonstrated that all the above options can co-exist at all levels of the design and technology platform.

8. IC Integration Tools:

The TC4SoC was used to successfully validate a number of IC integration tools; again, here, the benefit of such a design became very apparent. For each case so far we were successfully able to deliver a complete database, with minimum support to the engineers validating the solution. Two design examples are provided below:

a) IC packaging tools:

The TC4SoC is representative of a particular packaging/assembly style referred to as "Class M" it also contained a DDR interface that requires careful treatment while placing pads and analyzing impact of bonding. This design was successfully transmitted to the packaging tool team who were able to validate the solution for future SoC's with a similar requirement. This design is now included in the regression test suite for IC packaging tools. Figure 3 shows the bonding of 437 signals (including power supplies) of the TC4SoC in a 500 pin BGA package

Figure 3: TC4SoC Bonding

b) Voltage Drop Analysis:

A new voltage drop analysis methodology was also validated using this test-chip vehicle, the particularity is that this method involves making different analysis with increasing levels of precision as the design advances. The TC4SoC was ideal to benchmark this method as the delay between each step of the design flow was radically reduced with respect to a more complex device. It was possible to identify at which point all data required could be made available in the context of a real design environment. Run times were also very satisfactory allowing the proving of this new methodology on a significant example, before applying on other products.

Figure 4: TC4SoC Vdrop analysis

9. Conclusion

When design tools are benchmarked using real products as examples, engineering time from the original design team is required to provide data, analyze results and prove the validity of new tools. In the case where tools are shown to be immature this effort can impact a design schedule with no real benefit. Therefore the approach of validating using a representative chip in advance of real products can insure that only sufficiently mature tools are introduced to SoC development flows.

In this article we have outlined a new approach followed when new nanometer CMOS technologies, methodologies and tools are introduced for SoC design and development system validation. This entails using a representative design, TC4SoC to validate all steps from specification through to application board and software development. We have demonstrated this concept for the validation of SoC integration solutions, SoC Validation Systems, Key IP Validation, Technology Choice and Integration, Design Integration tools, Test methodology, Silicon validation of SoC related IP. This concept was successfully applied for a 400 MHz VLIW based SoC using a 32-bit 133 MHz STBus interconnect and successfully implemented in a leading 90nm CMOS technology.

Acknowledgements to all the people involved in TC4SoC project and more specifically: O. Bayet, J.G. Bonneault, L. Ducerf-Baudot and C. Cochard.

REFERENCES

[1] P. Magarshack, P. Paulin, System-on-chip Beyond the Nanometer Wall, DAC, 2003

[2] B. Ramanadin, JF. Vizier, C. Bertaux, SBATM: On-chip STBus traffic analyzer, International Workshop on IP-Based SoC Design, 2003.

[3] The STBus spec (protocol, concepts and layers) is now public: http://www.stmcu.com/inchtmlpages- STBus_intro.html

[4] Datasheet TC4SoC: ST230 Evaluation device. STMicroelectronics, Version 3.0, June 2004.

[5] Press article, Prosilog demonstrates the integration of the TC4SoC Platform for STMicroelectronics with Magillem as per SPIRIT guidelines.