Mercurial > pygar
comparison documents/pygar-slides-handout.lyx @ 74:31fef269ae58 pygar svn.75
[svn r75] presentation for wednesdaty
author | rlm |
---|---|
date | Wed, 12 May 2010 02:25:34 -0400 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
73:0f86d486e38e | 74:31fef269ae58 |
---|---|
1 #LyX 1.6.4 created this file. For more info see http://www.lyx.org/ | |
2 \lyxformat 345 | |
3 \begin_document | |
4 \begin_header | |
5 \textclass article | |
6 \use_default_options true | |
7 \language english | |
8 \inputencoding auto | |
9 \font_roman default | |
10 \font_sans default | |
11 \font_typewriter default | |
12 \font_default_family default | |
13 \font_sc false | |
14 \font_osf false | |
15 \font_sf_scale 100 | |
16 \font_tt_scale 100 | |
17 | |
18 \graphics default | |
19 \paperfontsize default | |
20 \use_hyperref false | |
21 \papersize default | |
22 \use_geometry false | |
23 \use_amsmath 1 | |
24 \use_esint 1 | |
25 \cite_engine basic | |
26 \use_bibtopic false | |
27 \paperorientation portrait | |
28 \secnumdepth 3 | |
29 \tocdepth 3 | |
30 \paragraph_separation indent | |
31 \defskip medskip | |
32 \quotes_language english | |
33 \papercolumns 1 | |
34 \papersides 1 | |
35 \paperpagestyle default | |
36 \tracking_changes false | |
37 \output_changes false | |
38 \author "" | |
39 \author "" | |
40 \end_header | |
41 | |
42 \begin_body | |
43 | |
44 \begin_layout Title | |
45 Pygar: Parallel Audio Processing | |
46 \end_layout | |
47 | |
48 \begin_layout Author | |
49 Laurel Pardue, Robert McIntyre | |
50 \end_layout | |
51 | |
52 \begin_layout Subsection* | |
53 Problem | |
54 \end_layout | |
55 | |
56 \begin_layout Standard | |
57 Music naturally comes in parallel sequences of samples called | |
58 \emph on | |
59 voices | |
60 \emph default | |
61 (ex. | |
62 from multiple instruments). | |
63 Pure-software mixers are forced to pass these voices through the Von Neuman | |
64 bottleneck of a single processor, operating on these streams in series | |
65 and switching between each one quickly. | |
66 They are therefore naturally limited in the number of voices they can handle. | |
67 Worse, since the processing of each voice has to share the same processor, | |
68 too many voices at once can fully max out the processor and crash the system. | |
69 On typical laptop hardware and a high end software tool like ProTools, | |
70 this number is around 5. | |
71 Embedded devices have an even tougher time at meeting any sort of reasonable | |
72 timing requirements. | |
73 \end_layout | |
74 | |
75 \begin_layout Standard | |
76 [screenie Just 6 voices are enough to bring this session of ProTools to | |
77 it's knees.] | |
78 \end_layout | |
79 | |
80 \begin_layout Standard | |
81 We want the power of writing transforms for voices in a high level language | |
82 combined with a framework that applies these transforms to the voices in | |
83 parallel. | |
84 \end_layout | |
85 | |
86 \begin_layout Subsection* | |
87 Vision --- Pygar | |
88 \end_layout | |
89 | |
90 \begin_layout Standard | |
91 Our system addresses the limitations of pure software mixers. | |
92 It is a grid of SMIPS processors capped by a mixer. | |
93 The voices flow through the processors in parallel and are combined at | |
94 the final mixer into a single stream. | |
95 Each processor can be loaded with any arbitrary C program. | |
96 \end_layout | |
97 | |
98 \begin_layout Standard | |
99 \begin_inset Float figure | |
100 placement H | |
101 wide false | |
102 sideways false | |
103 status collapsed | |
104 | |
105 \begin_layout Plain Layout | |
106 \begin_inset Graphics | |
107 filename ../../../../Pygar/documents/000402.png | |
108 width 5in | |
109 | |
110 \end_inset | |
111 | |
112 | |
113 \begin_inset Caption | |
114 | |
115 \begin_layout Plain Layout | |
116 The audio data (“samples”) start in the memory, but are soon pulled into | |
117 action by the DMA (direct memory access). | |
118 The DMA sends the samples to a chain of 0 or more soft-cores, where they | |
119 are transformed according to the soft-cores’ algorithms. | |
120 After running the gauntlet of soft-cores, the samples flow first to a buffering | |
121 FIFO, and finally to a mixer, which sends the samples off to be played | |
122 by speakers or stored in a file. | |
123 | |
124 \end_layout | |
125 | |
126 \end_inset | |
127 | |
128 | |
129 \end_layout | |
130 | |
131 \begin_layout Plain Layout | |
132 | |
133 \end_layout | |
134 | |
135 \end_inset | |
136 | |
137 | |
138 \end_layout | |
139 | |
140 \begin_layout Subsection* | |
141 Steps | |
142 \end_layout | |
143 | |
144 \begin_layout Standard | |
145 The difficult part of this project is managing code reuse. | |
146 We need three things for success. | |
147 | |
148 \end_layout | |
149 | |
150 \begin_layout Itemize | |
151 SMIPS processor -- Easy. | |
152 Just use the Lab 5 processors. | |
153 \end_layout | |
154 | |
155 \begin_layout Itemize | |
156 Some way to program the processors | |
157 \end_layout | |
158 | |
159 \begin_layout Itemize | |
160 DMA (Direct Memory Access) to load voices into the processors. | |
161 \end_layout | |
162 | |
163 \begin_layout Standard | |
164 We use ScratchPad to load code into the processors. | |
165 ScratchPad is an Intel module which implements a cache hierarchy. | |
166 The hierarchy reaches all the way from RAM created on the FPGA to on-chip | |
167 DRAM to RAM on the host computer all the way to the Hard Disk of the host | |
168 computer. | |
169 The first time a processor tries to access one of its instructions, the | |
170 cache goes all the way to the hard disk of the host computer to retrieve | |
171 the data. | |
172 Subsequent attempts to access this data only go as far as the on-chip DRAM. | |
173 Each processor has its own ScratchPad and thus can be programmed independently. | |
174 The ScratchPad abstraction allows each processor to run a program of any | |
175 size. | |
176 \end_layout | |
177 | |
178 \begin_layout Standard | |
179 Music access is achieved through RRR, another Intel abstraction which allows | |
180 us to treat the hard disk of the host computer as if it were a normal FIFO. | |
181 \end_layout | |
182 | |
183 \begin_layout Subsection* | |
184 News | |
185 \end_layout | |
186 | |
187 \begin_layout Standard | |
188 We have run our system with 12 sample voices and various combinations of | |
189 simple c voice processing programs and the results have been better than | |
190 software implementations. | |
191 Significantly, increasing the number of voices does not increase the processing | |
192 load since each voice is processed in parallel. | |
193 \end_layout | |
194 | |
195 \begin_layout Subsection* | |
196 Contributions | |
197 \end_layout | |
198 | |
199 \begin_layout Itemize | |
200 Implemented Pygar, a system for quick parallel processing of audio. | |
201 | |
202 \end_layout | |
203 | |
204 \begin_layout Itemize | |
205 Implemented 4 basic algorithms which serve as components for this system | |
206 (identity, bit-shift, volume-change, and delay) | |
207 \end_layout | |
208 | |
209 \begin_layout Itemize | |
210 Demonstrated Pygar out-performs software-only systems. | |
211 Pure-software systems have a limit of around 6 voices, while our system | |
212 achieves 12 voices in parallel with no architecturally imposed limit on | |
213 the number of voices. | |
214 \end_layout | |
215 | |
216 \end_body | |
217 \end_document |