DOC PREVIEW
UT EE 382C - Native Signal Processing With Altivec In the Ptolemy Environment

This preview shows page 1-2-3 out of 9 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Native Signal Processing With Altivec In the Ptolemy EnvironmentKen Aponte and Ken LoganMay 10, 2000AbstractThe authors extend the functionality of the Ptolemy simulation and code generation facilities byimplementing Altivec enabled signal processing kernels, the FFT and FIR, as Ptolemy actors.These actors are then used in Ptolemy demo systems, compiled using the GNU compilerenhanced with support for Altivec, and simulated using the Psim PowerPC simulator. Thisintegration of tools, with Ptolemy as the foundation, provides the design, synthesis andsimulation environment necessary for rapid prototyping of systems. Performance results areobtained and presented for all tests utilizing both scalar and Altivec versions of the actors.1 Introduction to Native Signal ProcessingMany of the modern general-purpose processor architectures now include native signalprocessing (NSP) extensions. Hewlett Packard PA-RISC, Sun Sparc, Silicon Graphics MIPS,Digital Alpha, Intel x86, AMD x86, and Motorola PowerPC have all introduced singleinstruction multiple data (SIMD) instruction set extensions to take advantage of the dataparallelism inherent in streaming signal processing and graphics applications. There is a greatdeal of diversity in the features included in the various NSP extensions, possibly due to the factthat we are just beginning to understand the workloads targeted by the extensions.Altivec is unique among the NSP extensions because it adds support for a separate 128bit vector multimedia unit in the processor [1]. Altivec technology is available in the currentlyshipping PowerPC 7400 processor and another recently announced [2] member of the PowerPCG4 family.Altivec is the only NSP extension that we identified through our research which offersthirty-two 128 bit wide dedicated vector registers. Unlike the Intel x86 compatible NSPextensions, there is no performance penalty associated with a ‘context switch’ to switch in or outof vector mode. In fact, it is possible to write code that uses the integer unit, vector unit, andfloating point unit concurrently on a PowerPC processor that implements Altivec [3]. The vectorregisters provide 8-way parallelism for 16-bit signed and unsigned integers and 16-wayparallelism for 8-bit signed and unsigned integers. Saturation arithmetic and a rich variety ofinstructions are included in the Altivec instruction set. The Altivec programming model isdocumented in [4,5].Currently, programmers must modify existing applications or write applications explicitlyfor a certain NSP extension. In [6, 7, 8] it was stated that this requirement presents significantusage problems for the NSP extensions. Since the new data-types and operations on them are notstandardized, code utilizing them is not portable at the source level between different NSPextensions. Using libraries provided by the processor vendors doesn’t remedy this portabilityproblem, due to the fact that the library API’s are also not standardized. Compiler supporttypically uses function inlining or macro calls in code segments that will benefit from using theNSP extensions [6]. Ideally, compilers of the future will be able to analyze and ‘auto-vectorize’code to be optimized for a given NSP extension. This would make the new semantics invisible tothe programmer, but such compilers do not currently exist [6]. A possible solution to thisproblem is finding an abstract representation that can efficiently be converted to software for anarbitrary NSP extension. We discuss using Ptolemy to accomplish this solution in the nextsection.2 Programming with Altivec in PtolemyPtolemy is a software environment for the simulation and prototyping of heterogeneoussystems [9]. It provides a software engineer or hardware designer a clear view of naturalpartitions of software and hardware in a single, heterogeneous environment.This is accomplished in Ptolemy by providing an object-oriented kernel that is free fromany particular model of computation. New models of computation (domains) can be easily addedwithout affecting existing domains. A domain may either simulate on a desktop workstation orsynthesize code. Once implemented, domains can be interwoven and manipulated. Thus,Ptolemy provides a heuristic approach to specify, simulate, and synthesize heterogeneoussystems, which in general, is a very difficult problem.“Code generation” refers to the synthesis of software corresponding to the algorithm [9].The Ptolemy stars we developed produce C source code that use Motorola’s Altivec extensions.Ptolemy (combined with the tools described below in section 3.1) provides a complete designsystem from concept to implementation to synthesis and test. The kernels developed by theauthors can form the basis of larger systems. Such systems can be prototyped with relative easein a “plug-and-play” manner – Altivec stars are substituted for their scalar versions in a graphicalenvironment and almost immediately the resultant system can be evaluated. Chen, Reekie,Bhavem, and Lee conducted similar work in [7] using the NSP instructions of the Sun UltraSparcarchitecture, VIS.3 Implementing Altivec enhanced NSP Kernels3.1 Tool-set usedWe used several tools in addition to Ptolemy to complete our experiments. The GNUcompiler enhanced with support for Altivec [10] was used to compile the code generated byPtolemy. The GNU compiler was configured as a cross-compiler targeting ‘powerpc-eabisim.’The ‘powerpc-eabisim’ executables were then run on the Psim PowerPC simulator. The Psimsimulator is included among the GNU tools bundled with the GNU compiler. We used the tracegeneration capabilities of Psim to generate traces that were then used by the sim_g4 [11]PowerPC timing simulator to provide detailed timing information.3.2 Fixed Point FIR ImplementationWe chose to implement the FIR filter due to its widespread use in signal processingapplications. It was shown by Daubechies in [12] that under certain regularity conditionsdiscrete-time filters will lead to continuous-time wavelets. This is a very practical and extremelyuseful wavelet decomposition scheme, since FIR discrete-time filters can be used to implementthem. Wavelet transforms have gained widespread acceptance in signal processing in general,and in image compression research in particular.Another contemporary example of the use of an FIR is in computer graphics. Aliasingeffects in computer-generated images are seen in the jagged edges of rendered objects.


View Full Document

UT EE 382C - Native Signal Processing With Altivec In the Ptolemy Environment

Documents in this Course
Load more
Download Native Signal Processing With Altivec In the Ptolemy Environment
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Native Signal Processing With Altivec In the Ptolemy Environment and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Native Signal Processing With Altivec In the Ptolemy Environment 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?