www.ti.com
Goals of the Standard
1.3Goals of the Standard
This section contains the goals of this standard. While it may not be possible to perfectly attain these goals, they represent the primary concerns that should be addressed after addressing the required elements described in the previous section.
∙Easy to adhere to the standard
∙Possible to verify conformance to standard
∙Enable system integrators to easily migrate between TI DSPs
∙Enable host tools to simplify a system integrator'stasks, including configuration, performance modeling, standard conformance, and debugging.
∙Incur little or no "overhead" for static systems
Although TI currently enjoys a leadership role in the DSP marketplace, it cannot directly control the algorithm software base. This is especially true for relatively mature DSPs, such as the C54xx family, where significant algorithm technology currently exists. Thus, for any specification to achieve the status of a standard, it must represent a low hurdle for the legacy code base.
While we can all agree to a guideline that states that every algorithm must be of high quality, this type of guideline cannot be measured or verified. This
While this standard does define an algorithm'sAPIs in a
Wherever possible, this standard tries to anticipate the needs of the system integrator and provide rules for the development of algorithms that allow host tools to be created that will assist the integration of these algorithms. For example, rules related to algorithm naming conventions enable tools that automatically resolve name conflicts and select alternate implementations as appropriate.
Maurice Wilkes once said, "There is no problem in computer programming that cannot be solved by an added level of indirection." Frameworks are perfect examples of how indirection is used to "solve" DSP software architecture problems; device independence is achieved by adding a level of indirection between algorithms and physical peripherals, and algorithm interchangeability is achieved by using function pointers.
On the other hand, Jim Gray has been quoted as saying, "There is no performance problem that cannot be solved by eliminating a level of indirection." It is essential that the TMS320 DSP Algorithm Standard remain true to the spirit of the DSP developer: any overhead incurred by adherence to the standard must be minimized.
1.4Intentional Omissions
In this section, we describe those aspects of the standard that are intentionally omitted. This is not to say that these issues are not important, but in the interest of timeliness, this version does not make any recommendation. Future versions will address these omissions.
∙Version control
∙Licensing, encryption, and IP protection
∙Installation and verification (i.e., digital signatures)
∙Documentation and online help
Like all software, algorithms evolve over time, and therefore require version control. Moreover, as the TMS320 DSP Algorithm Standard evolves, older algorithm components may fail to be compliant with the latest specification. Ideally, a version numbering scheme would be specified that allowed
12 | Overview | SPRU352G |