ipPROCESS: A Usage of an IP-core Development Process to Achieve Time-to-Market and Quality Assurance in a Multi Project Environment

Francielle Santos, André Aziz, Daniele Santos, Millena Almeida, Edna Barros
Informatics Center, Federal University of Pernambuco
Recife Brazil

Abstract:

Nowadays, the usage of Intellectual Property cores has been an alternative to the increasing gap between design productivity and chip complexity of System-on-chip (SoC) designs [1]. To support this approach, it is mandatory to deliver complete systems in short time-to-market. Thus, IP-core design organizations must assure high quality IP-cores delivering, in short time frames. In the most of the cases, these cores are produced in a multi project environment. Our work proposes an iterative process for developing IP-cores with prototyping in FPGA in a multi project environment, based on the mainly market standards as VSIA, RUP, PMBOK and RMM ones. The process was applied successfully in an organization context with many projects parallel development.

1. INTRODUCTION

Over the past few years, as the demand for embedded systems, with more functionality into a single device has increased, the industry started to use new methodologies to develop System-on-Chip (SoC) designs [2] by reusing pre-designed IP-cores. These methodologies should combine Electronic System Level (ESL) description languages and IP-core modeling [3].

Thus, it is necessary to deliver the produced IP-cores in the short time-to-market frames of consumer electronics market, with high levels of quality, assuring their well-succeeded simulation and integration into SoC platforms.

Involving many distinct ‘areas of concern’ like specification, functional verification, and prototyping, IP-core design has its own challenges like portability, reusability, standards, interfaces, well-defined and useful documentation, easy to integration, intellectual property protection and so on.

In this context, we propose the usage of an IP-core design process, for Soft IPs with prototyping in FPGAs, called ipPROCESS, inspired on: a rigorous software engineering process [4], well-known hardware design standards [5] [6] and a project management body of knowledge [7] as a way of improving the development, taken advantage of an efficient management methodology (with mechanisms to support teamwork) and well-defined team roles, reducing the design time, guarantying quality assurance.

The next sections are presented in the following way: in section 2 will be discussed the related works. Sections 3 and 4 present the ipPROCESS [8] definitions and also the proposed management methodology. The case study is shown in section 5 and the future works are addressed in section 6.

2. RELATED WORKS

The related work comprises such software as hardware initiatives, both related to project execution, lifecycle and tasks definitions and also applicable standards to these fields. All of presented related work intends to increase development teams’ productivity, with no prejudice to final product quality.

The Rational Unified Process (RUP) [4] proposes an organizational process, with the assignment of pre-defined tasks to specific roles following a well-known software development flow. Its main purpose is to produce high-quality software that meets the needs of its end users within a predictable schedule and budget [4].

The RUP basic advantage is to develop incrementally the final product, splitting the project time into iterations and delivering incremental groups of functionalities (builds) in some of these iterations.

Two of the most relevant works in hardware field are the Reuse Methodology Manual (RMM) [6] and the Virtual Socket Interface Alliance (VSIA) consortium [5]. The first one defines an IP/SoC development flow and development domain distinct “areas of concern”, like verification and prototyping, allied to some best practices, all resulting from market companies design teams experience [6].

The VSIA was an effort to standardize the way an IP core is delivered to integrator, defining open specifications and data formats, as a way of permitting reuse and also shorter time-to-market. Nowadays VSIA dissolved operations, transferring its set of defined standards to the industry [5].

The Project Management Institute (PMI) identified the main knowledge that a manager should have to conduct a project with success. That knowledge is presented as the Project Management Body of Knowledge (PMBOK) [7], which focuses on project execution, independently on the process development life cycle applied. In section 4 will be presented the management methodology approach.

3. ipPROCESS

The ipPROCESS defines a set of tasks, where each task determines “what should be done, when and for whom”, and assigns them to specific roles into the organization, according to the moment in the design life cycle, transforming the IP-core requirements into the prototype, complying with the constraints of time, cost and quality previously agreed with the customer [1][8][9].

The process goal is to facilitate and guide a high quality IP core design, providing an early bug detection (on the early development phases) and good documentation.

The process defines “what should be done” in the project by organizing the activities related to a specific area into “disciplines”. For example, activities related to system verification are grouped into Verification discipline.

The ipPROCESS defines five disciplines that are compliant to the IP-core development flow addressed by RMM [6]. The five disciplines are described in terms of activities (that group related tasks), workflows, artifacts, and roles, occurring in this order:

1. Requirements: establishes and maintain agreement with the customers on what the IP-core should do.
2. Analysis & Design: transforms the requirements into a design of the IP-core.
3. RTL Implementation: implements the components, according to the architecture.
4. Functional Verification: evaluates and assess the IP-core quality, finding and documenting defects.
5. Prototyping: prototypes the IP-core in the FPGA, based on the implementation components.

