|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
LibCoMa presents the developer a GUI that shows a tree-structured feature model. Typically, the user first selects which hardware features his version of the IC has. This will enable more specific options that can subsequently be set by the user. If all features have been defined, the user presses a button, and the values of the variation points are filled in the header files, and an accompanying makefile is generated. For optimal use of resources, variation points use a three-valued logic. A feature can be always present, always absent, or dependent on a run-time switch. The switch setting determines whether code is being included for the feature, and whether some extra code is enabled that allows to select the feature at run-time. The drivers and platform software is delivered as a black-box. However, to optimally use the three-valued logic described above, the code needs to be recompiled at the customer site. To protect IP and to prevent erroneous platform usage, the source code is encrypted. To prevent the customer from monitoring the disk and finding the decrypted code in an intermediate file, the code is decrypted inside the compiler. This required an agreement between NXP and the compiler vendor. ProcessNXP has tried several approaches to reduce the software development effort, before GTV was created. From 1994 to 1996, a Reuse Project attempted to create reusable software for TV, without identifying the specific family for which this was useful (i.e. without doing a proper commonality and variability analysis). From 1997 to 1999, a first attempt was made to create a family of software for a new generation of ICs. The development of the GTV product line really started around 2000, and had its first successful product in 2002. GTV has supported the full family of hardware since 2003. Introduction of the product line was not a trivial matter. There has always been limited money available for the software development in NXP. On the other hand, software was being recognized as a valuable asset, without which the hardware could not be sold. Constraints on development costs resulted in an incremental set-up of the software product line: first drivers, then platform, then (example) functions and applications. < Previous page . . 1 2 3 4 5 6 7 . . Next page > |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||