English
Automation in IP based SoC development: Case study of a media processor subsystem
Haridas V, Ramchandra V, Santhosh K, NXP Semiconductors
Bangalore INDIA
Abstract:
An IP based development methodology for building system-on-a-chip solution is described. The methodology is illustrated through a memory centric SoC architecture template intended for streaming data applications such as video and audio. This template provides a basic computation framework and realized by integrating the IP’s from a reusable IP portfolio including necessary software components. An automated development and verification methodology is proposed that can address the platform level configurability, efficient system integration and verification.
1. Introduction
Market pressure such as integrating more functional features with reduced time to market, prize and narrow product life cycle etc. are creating heavy pressure on the SoC design teams and the designers are not able to cope up with the standard reusable IP based SoC design methodologies. The only ways to handle such requirements are by having the following approach.
2. Current SoC development approach
In traditional SoC development project, the system is build around multi sourced discrete hardware and software components. The major issues with such approaches are the following.
Figure[1] Key challenges in IP based SoC development
2.1 Architecture challenges
Multi processor core methodologies are introduced in the embedded SoC domain to take care of increasing processing power requirements and at the same time taking care of key technology challenges such as power and memory bandwidth [1] [2]. In a typical architecture this is accomplished by the following way.
Efficient communication (on chip & off chip connectivity): Most of today’s application requires extreme processing power and throughput requirements. Mapping this to the SoC hardware real estate within a reasonable silicon cost is a great challenge to the SoC architect.
System level power management: Power management at system level is a trade off between several factors. Achieving reasonable power consumption without compromising much on the performance require careful analysis of system level requirements and good co-coordinated approach between the hardware and software elements of the system
System level debug: Today system developers use modern software tools to generate increasing amount of application software that get mapped to multiple processing units in a SoC. Most of the performance driven applications also makes use of hardware accelerator units in addition to the programmable cores. Here a system level debug approach is a must that can debug the system in a most appropriate non intrusive manner, and at the same time provide synchronized debug capabilities between cooperating software and hardware units within a reasonable silicon cost.
System level software infrastructure: Most of the time the low level software running on the SoC will have tight coupling with the interacting hardware elements, and if not given sufficient attention can result in a less efficient system. This may include the software drivers, operating systems, and the basic communication infrastructure realized at the operating system level.
Looking into the above requirements one can see that most of the challenges need careful attention, and lots of investments. In an IP based SoC development approach, the requirements listed above has to be taken care by the different IP building blocks. A strong representative IP portfolio along with standardized interfaces and configurability is one answer to the above problem. However the key challenge remains is the assessment of different IP configuration at SoC level, and this need to be done within a reasonable budget (time to market).
This can be taken care by having an automated development environment that can be used to evaluate the SoC requirements against the different IP building blocks. This involves trying out different IP configurations against the architectural requirements and building the SoC subsystem. In this paper we will walk through the development of multi core video subsystems and the development methodologies followed.
2.2 IP level challenges
The following are the key requirements from a SoC perspective that need to be addressed by the IP provider.
Architecture evaluation: In an IP based SoC development, typically a bottom up approach is deployed, where in different IP components are stitched together to create a SoC. The key challenge here is in mapping the SoC requirements into the individual IP blocks and choosing the right IP configuration. Multiple abstraction views (ESL, RTL) of the IP along with automated integration environment is the answer. This can provide a good tool to the SoC architect to evaluate the system against its requirements in a reasonable time.
Integration: In an IP based SoC development, integration has to be performed by an automation tool. The IP should support this automation approach in two ways.
A) By providing a standardized view for the automation tool to integrate the IP against a well-defined integration rules at the SoC level (e.g. SPIRIT XML [4]).
B) The automation tool can decide what configuration of the IP (choosing the IP configuration based under SoC context) needs to be extracted and the extraction process itself can be automated.
Verification: In its true sense, IP reuse is not complete without verification reuse. In a processor core based development; a software based verification methodology is more appropriate. There is a possibility to automate this too, provided the IP provider can supply the software views of the in a standardized format. We followed a verification software based approach that can create the verification software and verify the IP from both interconnectivity and interoperability perspective.
2.3. Tools & standards
Standards are the key for the success of any IP based Soc development approach. Standards enable seamless integration of IP cores from different vendors into the development flow. This also enables automation in integrating and verifying the IP at SoC level. Industry is already working on this aspects both at standardization level as well as at the EDA level. In this paper we explain how we adopted to this initiative by using SPIRIT [1] (Structure for Packaging, Integrating and Reusing IP within Tool-flows) standard and EDA flow based on mentors platform express.
In order to aid the IP based SoC development methodology and automation described above, one need to have strong IP portfolio that get linked with automated development flow for architectural evaluation, RTL integration and verification. In this paper we describe an IP yellow pages concept that can aid automatic extraction and configuration of the IP by specifying the correct IP parameters.
3. Example system
The methodology described earlier will be described here with a multi core video processor subsystem. The figure below represents the top-level view of the hardware architecture.
Figure [2].Multi core sub system functional blocks
The architecture is a memory centric one. The basic intention is to reduce the on chip memory cost by choosing an external memory for both instructions as well as user data. A modular approach is followed in realizing the system. The system is partitioned into various functional sub systems and later integrated at the top level. This will help in easy integration, scalability and configurability.
The major functional elements are the following
3.1. Controller sub system: This is realized by using an ARM926EJS processor [1]. This processor act as
3.2. Data processing engine:
A VLIW architecture based TriMedia (NXP solution) TM3271 media processor is used as a data processing engine. This processor contains highly specialized architecture for real-time media processing and utilizes significant parallelism and architectural optimizations to achieve real-time processing. External accelerators (not part of template) may need to be connected for specific video protocol processing.
3.3. Memory sub system:
The data communication infrastructure plays a major role in the SOC architecture for a number of reasons. The large amounts of temporal (e.g. video) data have to be transported between the processing core to IP blocks, via memory or directly. The combination of cores, processors, and interconnect must guarantee the hard-real time requirements of the application. Resource management (arbitration) of computation (e.g. real-time operating systems), communication (e.g. traffic classes with different performance), storage (by the external memory controller), and their combinations are essential.
3.4. IPC communication:
In a multi processor system, an efficient inter processor communication channel is a must between the co-operating processing elements. This Channel can be established through inter processor communication modules or through shared memory. Control and status information’s between the processing elements are passed through this channel in both directions. It has a low data rate, but requires low latency to minimize the system response time.
3.5. Peripheral sub system:
This module contains the standard peripherals for both ARM and Trimedia. The standard peripheral sets are duplicated for both processing elements. This is done to make sure that no dependency arises from software viewpoint. The standard peripheral sets are divided into the following category
3.6. System Software view
A simple form of multiprocessor operating system is organized in this system with a master linux kernel running on ARM9 and a slave PSOS kernel on TriMedia. The master processor determines the schedules for itself and the slave processor. The slave simply runs the processes assigned to it by the master. This organization scheme is conceptually simple and easy to implement. The master processor keeps all the information that is needed for scheduling. The kernels on each processor are responsible for managing purely local resources, such as devices that are not visible to other processors, and implementing the decisions on global resources (e.g. system shared memory).
Figure[3]. Multi processor software view
4. Automated design integration and verification flow
The system described above contains many IP components that get integrated at different hierarchy levels. All these components are to be typically customized (configuration) to meet the architectural requirements. Configurable IP offers a solution to the problem above by allowing the system integrator to set up configuration parameters through a script that configures the block according to the parameters. However to implement such feature in an automated way, the basic configurable architectural intellectual property (IP) blocks are needed in a standardized (Standardized views are required in IP deliveries, documents, and an electronic description of the IP etc.) machine-readable form, so that this can be pushed into an automated design and verification flow. The system integrator can evaluate the IP configurations against the system requirements by quickly integrating the system and evaluating the same. If the design requirements are not met, then different configurations of the IP can be tried. This provides options to the integrator in analyzing the requirements and how it matches with the IP configuration parameters.
Nx-Builder (next generation SoC builder) is the standard design environment used in realizing the project, that addresses the requirements listed above through extensive utilization of architecture, IP reuse, efficient system integration, hardware-software (HW-SW) co-verification and design flow automation. Since this is based on industry standard (SPIRIT [4]) for design integration and advanced commercial design technologies, Nx-Builder helps in correct-by-construction designs and allows rapid development of new systems from platform templates as well as platform derivatives.
Figure [4] Nx-Builder environment.
Nx-Builder is a development environment with a GUI (figure [4]), based on the third party EDA solution called Platform Express from Mentor graphics [5]. Nx-Builder contains APIs with NXP specific extensions as well as a number of generators that extend the platform express capabilities and also provide new flows such as Verification, Synthesis, DFT (Design for Testability).
An important part of the Nx-Builder is the link to NXP internal technologies like IP Yellow Pages (IP repositories). IPYP is a web based service that offers designers an easy way of accessing the IP they require from the IP repositories. The Nx-Builder extends the platform express functionalities to adapt NXP specific design flow.
Figure [5] shows the relationship between the IP libraries and the design environment. On the left is a NXP internal IP repository consisting of IP views. Layered on top are additional XML metadata descriptions and special generators that are invoked to fully configure the IP based on their context in the system being built. On the right is the Nx-Builder design environment that executes the generators creating IP descriptions based on user parameters. Generator chains handle design flows that check IP compatibility, integration and top-level design view generation.
Figure [5]. Nx-Builder link with IPYP
4.1. How Nx-Builder is used in the developmental flow:
During the project execution the Nx-Builder environment is used in three main phases.
Architecture Exploration and early Software development: The IP libraries in the Nx-Builder platform enable the user to quickly construct the architecture and explore various aspects like performance of the system, hardware and software dependencies, architecture pitfalls etc. It also enables to integrate any third party libraries (IP’s) into the platform. It provides easy integration of the software tests to be executed on the host platform and check against the hardware. This brings the value addition in terms of identifying the architectural issues and software dependencies with minimal effort and time in the initial phase of the development.
Nx-Builder platform [6] allows change/choose the processor models, the booting method, the memories, the infrastructure peripherals, the configurations parameters of the IP components connected, system memory map, the software tests execution etc. through an easy graphical based user interface. It also enables easy debugging of hardware and software in a co-simulation environment (seamless from Mentor Graphics, Cadence NC-SIM, X-RAY debugger for software etc.). The flow provided in this platform allows the user to easily switch between CPU simulation models, memory models (behavioral, RTL) and simulation (RTL, net list) without the rebuild thereby exploring the architectural issues quickly upfront.
IP Integration: Integrating IP into the Nx-Builder design environment involves a number of discreet steps. Fixed IP is integrated as a XML view [7]. Configurable IP is integrated as a ‘black box’ representation in XML followed by a number of steps to translate parameters into a fully configured XML view together with its verification views. The translation process involves writing a generator using an API to request a configured instance. The ‘black box’ XML contains interfaces to compatible bus structures. If new interfaces are required then new bus definitions and decoders have to be abstracted in XML. Not all steps are mandatory; this depends on the type of IP. A typical integration flow is shown in the following figure [6].
Figure [6]: IP integration flow
IP Verification: The verification software architecture defines the components of the verification software [8], their interrelations and their relations with the hardware to be tested. The various software architecture components used in the platform are IP test component, HAL/HAPI component, chip context, test application, Hardware IP. HAL (Hardware Abstraction Layer) describes the register abstraction of a hardware device. It defines the manner in which registers can be programmed and standard naming conventions etc. HAPI (Hardware Application Program Interface) provides a set of hardware and software implementation independent interfaces for diagnostic software to configure and enable central resources like interrupt controllers, DMA controllers, reset controllers and clock generation units etc. Figure [7] shows the verification software architecture. The verification software is intended for checking the interconnection between components in a sub system. The software tests are categorized based on testing generic and IP specific functionalities thereby testing the whole sub-system/SoC. The generic tests would perform the read/write to the IPs with specific patterns thereby ensuring the interconnectivity and interoperability. The IP specific tests would exercise the application interface of the system.
Figure[7]. Nx-Builder verification software flow
5. Results and summary
A quantitative assessment of the effort required to create the SoC subsystem against a tradition approach is not carried out as a part of project. In this automated approach most of the effort primarily goes in creating standard views for IP’s and validating their integration in a SoC environment. For highly configurable IP’s this is still a challenge. However this is a one time effort. This can clearly benefit derivative SoC design in a big way.
At a qualitative level the following can be considered as the clear value addition by using this methodology
System level design productivity: Automated development environment enables quick integration and evaluation of the System. Architectural choices can be made in less time by evaluating different architectural possibilities. Similarly the environment also facilitates to implement system level infrastructural needs such IP level power management at system level, external connectivity needs including physical layer, and system level debug infrastructure.
System level verification productivity: A unified, integrated, hardware-software platform forms a complete development environment for system-level functional verification of hardware IP as well as for simulation of software IP. Infrastructure for performing functional verification & performance evaluation are also in place.
Faster time to Silicon: By encapsulating multiple types of standardized peripheral IP and software stacks into a single development environment
Minimizing risk: The system described above is verified at HW/SW interaction level including software drivers and operating system. Also it is possible to create a verification coverage matrix including performance.
8. Reference
Bangalore INDIA
Abstract:
An IP based development methodology for building system-on-a-chip solution is described. The methodology is illustrated through a memory centric SoC architecture template intended for streaming data applications such as video and audio. This template provides a basic computation framework and realized by integrating the IP’s from a reusable IP portfolio including necessary software components. An automated development and verification methodology is proposed that can address the platform level configurability, efficient system integration and verification.
1. Introduction
Market pressure such as integrating more functional features with reduced time to market, prize and narrow product life cycle etc. are creating heavy pressure on the SoC design teams and the designers are not able to cope up with the standard reusable IP based SoC design methodologies. The only ways to handle such requirements are by having the following approach.
-
By choosing a programmable core based architecture, so that more and more functionalities can be added in software with out having a lengthy ASIC re-spin.
-
By choosing an automated platform based development methodology that can address IP reuse, verification reuse and platform level configurability.
2. Current SoC development approach
In traditional SoC development project, the system is build around multi sourced discrete hardware and software components. The major issues with such approaches are the following.
-
The IP’s are typically multi sourced. Compatibility (data base, bus protocols etc. are examples) and organizing support are the key issues here
-
The design team may require extensive training in specialized hardware and software associated with each IP resulting in lengthy hardware/software integration and verification
-
May take long time to solve system level issues (e.g. system level power management, system level debug infrastructure etc.).
Figure[1] Key challenges in IP based SoC development
2.1 Architecture challenges
Multi processor core methodologies are introduced in the embedded SoC domain to take care of increasing processing power requirements and at the same time taking care of key technology challenges such as power and memory bandwidth [1] [2]. In a typical architecture this is accomplished by the following way.
-
The control processing (asynchronous control flow traffic) domain handled by a microcontroller (CPU).
-
One or more data processing engines (e.g. DSP’s) along with application specific hardware accelerator for constant rate data flow computations. There are many VLIW based architectures are available well suited for this kind of applications [3].
Efficient communication (on chip & off chip connectivity): Most of today’s application requires extreme processing power and throughput requirements. Mapping this to the SoC hardware real estate within a reasonable silicon cost is a great challenge to the SoC architect.
System level power management: Power management at system level is a trade off between several factors. Achieving reasonable power consumption without compromising much on the performance require careful analysis of system level requirements and good co-coordinated approach between the hardware and software elements of the system
System level debug: Today system developers use modern software tools to generate increasing amount of application software that get mapped to multiple processing units in a SoC. Most of the performance driven applications also makes use of hardware accelerator units in addition to the programmable cores. Here a system level debug approach is a must that can debug the system in a most appropriate non intrusive manner, and at the same time provide synchronized debug capabilities between cooperating software and hardware units within a reasonable silicon cost.
System level software infrastructure: Most of the time the low level software running on the SoC will have tight coupling with the interacting hardware elements, and if not given sufficient attention can result in a less efficient system. This may include the software drivers, operating systems, and the basic communication infrastructure realized at the operating system level.
Looking into the above requirements one can see that most of the challenges need careful attention, and lots of investments. In an IP based SoC development approach, the requirements listed above has to be taken care by the different IP building blocks. A strong representative IP portfolio along with standardized interfaces and configurability is one answer to the above problem. However the key challenge remains is the assessment of different IP configuration at SoC level, and this need to be done within a reasonable budget (time to market).
This can be taken care by having an automated development environment that can be used to evaluate the SoC requirements against the different IP building blocks. This involves trying out different IP configurations against the architectural requirements and building the SoC subsystem. In this paper we will walk through the development of multi core video subsystems and the development methodologies followed.
2.2 IP level challenges
The following are the key requirements from a SoC perspective that need to be addressed by the IP provider.
Architecture evaluation: In an IP based SoC development, typically a bottom up approach is deployed, where in different IP components are stitched together to create a SoC. The key challenge here is in mapping the SoC requirements into the individual IP blocks and choosing the right IP configuration. Multiple abstraction views (ESL, RTL) of the IP along with automated integration environment is the answer. This can provide a good tool to the SoC architect to evaluate the system against its requirements in a reasonable time.
Integration: In an IP based SoC development, integration has to be performed by an automation tool. The IP should support this automation approach in two ways.
A) By providing a standardized view for the automation tool to integrate the IP against a well-defined integration rules at the SoC level (e.g. SPIRIT XML [4]).
B) The automation tool can decide what configuration of the IP (choosing the IP configuration based under SoC context) needs to be extracted and the extraction process itself can be automated.
Verification: In its true sense, IP reuse is not complete without verification reuse. In a processor core based development; a software based verification methodology is more appropriate. There is a possibility to automate this too, provided the IP provider can supply the software views of the in a standardized format. We followed a verification software based approach that can create the verification software and verify the IP from both interconnectivity and interoperability perspective.
2.3. Tools & standards
Standards are the key for the success of any IP based Soc development approach. Standards enable seamless integration of IP cores from different vendors into the development flow. This also enables automation in integrating and verifying the IP at SoC level. Industry is already working on this aspects both at standardization level as well as at the EDA level. In this paper we explain how we adopted to this initiative by using SPIRIT [1] (Structure for Packaging, Integrating and Reusing IP within Tool-flows) standard and EDA flow based on mentors platform express.
In order to aid the IP based SoC development methodology and automation described above, one need to have strong IP portfolio that get linked with automated development flow for architectural evaluation, RTL integration and verification. In this paper we describe an IP yellow pages concept that can aid automatic extraction and configuration of the IP by specifying the correct IP parameters.
3. Example system
The methodology described earlier will be described here with a multi core video processor subsystem. The figure below represents the top-level view of the hardware architecture.
Figure [2].Multi core sub system functional blocks
The architecture is a memory centric one. The basic intention is to reduce the on chip memory cost by choosing an external memory for both instructions as well as user data. A modular approach is followed in realizing the system. The system is partitioned into various functional sub systems and later integrated at the top level. This will help in easy integration, scalability and configurability.
The major functional elements are the following
3.1. Controller sub system: This is realized by using an ARM926EJS processor [1]. This processor act as
-
Central controller within the system. Handles asynchronous control traffic and I/O management
-
Initialization, booting and I/O control
-
Additionally can be used for data pre- preprocessing
3.2. Data processing engine:
A VLIW architecture based TriMedia (NXP solution) TM3271 media processor is used as a data processing engine. This processor contains highly specialized architecture for real-time media processing and utilizes significant parallelism and architectural optimizations to achieve real-time processing. External accelerators (not part of template) may need to be connected for specific video protocol processing.
3.3. Memory sub system:
The data communication infrastructure plays a major role in the SOC architecture for a number of reasons. The large amounts of temporal (e.g. video) data have to be transported between the processing core to IP blocks, via memory or directly. The combination of cores, processors, and interconnect must guarantee the hard-real time requirements of the application. Resource management (arbitration) of computation (e.g. real-time operating systems), communication (e.g. traffic classes with different performance), storage (by the external memory controller), and their combinations are essential.
3.4. IPC communication:
In a multi processor system, an efficient inter processor communication channel is a must between the co-operating processing elements. This Channel can be established through inter processor communication modules or through shared memory. Control and status information’s between the processing elements are passed through this channel in both directions. It has a low data rate, but requires low latency to minimize the system response time.
3.5. Peripheral sub system:
This module contains the standard peripherals for both ARM and Trimedia. The standard peripheral sets are duplicated for both processing elements. This is done to make sure that no dependency arises from software viewpoint. The standard peripheral sets are divided into the following category
-
RTOS or Kernel Support (Timers, Watchdog, Control registers etc.)
-
Communications (UART, SPI, USB, I2C, GPIO etc.)
3.6. System Software view
A simple form of multiprocessor operating system is organized in this system with a master linux kernel running on ARM9 and a slave PSOS kernel on TriMedia. The master processor determines the schedules for itself and the slave processor. The slave simply runs the processes assigned to it by the master. This organization scheme is conceptually simple and easy to implement. The master processor keeps all the information that is needed for scheduling. The kernels on each processor are responsible for managing purely local resources, such as devices that are not visible to other processors, and implementing the decisions on global resources (e.g. system shared memory).
Figure[3]. Multi processor software view
4. Automated design integration and verification flow
The system described above contains many IP components that get integrated at different hierarchy levels. All these components are to be typically customized (configuration) to meet the architectural requirements. Configurable IP offers a solution to the problem above by allowing the system integrator to set up configuration parameters through a script that configures the block according to the parameters. However to implement such feature in an automated way, the basic configurable architectural intellectual property (IP) blocks are needed in a standardized (Standardized views are required in IP deliveries, documents, and an electronic description of the IP etc.) machine-readable form, so that this can be pushed into an automated design and verification flow. The system integrator can evaluate the IP configurations against the system requirements by quickly integrating the system and evaluating the same. If the design requirements are not met, then different configurations of the IP can be tried. This provides options to the integrator in analyzing the requirements and how it matches with the IP configuration parameters.
Nx-Builder (next generation SoC builder) is the standard design environment used in realizing the project, that addresses the requirements listed above through extensive utilization of architecture, IP reuse, efficient system integration, hardware-software (HW-SW) co-verification and design flow automation. Since this is based on industry standard (SPIRIT [4]) for design integration and advanced commercial design technologies, Nx-Builder helps in correct-by-construction designs and allows rapid development of new systems from platform templates as well as platform derivatives.
Figure [4] Nx-Builder environment.
Nx-Builder is a development environment with a GUI (figure [4]), based on the third party EDA solution called Platform Express from Mentor graphics [5]. Nx-Builder contains APIs with NXP specific extensions as well as a number of generators that extend the platform express capabilities and also provide new flows such as Verification, Synthesis, DFT (Design for Testability).
An important part of the Nx-Builder is the link to NXP internal technologies like IP Yellow Pages (IP repositories). IPYP is a web based service that offers designers an easy way of accessing the IP they require from the IP repositories. The Nx-Builder extends the platform express functionalities to adapt NXP specific design flow.
Figure [5] shows the relationship between the IP libraries and the design environment. On the left is a NXP internal IP repository consisting of IP views. Layered on top are additional XML metadata descriptions and special generators that are invoked to fully configure the IP based on their context in the system being built. On the right is the Nx-Builder design environment that executes the generators creating IP descriptions based on user parameters. Generator chains handle design flows that check IP compatibility, integration and top-level design view generation.
Figure [5]. Nx-Builder link with IPYP
4.1. How Nx-Builder is used in the developmental flow:
During the project execution the Nx-Builder environment is used in three main phases.
-
Architecture exploration and early software development
-
IP Integration
-
IP Verification
Architecture Exploration and early Software development: The IP libraries in the Nx-Builder platform enable the user to quickly construct the architecture and explore various aspects like performance of the system, hardware and software dependencies, architecture pitfalls etc. It also enables to integrate any third party libraries (IP’s) into the platform. It provides easy integration of the software tests to be executed on the host platform and check against the hardware. This brings the value addition in terms of identifying the architectural issues and software dependencies with minimal effort and time in the initial phase of the development.
Nx-Builder platform [6] allows change/choose the processor models, the booting method, the memories, the infrastructure peripherals, the configurations parameters of the IP components connected, system memory map, the software tests execution etc. through an easy graphical based user interface. It also enables easy debugging of hardware and software in a co-simulation environment (seamless from Mentor Graphics, Cadence NC-SIM, X-RAY debugger for software etc.). The flow provided in this platform allows the user to easily switch between CPU simulation models, memory models (behavioral, RTL) and simulation (RTL, net list) without the rebuild thereby exploring the architectural issues quickly upfront.
IP Integration: Integrating IP into the Nx-Builder design environment involves a number of discreet steps. Fixed IP is integrated as a XML view [7]. Configurable IP is integrated as a ‘black box’ representation in XML followed by a number of steps to translate parameters into a fully configured XML view together with its verification views. The translation process involves writing a generator using an API to request a configured instance. The ‘black box’ XML contains interfaces to compatible bus structures. If new interfaces are required then new bus definitions and decoders have to be abstracted in XML. Not all steps are mandatory; this depends on the type of IP. A typical integration flow is shown in the following figure [6].
Figure [6]: IP integration flow
IP Verification: The verification software architecture defines the components of the verification software [8], their interrelations and their relations with the hardware to be tested. The various software architecture components used in the platform are IP test component, HAL/HAPI component, chip context, test application, Hardware IP. HAL (Hardware Abstraction Layer) describes the register abstraction of a hardware device. It defines the manner in which registers can be programmed and standard naming conventions etc. HAPI (Hardware Application Program Interface) provides a set of hardware and software implementation independent interfaces for diagnostic software to configure and enable central resources like interrupt controllers, DMA controllers, reset controllers and clock generation units etc. Figure [7] shows the verification software architecture. The verification software is intended for checking the interconnection between components in a sub system. The software tests are categorized based on testing generic and IP specific functionalities thereby testing the whole sub-system/SoC. The generic tests would perform the read/write to the IPs with specific patterns thereby ensuring the interconnectivity and interoperability. The IP specific tests would exercise the application interface of the system.
Figure[7]. Nx-Builder verification software flow
5. Results and summary
A quantitative assessment of the effort required to create the SoC subsystem against a tradition approach is not carried out as a part of project. In this automated approach most of the effort primarily goes in creating standard views for IP’s and validating their integration in a SoC environment. For highly configurable IP’s this is still a challenge. However this is a one time effort. This can clearly benefit derivative SoC design in a big way.
At a qualitative level the following can be considered as the clear value addition by using this methodology
System level design productivity: Automated development environment enables quick integration and evaluation of the System. Architectural choices can be made in less time by evaluating different architectural possibilities. Similarly the environment also facilitates to implement system level infrastructural needs such IP level power management at system level, external connectivity needs including physical layer, and system level debug infrastructure.
System level verification productivity: A unified, integrated, hardware-software platform forms a complete development environment for system-level functional verification of hardware IP as well as for simulation of software IP. Infrastructure for performing functional verification & performance evaluation are also in place.
Faster time to Silicon: By encapsulating multiple types of standardized peripheral IP and software stacks into a single development environment
Minimizing risk: The system described above is verified at HW/SW interaction level including software drivers and operating system. Also it is possible to create a verification coverage matrix including performance.
8. Reference
[1]. C.P. Ravikumar, “Multiprocessor Architectures for Embedded System-on-chip Applications”, Proceedings of the 17th International Conference on VLSI Design (VLSID’04)
[2]. Asadollah Shahbahrami, Ben Juurlink, Stamatis Vassiliadis, “A Comparison Between Processor Architectures for Multimedia Applications” Faculty of Electrical Engineering, Mathematics, and Computer Science Delft University of Technology, TheNetherlands
[3]. R.Asokan and S.Nazareth. “Processor Architectures for Multimedia”, Proc. of the 14th Annual Workshop on Architecture and System Design, pp. 589-594, November 2001.
[4] SPIRIT User Guide v1.2, Spirit schema working group , 2006 http://spiritconsortium.com/
[5] Platform Express User Guide, www.mentor.com
[6] Nx-Builder User Guide (NXP internal)
[7] IP-XACT_V1.2_Public_Release, 2006, http://spiritconsortium.com/
[8] Verification software User guide (NXP internal)
|
||||||
NXP Hot IP
Related Articles
- IP Processor Core Platform Selection According to SoC Architecture: a case study
- UPF Constraint coding for SoC - A Case Study
- Case study: Using Spartan to support green energy development
- Reusable debug infrastructure in multi core SoC : Embedded WiFi case study
- Reusable Verification Infrastructure for A Processor Platform to deliver fast SOC development
New Articles
Most Popular
|
E-mail This Article | 
|
|
Printer-Friendly Page |