Each discipline presents a macro workflow, defining activities to be performed and its order, like in Figure 1.

Figure 1. Prototyping workflow

For each activity there is a set of tasks to be performed by specific roles, presenting inputs and outputs artifacts. As an example, Figure 2 shows the details of Cossimulate Component activity.

Figure 2. Details of Cossimulate Component activity

All the elements modeled by the process like tasks, roles, artifacts are detailed in order to help the designers in process learning and usage. One example of task detailing can be seen in Figure 3.

Figure 3. Design Interfaces task detailing

The IP-core development is done incrementally, delivering intermediate sets of functionalities along the iterations. This way, in the beginning of a project, the work is divided in sets of product functionalities. Per iteration, it should be executed activities related to each discipline to the allocated sets.

Per iteration, depending on the project phase, the effort per discipline, spent to elaborate the functionality sets allocated, will differ. As an example, in a Conception Iteration, sets of functionalities elaborated will spend more effort on Requirements discipline than the RTL Implementation one. Figure 4 represents how the emphasis on one discipline varies over time and how iterations are distributed along the phases.

Figure 4. ipPROCESS architecture

While a phase is essentially a span of time between two major milestones, comprising one or several iterations, iteration itself represents all the workflow (comprising all disciplines execution), applied to construct a set of functionalities. The number of iterations needed and its duration depends on the project characteristics.

From a management perspective, the life cycle implemented by ipPROCESS is decomposed over the time into four sequential phases (see Figure 5). At each phase-end an assessment is performed to determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to the next phase.

Figure 5. ipPROCESS phases

For example, in the first phase (Conception), we spend more time on requirements, and in the last phase (Prototyping), we spend more time on FPGA prototyping. This life cycle was proposed based on the efficient RUP approach.

During the IP-core development is produced a complete user documentation compliant to VSIA, SRS and RMM definitions.

The summary of defined phases, disciplines, tasks, templates, artifacts and roles is shown in Table 1. ipPROCESS contributions.

Table 1. ipPROCESS contributions

Contribution	Quantity
Phases	4
Disciplines	5
Tasks	30
Roles	11
Artifacts	29
Templates	13

All the ipPROCESS is modeled using the SPEM (Software Process Engineering Meta-Model) [9], a UML profile, which permits a whole process validation and easy maintenance. To model, validate and publish the process, the EPF Tool (Eclipse Process Framework) [10] is being used, which generates a structured publication as a web site for the process contents. This tool also enables the process tailoring according to project specific characteristics, generating an adapted instance for each new project.

4. MANAGEMENT METHODOLOGY

As said previously, the management of the process tasks according to the ipPROCESS is an efficient approach, reducing the IP core time-to-market with no prejudice to product quality. This fact comes from the iterative and incremental process life cycle combined with the process application by specialized experienced designers. Based on these elements, we are proposing an management strategy as depicted in Figure 6, where short names to the ipPROCESS disciplines like REQ to Requirements and so on have been used.

Figure 6. Project development by different teams

A specialized team executes each discipline (named differently in Figure 6), and the resulting artifacts are passed to the next discipline (executed by another team of experienced designers) as in a “pipeline”, where in each stage different teams are executing specialized activities in parallel. For instance, in Figure 6, in the end of second iteration, there are four different teams working in parallel.

As said previously, per iteration, the disciplines are executed to sets of functionality with different effort. To complement this concept there is the “release”. A release represents a set of functionalities totally implemented and prototyped that can be deployed to the customer as an intermediate deliver.

The relation between these two concepts is pretty relevant to the proposed management methodology and can be seen in Figure 6. Project development by different teams. Considering the example:

1. Release 1: composed by the functionalities F1 and F2.

2. Release 2: composed by the functionalities F3 and F4.

3. Release 3: composed by the functionalities F5, F6 and F7.

4. Release 4: composed by the functionalities F8 and F9.

5. Release 5: composed by the functionalities F10 and F11.

In the final of the first iteration, that will be specified the requirements related to releases 1 and 2: functionalities F1, F2, F3 and F4. When the third iteration finishes, that will be already prototyped and maybe deployed to the customer the following functionalities: F1, F2, F3 and F4.

At this time, the project general progress (beyond what has been said): all the requirements specified; the architecture defined; all the functionalities implemented, unless F10 and F11; all the functionalities verified, unless: F8, F9, F10, F11.

The importance of these two concepts is to plan and monitor the project through iterations, assuring the delivery of the agreed releases.

To assure good results, the process is applied with the support of management [11] and communication [12] tools support and with execution of small iterations over the time.

During each project iteration execution, in addition to the development, the risks and problems are monitored, and, in the next iteration treated. This way, the organization quickly reacts to the problems along the project.

Thus, to achieve time-to-market, this methodology propose the usage of specialized teams allocated per area of concern (and not per project), increasing the management effort to cope with multi-projects environment.

