Texas Instruments TMS320 DSP Interrupt Latency, Execution Time, Mips Is Not Enough, Operation

Page 41

www.ti.com

 

 

Interrupt Latency

 

 

Code

Code Sections

Size

Align

a.obj(.text)

768

0

b.obj(.text)

125

32

4.3Interrupt Latency

In most DSP systems, algorithms are started by the arrival of data and the arrival of data is signaled by an interrupt. It is very important, therefore, that interrupts occur in as timely a fashion as possible. In particular, algorithms should minimize the time that interrupts are disabled. Ideally, algorithms would never disable interrupts. In some DSP architectures, however, zero overhead loops implicitly disable interrupts and, consequently, optimal algorithm efficiency often requires some interrupt latency.

Guideline 9

Interrupt latency should never exceed 10µs.

Rule 23

All algorithms must characterize their worst-case interrupt latency for every operation.

All algorithms must characterize their interrupt latency by filling out a table such as that shown below. The interrupt latency must be expressed in units of instruction cycles. Note that the entry in this table is not required to be a constant; it may be function of the algorithm'sinstance creation parameters. Each row of the table corresponds to a method of the algorithm.

Operation

Worst-Case Latency (Instruction Cycles)

process()

300

In practice, the interrupt latency may also depend on the type of memory allocated to an algorithm instance. Since this relationship can be extremely complex, interrupt latency should be measured for a single fixed configuration. Thus, this number must be the latency imposed by an algorithm instance using the same memory configuration used to specify worst-case MIPS and memory requirements.

4.4Execution Time

In this section, we examine the execution time information that should be provided by algorithm components to enable system integrators to assemble combinations of algorithms into reliable products. We first point out the challenges and then describe a simple model that, while not perfect, will significantly improve our ability to integrate algorithms into a system.

4.4.1 MIPS Is Not Enough

It is important to realize that a simple MIPS calculation is far from sufficient when combining multiple algorithms. It is possible, for example, for two algorithms to be "unschedulable" even though only 84% of the available MIPS are required. In the worst case, it is possible for a set of algorithms to be unschedulable although only 70% of the available MIPS are required!

Suppose, for example, that a system consists of two tasks A and B with periods of 2 ms and 3 ms respectively. Suppose that task A requires 1 ms of the CPU to complete its processing and task B also requires 1 ms of the CPU. The total percentage of the CPU required by these two tasks is approximately 83.3%; 50% for task A plus 33.3% for task B.

SPRU352G –June 2005 –Revised February 2007

Algorithm Performance Characterization

41

Page 40 Page 42
Image 41
Page 40 Page 42
Contents Rules and Guidelines Users GuideSubmit Documentation Feedback Contents Use of the DMA Resource Urls List of Figures Document Overview Read This FirstIntended Audience Text Conventions Related DocumentationRule n Guideline nOverview Rules for TMS320C5x Rules for TMS320C6x Scope of the StandardRequirements of the Standard Rules and GuidelinesIntentional Omissions Goals of the StandardFrameworks System ArchitectureCore Run-Time Support AlgorithmsGeneral Programming Guidelines Threads and Reentrancy Use of C LanguageThreads RuleReentrancy Preemptive vs. Non-Preemptive MultitaskingExample Data Memory Data MemoryScratch versus Persistent Memory SpacesScratch vs Persistent Memory Allocation Guideline Algorithm versus ApplicationSection Name Purpose Program MemoryROM-ability Use of Peripherals Use of PeripheralsInterfaces and Modules Algorithms Packaging Algorithm Component ModelImplementation Fir.h Interfaces and ModulesExternal Identifiers Module Instance Objects Naming ConventionsModule Initialization and Finalization Run-Time Object Creation and Deletion Design-Time Object CreationExample Module Module ConfigurationMultiple Interface Support Summary Interface InheritanceElement Description RequiredAlgorithms AlgorithmsObject Code PackagingDebug Verses Release Header FilesModuleversvendorvariant.1arch Data Memory Program Memory Interrupt Latency Execution Time Algorithm Performance Characterization Size Heap Memory External Static Local and Global Data Memory Stack MemoryData Bss Object files Size Execution Time Interrupt LatencyMips Is Not Enough OperationExecution Timeline for Two Periodic Tasks Execution Time Model59000 198000 Process198000 Submit Documentation Feedback DSP-Specific Guidelines Register Types CPU Register TypesTMS320C6xxx Rules and Guidelines Use of Floating PointEndian Byte Ordering Data ModelsStatus Register Register ConventionsRegister Use Type CSR Field Use TypeProgram Models Interrupt LatencyTMS320C54xx Rules and Guidelines TMS320C54xx Rules and Guidelines ST1 Field Name Use Type Status RegistersST0 Field Name Use Type Pmst Field Name Use Type TMS320C55x Rules and GuidelinesStack Architecture Example RelocatabilitySSP ST3 Field Name Use Type Status BitsST2 Field Name Use Type Homy General TMS320C24xx GuidelinesTMS320C28x Rules and Guidelines TMS320C28x Rules and GuidelinesXAR0 M0M1MAP Submitting DMA Transfer Requests Use of the DMA ResourceAlgorithm and Framework OverviewLogical Channel Requirements for the Use of the DMA ResourceData Transfer Synchronization Data Transfer PropertiesDMA Rule Abstract InterfaceDMA Guideline Average Maximum Resource CharacterizationData Transfers bytes Frequency Strong Ordering of DMA Transfer Requests Runtime APIsDevice Independent DMA Optimization Guideline Submitting DMA Transfer Requests13 C6xxx Specific DMA Rules and Guidelines Cache Coherency Issues for Algorithm Producers14 C55x Specific DMA Rules and Guidelines Supporting Packed/Burst Mode DMA TransfersAddressing Automatic Endianism Conversion Issues Minimizing Logical Channel Reconfiguration OverheadInter-Algorithm Synchronization Non-Preemptive SystemPreemptive System Algorithm B Algorithm a Inter-Algorithm Synchronization Appendix a General Rules DMA Rules Performance Characterization RulesGeneral Guidelines DMA Guidelines Submit Documentation Feedback Core Run-Time APIs DSP/BIOS Run-time Support LibraryTI C-Language Run-Time Support Library DSP/BIOS Run-time Support LibraryBooks BibliographySubmit Documentation Feedback Glossary of Terms GlossaryGlossary of Terms Glossary of Terms Important Notice
Top Page Image Contents