www.ti.com
1.3GoalsoftheStandard
1.4IntentionalOmissions
GoalsoftheStandard
Thissectioncontainsthegoalsofthisstandard.Whileitmaynotbepossibletoperfectlyattainthese
goals,theyrepresenttheprimaryconcernsthatshouldbeaddressedafteraddressingtherequired
elementsdescribedintheprevioussection.
•Easytoadheretothestandard
•Possibletoverifyconformancetostandard
•EnablesystemintegratorstoeasilymigratebetweenTIDSPs
•Enablehosttoolstosimplifyasystemintegrator'stasks,includingconfiguration,performance
modeling,standardconformance,anddebugging.
•Incurlittleorno"overhead"forstaticsystems
AlthoughTIcurrentlyenjoysaleadershiproleintheDSPmarketplace,itcannotdirectlycontrolthe
algorithmsoftwarebase.ThisisespeciallytrueforrelativelymatureDSPs,suchastheC54xxfamily,
wheresignificantalgorithmtechnologycurrentlyexists.Thus,foranyspecificationtoachievethestatusof
astandard,itmustrepresentalowhurdleforthelegacycodebase.
Whilewecanallagreetoaguidelinethatstatesthateveryalgorithmmustbeofhighquality,thistypeof
guidelinecannotbemeasuredorverified.Thisnon-verificationornon-measurementenablessystem
integratorstoclaimthatalltheiralgorithmsareofhighquality,andthereforewillnotplaceavalueonthe
guidelineinthisinstance.Thus,itisimportantthateachguidelinebemeasurableor,insomesense,
verifiable.
Whilethisstandarddoesdefineanalgorithm'sAPIsinaDSP-independentmanner,itdoesnotseekto
solvetheDSPmigrationproblem.Forexample,itdoesnotrequirethatalgorithmsbeprovidedonbotha
C54xandaC6xplatform.Itdoesnotspecifyamultiplebinaryobjectfileformattoenableasinglebinary
tobeusedinbothaC5xandaC6xdesign.Nordoesitsupplytoolstotranslatecodefromone
architecturetoanotherorrequiretheuseofanarchitectureindependentlanguage(suchasC)inthe
implementationofalgorithms.
Whereverpossible,thisstandardtriestoanticipatetheneedsofthesystemintegratorandproviderules
forthedevelopmentofalgorithmsthatallowhosttoolstobecreatedthatwillassisttheintegrationofthese
algorithms.Forexample,rulesrelatedtoalgorithmnamingconventionsenabletoolsthatautomatically
resolvenameconflictsandselectalternateimplementationsasappropriate.
MauriceWilkesoncesaid,"Thereisnoproblemincomputerprogrammingthatcannotbesolvedbyan
addedlevelofindirection."Frameworksareperfectexamplesofhowindirectionisusedto"solve"DSP
softwarearchitectureproblems;deviceindependenceisachievedbyaddingalevelofindirectionbetween
algorithmsandphysicalperipherals,andalgorithminterchangeabilityisachievedbyusingfunction
pointers.
Ontheotherhand,JimGrayhasbeenquotedassaying,"Thereisnoperformanceproblemthatcannot
besolvedbyeliminatingalevelofindirection."ItisessentialthattheTMS320DSPAlgorithmStandard
remaintruetothespiritoftheDSPdeveloper:anyoverheadincurredbyadherencetothestandardmust
beminimized.
Inthissection,wedescribethoseaspectsofthestandardthatareintentionallyomitted.Thisisnottosay
thattheseissuesarenotimportant,butintheinterestoftimeliness,thisversiondoesnotmakeany
recommendation.Futureversionswilladdresstheseomissions.
•Versioncontrol
•Licensing,encryption,andIPprotection
•Installationandverification(i.e.,digitalsignatures)
•Documentationandonlinehelp
Likeallsoftware,algorithmsevolveovertime,andthereforerequireversioncontrol.Moreover,asthe
TMS320DSPAlgorithmStandardevolves,olderalgorithmcomponentsmayfailtobecompliantwiththe
latestspecification.Ideally,aversionnumberingschemewouldbespecifiedthatallowedhost-basedtools
toautomaticallydetectincompatibleversionsofalgorithmcomponents.
12OverviewSPRU352G–June2005–RevisedFebruary2007
SubmitDocumentationFeedback