Very large-scale integration (VLSI) technology has progressed to the point that many new designs are systems on a chip (SOC). In SOC, the design is partitioned into modules each including thousands (often even millions) of active components. These SOC systems are crafted by diverse teams that may be physically separated and sometimes are located in different parts of the world.
Portions of the SOC design include a hierarchy of modules that have a wide range of complexity. It is helpful to categorize this hierarchy in descending order of complexity as follows:
A. Mega-modules: Core processors such as DSP CPU elements, co-processors such as floating point processors and memory elements such as two-level cache memory with sophisticated memory controllers;
B. Super modules: Enhanced direct memory access functions with extensive external memory interfaces EMIF and bus interface functions; and
C. Complex modules: first-in-first-out (FIFO) buffers or register file functions having configurability for file size and word width.
These Mega-Modules, Super-Modules, and Complex Modules are the product of a large design investment and a great deal of design evaluation, simulation, and detection of functional and parametric failures. Each module type has a full history recording the results of these exhaustive evaluations. When a module is released by one project for re-use by another project, the need for continued communication between the founder and the user is pre-eminent.
It would be natural to assume that establishing a library for all re-use modules would go a long way to providing the communication. Unfortunately, the library concept sets up another entity between founder and user and suffers from the confusion of ownership and responsibility. For an effective design system, designers of a module (founders) must always remain responsible yet must be relieved of every day communication regarding issues and details relating to the reuse of the module.
Clearly, while a centralized system is needed for communication, this system must have an aspect of decentralization wherein projects may operate autonomously. Modules could be integrated systems that are designed and implemented by engineers engaged with potentially a large number of projects worldwide. Managing issues in these SOC designs thus are not restricted to the business process of one project, but include inter-project communications at a very fine granularity, down to the detail level of the individual design module.
Several bug-tracking tools are available to meet these needs. They are targeted chiefly at tracking issues related to a particular project, and have weak, non-existent, or inappropriately targeted solution for designs with many interdependent collaborative projects. What is needed is a system that will not only allow each individual project to track its own bugs and design issues, but also allow the same seamless tracking/collaboration for upstream, downstream or partner projects affected by the same issue. Collaboration has to be seamless or transparent so that a resolution of the issue provided by members in one project applies immediately to the resolution of the same problem in other affected projects.
In conventional bug tracking tools all issues/bugs detected by one project become limited to the techniques chosen by that project with a set of specific choices on definitions and descriptions for what is referred to as the project schema: (a) bug life, (b) states transition and (c) fields within the report. The bug report then must be separately copied and these schemas must be communicated to the other projects with differently defined schema beyond the bug-tracking tool itself. Typical communications are through e-mails or other indirect communications. This often results in delays and other communication problems caused by the lack of an integrated tool to handle inter-project communications and lack of uniformity across project schema.
FIG. 1 illustrates an example flow diagram of a conventional bug tracking system. The conventional system in this example has N projects which report manually and other projects are notified manually, and related reports are issued manually in all N projects.
Assume the first bug was found 101 in Project 1. Project 1 reports the bug manually to other projects via path 109 and also submits a bug report 102 within its own project for validation 103. Validation is the process by which the bug report is determined to be acceptable in its description of the bug. Upon validation the bug report is written to the project 1 database 104 in native schema. Other projects linked to project 1 receive the new bug report manually via notification path 109 to 111, 109 to 121 and so forth. Each project submits its own bug report 112, 122 in their native schema and then passes these reports on for validation in steps 113 and 123. Upon validation the each bug report is written to the respective project database 114, 124 in native schema.
Similarly, when a bug update is identified 105 in project 1, an update report 106 is written, which will also undergo validation 103 before being written into the project 1 database 104. Update bug reports 105 are passed manually from the bug update step 105 to other project update bug report steps 116 and 126 via path 110. Once the updates are completed in steps 116 and 126, they are validated in steps 113 and 123 and then written to the respective project databases in steps 114 and 124 respectively.
When a bug update is identified in either project 2 115 or project N 125, an update report 116 or 126 is written, which will also undergo validation 113 or 123 before being manually written into the respective project databases 114 and 124. Update bug reports 115 and 125 are likewise passed manually from the bug update steps 115 and 125 to other project update bug report steps via path 110.