5. RESULTS

This methodology has been applied in a multi-project environment (3 projects), developed by a small team (14 developers), split in 5 areas (according to the ipPROCESS disciplines) and has shaped up to be a good alternative to increase the productivity, also shown in better technical results as the developers apply the technical learning throughout the projects under development.

As a way of attesting the organization improvement, the ipPROCESS application on projects was evaluated [12] against an ISO standard 15504 (Information technology Process assessment) [14] (implemented by the CMMI Model), before the multi-project execution (with 8 months of execution) and after that, showing the following summarized results in Table 2. Process and product evaluations results.

Table 2. Process and product evaluations results

Data	Before execution	After execution
15504 adherence*	38%	62%
Implemented processes	33%	75%
Managed processes	8%	25%

*Maturity Level 1: Managed Processes

These evaluations were executed according to the maturity level 1 defined by the CMMI Model, where is observed if the organization has the processes defined, implemented and managed. As it can be seen, the ipPROCESS was compliant to 38% of ISO 15504 standard processes, before the case study execution, and today this compliance is 62%. This occurs because of the number of implemented processes: it was 33% and now is 75%. This fact can be noticed in the detailing of ipPROCESS state (rate in assessment) for 12 of 22 processes analyzed (engineering processes) before and after process implantation is in Figure 7.

Figure 7. State of ipPROCESS engineering processes before and after the process implantation

The managed processes information shows the increase of implemented processes that are managed by the organization, reflecting directly in the product final quality. So, there were relevant improvements on the ipPROCESS and, with the tools support all learned lessons are documented, allowing the continuous process improvement.

An important qualitative result was the increase of the Organizational Knowledge. Before the multi-projects execution, each team was responsible for a project, and, when a designer was fired, a part of project knowledge was lost. Now, with the distinct areas and good communication implemented, even hiring or firing designers does not affect the ongoing projects.

Technical improvements of designers were also noticed. As the teams are specialized and always execute the same flow, in each new project the designers learn and apply more technical concepts, increasing the organizational technical knowledge. This also caused a productivity increase.

6. FUTURE WORKS

The presented work proposed an efficient and disciplined way to achieve both quality and time-to-market when developing IP-cores prototyped in FPGA. As obtained results, the process was implemented in a multi-project environment, with tools support and also periodic quality assessment.

Some of the future works addressed to ipPROCESS are:

1. Deployment Discipline definition: definition of workflow, tasks and roles to the IP-core deployment area of concern. This work is already under development, being validated.

2. The definition of the flow to prototype IP core in ASIC: definition of disciplines, workflows, tasks and roles to the IP-core prototyping in Asic. This work is already under development; it was validated with 4 case studies and is being adapted.

3. The definition of the Customer acquisition and maintenance flows: definition of disciplines, workflows, tasks and roles to the IP-core acquisition by the customer (the activities related to the project proposition feasibility) and also the IP core maintenance flow (after IP core deployment). This works is already under definition.

REFERENCES

[1] M. Lima, et al, “ipPROCESS: Using a Process to Teach IP-core Development”, MSE, 2005.

[2] R. Saleh, et al, “System-on-Chip: Reuse and Integration”, Proc. IEEE, vol. 94, nº 6, Canada, 2006, pp. 1050–1069.

[3] E. N. S. Barros, et al, “A SystemC-only Design Methodology and the CINE-IP Multimedia Platform”, Design Automation for Embedded Systems Journal, vol. 10, nº 2-3, 2006, pp. 181-202.

[4] P. Krutchen, The Rational Unified Process, Addison-Wesley, 1998.

[5] VSI Alliance, “VSI Alliance web site”, VSI Alliance, 2008.

[6] M. Keating, P. Bricaud, Reuse Methodology Manual for System-on-a-Chip Designs, Kluwer Academic Press, 2002.

[7] Project Management Institute, A Guide to the Project Management Body of Knowledge – PMBOK® Guide, PMI, Pennsylvania 2000.

[8] ipPROCESS, “The ipPROCESS Definition”, LINCS, 2006.

[9] M. Lima, F. Santos, J. Bione, T. Lins, E. Barros. “ipPROCESS: A Development Process for Soft IP-core with Prototyping in FPGA”, FDL, 2005.

[10] SPEM, SPEM - Software Process Engineering Metamodel, OMG, 2008.

[11] EPF, “Eclipse Process Framework Website”, Eclipse Foundation 2008.

[12] dotProject, “dotProject - the Open Source Project Management tool”, dotProject, 2008.

[13] Mantis, “Mantis Bugtracker Website”, Mantis, 2008.

[14] Software Quality Institute, “Appraisal Assistant Tool”, SQI, 2007.

[15] ISO, ISO 15504: Information technology Process assessment Standard, ISO, 2004.