Filter
Top Products
www.ti.com
6.9RuntimeAPIs
6.10StrongOrderingofDMATransferRequests
RuntimeAPIs
Forexample,inthetableabove,the"process"operationisusingtwologicalchannels.Onlogicalchannel
0,itperformsonaverage5datatransfersandamaximumof7datatransfers.Theaveragenumberof
bytesforeachtransferis768,andthemaximumnumberofbytesis1024.
TheIDMA2interfaceisusedtorequestandgrantanalgorithmsomeDMAresources,andalsochange
theseresourcesinreal-time.WealsoneedtodefineruntimeAPIsthatareactuallycalledfromwithinthe
algorithmtoconfigurethelogicalchannel,startadatatransferandsynchronizethedatatransfer(s).
ThefollowingAPCY2APIsareallowedtobecalledfromwithinanalgorithmthathasimplementedthe
IDMA2.
Configuration:
ACPY2_configure(),ACPY2_setSrcFrameIndex,ACPY2_setDstFrameIndex,ACPY2_setNumFrames
Synchronization:ACPY2_complete(),ACPY2_wait()
Scheduling:ACPY2_start(),ACPY2_startAligned()
Itisimportanttonoticethatthealgorithm'sclientisfreetoimplementtheseAPIsasappropriate,granted
thattheysatisfytheirsemanticsintheTMS320DSPAlgorithmStandardAPIReference(SPRU360).
TheIDMA3interfacewhichisrequiredtobeimplementedbyalgorithmsthatusetheC64x+EDMA3
controller,canbeoptionallyassociatedwithacustomIDMA3protocol.Whenanon-nullprotocolobjectis
provided,theDMAresourcemanagerusesIDMA3_Protocolfunctionstoperformadditionalmemory
allocationforthelogicalDMAchannel’senvironmentfieldortocallprotocol-specific,handleinitialization
andde-initializationfunctions.ThisfeatureallowsframeworkstosupportcustomDMAservicefunction
librarieswithcustominitializationandfinalizationfunctions.
TheACPY3libraryisanexampleofsuchacustomDMAlibrarythatissimilartotheACPY2libraryinits
roleanddefinition.However,itprovidesamuchlowerlevelofabstractioncomparedtotheACPY2
interface;itisdesignedtotargetEDMA3.0/QDMA,whileACPY2providesagenericDMAabstraction
layer.DetailsoftheACPY3librarycanbefoundinUsingDMAwithFrameworkComponentsforC64x+
(SPRAAG1).UseoftheACPY3libraryisnotmandatorywhenusingtheIDMA3interfaces;algorithmsare
freetousetheirownDMAfunctionstoprogramthephysicalDMAresourcesacquiredthroughtheIDMA3
protocol.
AnimportantenhancementthatwasintroducedthroughtheACPY2APIsoverthedeprecatedACPYAPIs
isthestrictFIFOorderingpropertyofDMAtransferssubmittedbyanalgorithmonalogicalDMAchannel.
Oftenalgorithmsneedtoissueback-to-backDMAtransfersfromandintothesamedataregionandthey
cantakeadvantageoftheFIFOproperty.Forexample,analgorithmcanscheduleatransfertocopyout
theresultstoredinabufferusedbyanin-placecomputationphase,andimmediatelyscheduleatransfer
tobringinthenextsetofinputdataintothesamebufferforthenextroundofprocessing.Withoutthe
strongorderingproperty,anACPY2_wait()synchronizationcallwouldbeneededpriortosubmittingthe
secondtransferrequest.Thisadditionalsynchronizationisneededtopreventtheincoming(nextround's)
inputdatafromcorruptingthecurrentoutputthatispotentiallystillbeingcopiedout.Thestrongordering
guaranteeensuresthatthesecondtransferwillnotstartuntilafterthefirsttransferfinishes.Thisleadsto
twolevelsofoptimizations.
TheextraACPY2_wait()call/synchronizationoverheadiseliminated,butevenmoreimportantly,the
algorithmcannowcontinuetoperformothertasks(e.g.,processsomeotherbuffer,etc.)untilitabsolutely
needstosynchronizewiththecompletionofthesecondtransfer.
AnotherrelatedACPY2enhancementistheintroductionoftheconceptofaserializer(QueueID)property
forlogicalchannels.AcommonQueueIDextendsthestrongFIFOorderingpropertytoalltransfers
submittedonanyofthelogicalchannelsassignedthesameQueueIdbythesamealgorithm.QueueIDs
areassignedbythealgorithmandpublishedthroughitsIDMA2interface.
IDMA3doesnotsupportthequeueIDsdefinedinIDMA2.Thismeansthereisnorequirementtoenforce
inter-channelFIFOorderingofsubmittedDMAtransfers.WhenFIFOorderingisneeded,youmustuse
linkedtransfers.
SPRU352G–June2005–RevisedFebruary2007UseoftheDMAResource67
SubmitDocumentationFeedback