Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

Rapid Configuration & Instruction Selection for an ASIP 411
4. SPEECH RECOGNITION PROGRAM & ANALYSIS
We use a speech recognition application as a case study to demonstrate the
effectiveness of our approach. This application provides user voice control
over Unix commands in a Linux’ shell environment. It employs a template
matching based recognition approach‚ which requires the user to record at
least four samples for each Unix command that he/she wants to use. These
samples are recorded and are stored in a file. Moreover‚ since this software
involves a user’s voice‚ for the sake of consistency‚ a test bench is recorded
and is stored in another file.
The application consists of three main sections: record‚ pre-process‚ and
recognition. In the “record” section‚ it first loads the configuration of the
speaker‚ then it loads the pre-recorded test bench as inputs‚ and the prerecorded
samples into memory. After that‚ it puts the test bench into a queue
passing through to the next section. In the “pre-process” section‚ it copies
the data from the queue and divides the data into frame size segments. Then‚
it performs a filtering process using the Hamming window and applies singleprecision
floating-point 256-point FFT algorithm to the input data to minimize
the work done in the following recognition section. Afterwards‚ it calculates
the power spectrum of each frame and puts these frames back into the queue.
Finally‚ in the “recognition” section‚ it implements the template matching
approach utilising Euclid’s distance measure in which it compares the input
data with the pre-recorded samples that are loaded in memory during the
“record” section. In the next step‚ it stores the compared results in another
queue. If the three closest matches of pre-recorded samples are the same
command‚ then the program executes the matched Unix command. However‚
if the input data does not match the pre-recorded samples‚ the program goes
back to the “record” section to load the input again‚ and so on. Figure 30-4
shows the block diagram of speech recognition program.
As this application involves a human interface and operates in sequence‚
it is necessary to set certain real-time constraints. For example‚ it is assumed
that each voice command should be processed within 1 second after the user
finished his/her command. So‚ “record” section should take less than 0.25s
to put all the data into a queue. While “pre-process” and “recognition” should
consume less than 0.5s and 0.25s respectively.
Through a profiler we analysed the speech recognition software in a first
approximation. Table 30-2 shows the percentage of selected software functions
that are involved in this application in different Xtensa processors
configurations that we denote as P1‚ P2 and P3. P1 is an Xtensa processor
with the minimal configurable core options. P2 is a processor with Vectra DSP
Engine and its associated configurable core options. P3 is a processor with a
floating-point unit and its associated configurable core options (more
configurations are possible‚ but for the sake of efficacy‚ only these three
configurations are shown here). Moreover‚ in Table 30-2‚ the application spent
13.4% of time calling the single precision square root function in Xtensa