GTV is the global software product line that supports NXPs Ultimate One Chip family of ICs for mainstream (analogue) TV (NXP was formerly known as Philips Semiconductors; it became an independent company in 2006). In this article we describe four aspects of GTV: business, software architecture and tooling, software development process and software development organization. The GTV product line was initiated around 2000 and became very successful in the years 2003 and following. The product line is continuing today as the world-wide software platform for NXPs LCD One Chip family.
Business
NXP is a supplier of semiconductor devices, among which integrated circuits for mainstream television. At the time of GTV, NXP had an annual turnover of several hundreds of millions of Euros in ICs for mainstream TV (a significant part of NXPs turnover), making NXP an undisputed global market leader in that field. NXP served over one hundred customers, ranging from A-brands to OEMs.
GTV was designed to control the Ultimate One Chip solution (UOC), a family of chips for mainstream TV with hundreds of variants. Initially, customers were able and willing to develop software for these chips themselves, but as the chips grew in capacity, customers started to rely more and more on NXP for delivering software with the chip.
GTV is set-up as a single product family that can control all variants of the hardware for all customers (world-wide). Interesting to note is that the customers sometimes build a product family themselves. This implies that NXP cannot instantiate a member of the family for the customer, but rather the customer has to do the instantiation by themselves. This puts extra demands on the mechanisms and tools used to create the product family.
As the ICs are intended for the mainstream TV market, where cost is a dominant issue, the software has to deal with severe resource constraints (8 bit processors, 64-256 kilobytes of memory, et cetera). And since GTV is set-up as a single product family, extra measures have to be taken to ensure that after instantiation there is no code in the product that is not necessary. This resulted among other things in three-valued logic for switches that control functionality: functionality can be never in the run-time product, sometimes (depending on run-time switches) or always.