Center for Embedded Computer Systems University of California, Irvine Design of a MP3 Decoder using the System-On-Chip Environment (SCE) Andreas Gerstlauer Dongwan Shin Samar Abdi Pramod Chandraiah Daniel D. Gajski Technical Report CECS-07-05 November 2, 2007 Center for Embedded Computer Systems University of California, Irvine Irvine, CA 92697-2625, USA (949) 824-8919 {gerstl,dongwans,sabdi,pramodc,gajski}@cecs.uci.edu http://www.cecs.uci.edu
Transcript
Center for Embedded Computer Systems
University of California, Irvine
Design of a MP3 Decoder using the System-On-Chip Environment(SCE)
Andreas GerstlauerDongwan Shin
Samar AbdiPramod Chandraiah
Daniel D. Gajski
Technical Report CECS-07-05November 2, 2007
Center for Embedded Computer SystemsUniversity of California, IrvineIrvine, CA 92697-2625, USA
AbstractElectronic system-level (ESL) design is touted as a promising solution to sustain productivity in embedded
system design in the presence of increasing complexities and decreasing time-to-market. The System-On-ChipEnvironment (SCE) provides such a SpecC-based ESL design solution. In this report, we demonstrate SCE asapplied to the design of a MP3 decoder. Starting from a reference C code, an initial specification model isdeveloped and several different architectural alternatives are explored for implementation on an ARM-basedtarget platform. Using SCE, models for all alternatives are generated and a final, optimal multi-processorsystem-on-chip (MPSoC) design is selected.
Results of the SCE-based design process show the feasibility and benefits of the approach. Using SCE re-finement and exploration tools, all models were generated within minutes. Including the time needed for modelsimulations, the overall exploration process was completed within an hour. Therefore, the design example demon-strates the capabilities of SCE for rapid, early design space exploration resulting in significant productivity gains.
AbstractElectronic system-level (ESL) design is touted as apromising solution to sustain productivity in embed-ded system design in the presence of increasing com-plexities and decreasing time-to-market. The System-On-Chip Environment (SCE) provides such a SpecC-based ESL design solution. In this report, we demon-strate SCE as applied to the design of a MP3 decoder.Starting from a reference C code, an initial specifica-tion model is developed and several different archi-tectural alternatives are explored for implementationon an ARM-based target platform. Using SCE, mod-els for all alternatives are generated and a final, opti-mal multi-processor system-on-chip (MPSoC) designis selected.
Results of the SCE-based design process show thefeasibility and benefits of the approach. Using SCErefinement and exploration tools, all models weregenerated within minutes. Including the time neededfor model simulations, the overall exploration pro-cess was completed within an hour. Therefore, thedesign example demonstrates the capabilities of SCEfor rapid, early design space exploration resulting insignificant productivity gains.
1 IntroductionIn the presence of ever-increasing system complexi-ties and time-to-market pressures, the design of em-bedded systems is facing a growing productivity gap.New methods and tools are needed to sustain the re-quired productivity. Electronic system level (ESL)design has been touted as one of the most promising
solutions. ESL approaches aim to close this gap byraising the design process, supported by correspond-ing design automation tools, to higher levels of ab-straction.
The System-On-Chip Environment (SCE) is such acomprehensive ESL design solution for taking a com-plete embedded system design from initial specifica-tion down to its final implementation. SCE supportsa wide range of applications and target platforms fordesign of homogeneous multi-core or heterogeneousmulti-processor systems-on-chip (MPSoCs). In SCE,the system is gradually synthesized through a seriesof interactive exploration and automated refinementsteps. Leveraging human insight for crucial designdecisions while automating tedious and error-pronetasks like model rewriting enables SCE to deliver therequired productivity gains for rapid and early designspace exploration. Furthermore, SCE provides an au-tomated path all the way from high-level specificationdown to hardware/software implementation.
SCE is based on the SpecC system-level design lan-guage (SLDL) [5], and it follows a specify-explore-refine methodology [8]. The design process startsfrom a model specifying the design functionality(specify). At each following step, the designer first ex-plores the design space (explore) and makes the nec-essary design decisions. SCE then automatically gen-erates a new model at the next lower abstraction levelby integrating the decisions into the previous model(refine).
An overview of SCE is shown in Figure 1 [1]. Thedesign process starts with a specification model. Inthe general case, the specification model is an ab-
stract, high-level description of the desired function-ality, free of any implementation details [7]. Follow-ing a series of system exploration tasks, the speci-fication is then gradually and stepwise refined intotransaction-level models (TLMs) of the design atvarying levels of abstraction [13, 17, 15, 16]. Ineach step, the designer enters relevant design deci-sions through a graphical user interface (GUI) or us-ing SCE’s scripting capabilities [4]. Refinement toolsthen automatically generate a new model implement-ing and reflecting the user’s decisions. In the process,the system is defined, synthesized and assembled us-ing models of available system components taken outof a set of processing element (PE), communicationelement (CE) and bus databases [6]. As a result, witheach exploration and refinement step, a new layer ofimplementation detail is introduced.
All models in the SCE design flow are representedin SpecC form. As such, models at any stage are exe-cutable and can be simulated for validation and feed-back about design quality. Intermediate models in theflow allow for early and fast validation of critical de-sign aspects. In general, in an iterative process, de-signers can vary decisions, generate models and eval-uate effects through simulation or analysis until an op-timal system design has been reached.
The final pin-accurate model (PAM) of the selected
design solution can then be fed into a backend processfor further hardware and software synthesis of eachindividual system component. On the hardware side,high-level synthesis (HLS) of the behavioral, bus-functional description of each hardware componentin the PAM into a register-transfer level (RTL) imple-mentation is performed. In addition, SCE supportsfully automatic synthesis of software for each pro-grammable processor in the system. Target-specificcode is generated, compiled and linked against OSand other libraries taken out of a software database.For each processor, final processor binaries are gener-ated and an instruction-set simulator (ISS) running thetarget binary is re-integrated into the system model.
As a final result of the SCE design flow, the im-plementation model at the output of the backend pro-cess is a fully cycle- and pin-accurate description ofthe system design. Furthermore, Verilog/VHDL codeand target binaries generated for each hardware andsoftware processor, respectively, provide the data forfinal logic synthesis, manufacturing or FPGA-basedprototyping of the design.
In this report, we demonstrate the System-On-ChipEnvironment (SCE) as applied to the design of a typi-cal embedded system: an MP3 decoding algorithm asused in cell phones or MP3 players. Starting from theinitial C reference code we obtained from [12], we de-veloped the SpecC specification model of the designas a starting point for the design and exploration pro-cess (Section 2). Given the specification, we exploredseveral different target architectures for implementa-tion of the decoder on an ARM-based platform (Sec-tion 3). Using SCE tools, models of all candidateswere generated and evaluated, and an optimal archi-tecture was selected (Section 4). As a result of the de-sign and exploration process, the automatically gen-erated pin-accurate model of the chosen system de-sign is ready for final implementation through furtherbackend hardware and software synthesis.
2 SpecificationWe started the design process by developing a SpecCspecification model of the MP3 decoding algorithmbased on an open-source C reference implementationwe obtained from the internet [12]. Due to the fact
2
that SpecC is a complete superset of regular ANSIC, any C code can serve as an initial SpecC modelof the application. However, in order to be able tosynthesize the code and efficiently explore the designspace, the initial C code needs to be converted into aproper SpecC specification [9].
C to SpecC conversion needs to follow a processof stepwise refinement of the code. First, we per-formed a general cleanup of the C code in order toimprove synthesizability at the level of individual ex-pressions. Starting at the top level, we then graduallyconverted the C functional call hierarchy into a corre-sponding SpecC hierarchy, introducing and exposingstructural and behavioral dependencies, and replac-ing ambiguous C constructs with their explicit SpecCequivalents.
The resulting SpecC specification model of theMP3 decoder has 14,045 lines of code distributed over44 behaviors (out of which 29 are leaf behaviors).Conversion from C to SpecC code took approximately6 man-weeks, out of which 2 man-weeks were spenton initial C code cleanup and the remaining 4 man-weeks on C-to-SpecC hierarchy conversion.
2.1 Reference C CodeThe original MAD C code we obtained from [12] is“a new implementation of the ISO/IEC standards thatis unencumbered by the errors of other implemen-tations” and “not a derivation of the ISO referencesource or any other code.” The authors claim that con-siderable effort has been expended to ensure a correctimplementation, even in cases where the standards areambiguous or misleading.
We chose the MAD library as the basis for ourMP3 decoder implementation because it is based on100% fixed-pointer (integer) computation, allowing itto be implemented even on target processors withouta floating-point unit. All calculations in the decoderare performed with a 32-bit fixed-point integer repre-sentation. The MAD implementation we started frominternally supports 24-bit PCM output for increasedprecision and high-quality output. The SpecC model,however, only produces 16-bit stereo PCM output, us-ing simple rounding, clipping, and scaling of MAD’shigh-resolution samples down to 16 bits. As a basicimplementation, it does not employ any dithering or
Main
mp3decoder
nframes
stimulus errordecoder monitor
decoder_error
pcm_out
nframes
IMP3Decoder
stream_in
Figure 2: Top-level of MP3 SpecC specificationmodel.
noise shaping, which could increase the audible dy-namic range based on the extra resolution availableinternally.
The initial MAD implementation needed consid-erable cleanup before converting it into a specifica-tion model in SpecC. First of all, MAD was a com-plete MP3 player and included features such as ID3tag processing. We were only interested in the coreMP3 decoder functionality. As a first step, we deriveda light weight implementation of the core MP3 de-coder with a simple user interface by eliminating un-necessary files and functions. The platform-specificoptimizations included by MAD were also removed.Code that depended on advanced C library functionswere eliminated if they were determined not to affectthe decoding functionality. Further, the MAD imple-mentation used function pointers for some call-backfunctions. These function pointers were replaced withthe calls to the actual functions. Dynamic memory al-locations were analyzed and were replaced with safestatic allocations. This initial cleanup phase took ap-proximately 2 man-weeks.
2.2 SpecC ModelConversion of the C code to a SpecC hierarchy startsat the top level of the C functional call hierarchy, i.e.at the main() method. In the first step, the main()method is converted into an equivalent SpecC Mainbehavior. In the process, the testbench part of the ap-plication has to be separated out from the actual partsto be designed.
Figure 2 shows the results of this process for theMP3 decoder SpecC model. At the top-level, the
3
MP3 decoder Main behavior simply executes themp3decoder application, supplying the parsed com-mand line arguments like input and output file namesvia interface method calls and ports. Internally, thetop-level mp3decoder executes the actual Decoderdesign next to testbench behaviors for file I/O includ-ing supplying input stimuli, monitoring resulting out-puts, and checking for fatal error exit conditions.
As is typical for a specification testbench setup,the testbench part (stimuli and monitor behaviors) runconcurrently to the actual design. Stimulus and Moni-tor behaviors are supplied with the names of input andoutput files to read from and write to through portsconnected to the overall Main behavior. Internally, thedesign communicates with the testbench through ab-stract channels for incoming MP3 bytes (stream in),outgoing PCM samples (pcm out) and asynchronouserror conditions (decoder error). All three channelsare FIFO queues for buffering of frame data and de-coupling of threads in order to improve performance.
The actual Decoder application to be designed(Figure 3) is at its highest level a finite state machine,captured in a SpecC fsm composition. After initial-ization and setup of the decoder (init and mute states),the decoder successively starts reading bytes from theinput MP3 stream channel (stream in) until a com-plete frame has been received. Since MP3 frames canbe of variable length and since a frame’s main datacan include data from past and/or future frames (neg-ative and positive main data offset aka MP3 bit reser-voir), the frame header needs to be decoded in orderto determine how many bytes need to be read fromthe input stream. Therefore, input and decode headerstates run in a loop until a complete frame has been in-ternally buffered (in the local stream array). Once theheader has been completely decoded and a completeframe of data is available, decoding continues withprocessing of the frame body (decoder frame). Theresult of frame decoding is the set of decoded subbandsamples for the given frame (frame sbsample). Fi-nally, a last synth state performs full frequency PCMsynthesis to produce the final PCM samples sent outover the pcm out channel.
After a frame has been successfully decoded anda final error check has been performed (recover), theDecoder loops back to the setup state (mute) in order
Figure 3: Behavioral and structural hierarchy of MP3decoding.
the begin processing of the next frame. In general, er-rors can occur at any stage of the decoding process.Errors are subdivided into recoverable and fatal er-rors. In each state, decoding errors, e.g. due to invalidinput data, are checked. If a recoverable error is de-tected, the state machine branches directly to the re-cover state, which will try to restore the internal statevariables of the decoder to a sane status before jump-ing ahead to the decoding of the next frame. Since thestart of a frame in the input stream is not known, thedecode header state (in a loop with the input state)will try to re-synchronize decoding in such situations
4
Mad_frame_decode
fail
layer_III
init
preload
anc
sideinfo
main_data
decode
init
granule
init
Figure 4: Behavior hierarchy of MP3 frame decoding.
III_decode
granule
init
getdata
stereo
channels
left
right
right
left
scalefac
aliasreduce
imdct
huff
aliasreduce
imdct
huff
scalefac
Figure 5: Behavior hierarchy of granule decoding inan MP3 frame.
5
by scanning the input stream until the next synchro-nization word marking the start of a frame is received.In all cases, if recovery or synchronization fails, or if afatal error occurs at any stage of the decoding process,the Decoder will branch to the fail state before exitingthe decoding completely (finish). Also, the decoderwill finish if the end of the stream has been reached,i.e. no more input is available.
2.2.1 Frame Decoding
The internal decomposition of the frame decodingstate is shown in more detail in Figure 4. TheFrame decode behavior is sequentially composed outof a multi-level hierarchy of subbehaviors. At the top-most level, frame decoding consists of a state machinethat performs the actual MPEG layer III decoding en-closed by initialization and error handling states. TheLayer III behavior is then further decomposed intoa state machine for the actual decoding and signalprocessing chain. Layer III processing consists ofstates for initialization (init), decoding of frame sideinformation (sideinfo), preprocessing and collectionof frame main data (main data), core layer III decod-ing (decode), designation of ancillary bits (anc), andpreloading of next frame’s data (preload). Further-more, the core decoding is further subdivided into astate machine that, after some initialization, sequen-tially loops over the two granules that form the coreof each MP3 frame.
Figure 5 shows this core layer III decoding withgranule processing (granule) further expanded. De-coding of each of the two granules is subdivided intothree major states: data demultiplexing and decom-pression (getdata), joint stereo decoding (stereo) andstereo channel decoding (channels). Note that thestereo step is skipped if the stream does not use jointstereo encoding. Both getdata and channels decod-ing internally each contain two instances of basic sin-gle channel processing behaviors, one instance eachper left and right channel. Data demultiplexing anddecompression consists of scalefactor (scalefac) andhuffman (huff ) decoding for each channel. On theother hand, decoding of each stereo channel consistsof anti-aliasing (alias reduction, aliasreduce) and anIMDCT (imdct) for conversion from the frequencyinto the time domain.
Mad_synth_frame
synth_full
synth_init
...th_header
output
synth_channel0 synth_channel1
filtercorefiltercore
init
calc_sample calc_sample
dct32dct32
init
Figure 6: Behavior hierarchy of MP3 PCM synthesis.
For channels decoding, both channels can be de-coded in parallel. On the other hand, since internalstate is kept during huffman decoding, successive in-vocations of huff are not independent of each other.Therefore, neither the two channels in the getdatablock nor the two granules themselves can be decodedconcurrently, i.e. due to the dependencies across in-vocations, the correct sequential order of huffman de-coding calls needs to be maintained.
Finally, note that on each level of frame decoding,error handling is performed asynchronously to theregular decoding chain. If the stream is in error con-dition or if errors are detected during input data pro-cessing (main data or granule’s getdata), the globalerror conditions is set and decoding is aborted, i.e. thecontrol flow transitions to the exit state through eachlevel of the hierarchy.
6
2.2.2 PCM Synthesis
The last stage of the MP3 decoding process is the fi-nal synthesis of the PCM samples, shown in more de-tail in Figure 6. At the top level, the Synth frame be-havior sequentially performs the actual full-frequencyPCM synthesis (synth full), preceded and followed bysmall blocks for variable initialization (synth init) andheader post-processing (synth header), respectively.
The synth full behavior is then further composedout of two instances of a synth channel behavior run-ning in parallel. Each of the two instances is inde-pendently responsible for synthesizing one of the twostereo output channels from the given input array ofsubband samples. Internally, each channel behaviorexecutes the respective synthesis filter core (filtercore)repeatedly in a loop, once for each group of 32 out-put samples to be produced per channel. Synthesiz-ing each block of 32 samples then consists of an ini-tialization step (init), a discrete cosine transformation(dct32), and rounding, clipping and quantization ofsamples (calc sample).
Finally, following the core PCM synthesis, the fi-nal output behavior then takes the internally bufferedsamples and sends them to the testbench via the out-put FIFO queue pcm out.
3 Design Space ExplorationGiven the specification model, we investigated a real-ization of the MP3 decoder design on an ARM-basedtarget platform [2]. In the process, we explored sev-eral different architectural alternatives for implemen-tation of the decoder across software and hardwaredomains. The main objective of design space explo-ration was the optimization of the overall MP3 framedecoding delay. Based on the sequential nature ofthe MP3 specification at its upper layers, optimiza-tion was primarily focused on hardware accelerationof critical blocks, with exploitation of available paral-lelism as a secondary goal.
Using SCE’s profiling and estimation capabilities[3], we analyzed the computational complexity of theMP3 decoding algorithm. Combining dynamic pro-filing of the input specification model simulation witha static analysis and matching of specification and
ARM (ARM7)
Ma i n B u s (AMB A_ AH B )
mas
ter0
Arbiter
MP 3 _ I N P C M_ O U T
slave
1
slave
2
Mad_Decoder
Mad_S t i m u l u s
OS (round-rob i n)
s t ream _i n p cm _ou t
Mad_
Monit
or
Mad_
Erro
r
Arm/In Arm/O u t
Figure 8: MP3 platform with pure software imple-mentation (SWPE).
ARM processor characteristics, the SCE profiler gen-erates estimates about the software execution times ofeach MP3 block on the given ARM processor. Fig-ure 7 shows the estimated total delays per block ob-tained for a decoding of eight MP3 frames. As shownin Figure 7(a), overall MP3 decoding delays are al-most evenly distributed between frame decoding andPCM synthesis. Looking at individual leaf behav-iors of the frame decoding and PCM synthesis blocks(Figure 7(b), major contributors in each block are theImdct and Dct behaviors, respectively. Furthermore,the regular and inverse modified discrete cosine trans-forms (DCT and IMDCT) are both widely-used, gen-eral digital filter algorithms, i.e. advanced hardwareimplementations are readily available. As such, theymake good candidates for hardware acceleration.
3.1 Pure Software Implementation
We started the design and exploration process by in-vestigating a pure software solution of the MP3 de-coding algorithm running on an ARM7TDMI targetprocessor. As shown in Figure 8, in this most ba-sic target architecture, the ARM processor runs themain Decoder behavior on top of a real-time operat-ing system. In our case, we chose µC/OS-II [18] usinga round-robin scheduling strategy as target operatingsystem. As part of the scheduling exploration step in
Figure 7: Computational complexity of MP3 decoder blocks.
the SCE design process, all parallel behavior compo-sitions for left and right channel processing inside thegranule decoding and PCM synth blocks were refinedinto dynamically spawned tasks running concurrentlyon top of the OS. For validation of and feedback aboutdynamic scheduling effects during simulation, SCEautomatically inserts an abstract, high-level model ofthe chosen operating system into the generated TLMand PAM design models [11].
In addition to the actual decoding algorithm run-ning on the ARM, the processor is assisted by twohardware I/O units for MP3 stream input and PCMspeech sample output processing and buffering. Assuch, the Stimulus, Monitor and Error behaviors ofthe top-level MP3 design specification are mapped toMP3 IN and PCM OUT I/O units, respectively. Fur-thermore, note that the two FIFO queues for streaminput and PCM output between the decoder andthe monitor and stimulus behaviors have each beenmapped into the corresponding hardware unit for im-plementation. Using SCE, the queues will thereforebe implemented as local send and receive FIFOs in-side each of the hardware I/O processors.
The ARM processor and the I/O blocks communi-cate over a single instance of an AMBA AHB localprocessor bus. The ARM processor is a master on itsbus and the two I/O units are synthesized to connect asAHB slaves. As such, all communication between theARM processor and the I/O units will be routed overthe AHB bus. Specifically, the decoder running on theARM processor will read input MP3 stream data fromand write output PCM samples to the hardware FIFOs
in the MP3 IN and PCM OUT I/O blocks, respec-tively. All communication between the ARM proces-sor and the I/O queues is implemented by mappingFIFO registers and link channels into the AHB ad-dress space using dedicated bus addresses and pro-cessor interrupt lines.
3.2 DCT Hardware AccelerationIn the first step of the exploration and optimizationprocess, we chose the critical Dct32 component (seeFigure 7(b)) as the candidate for hardware-assistedacceleration in a co-processor fashion. The Dct32 wasmapped into a separate, stand-alone hardware PE thatacts as a slave to the main decoding algorithm run-ning on the master ARM processor. As a result, whenreaching the corresponding stage in the decoding pro-cess, the ARM will send the input data to the DCThardware component for processing. The ARM soft-ware will then wait for the results coming back fromthe DCT before continuing with the decoding process.While waiting for the DCT, the operating system onthe ARM can swap in and switch over to any otherready task, thus exploiting available parallelism onthe software side, if any.
The resulting system computation and communi-cation architecture is shown in Figure 9. In this firststep, we allocated only a single DCT co-processor.The single DCT hardware PE is shared between bothleft and right channel PCM synthesis processes onthe ARM (running two independent, concurrent loopsfor processing of samples each, see Figure 6). All inthe hope to exploit the parallelism (across loop itera-
8
ARM (ARM7)
Ma i n B u s (AMB A_ AH B )
mas
ter0
Arbiter
MP 3 _ I N P C M_ O U T
slave
1
I P B u s
D C T (I P )
slave
2
slave
3
Mas
ter
Slav
e
Mad_Decoder
Mad_S t i m u l u s
OS (round-rob i n)
s t ream _i n p cm _ou t
Mad_
Monit
or
Mad_
Erro
r Dt c3 2
T XArm/D c t
Arm/I n Arm/O u t
(a) IP-based DCT hardware.
ARM (ARM7)
Ma i n B u s (AMB A_ AH B )
mas
ter0
Arbiter
MP 3 _ I N P C M_ O U T
slave
1
D C T (H W )
slave
2
slave
3
Mad_Decoder
Mad_S t i m u l u s
OS (round-rob i n)
s t ream _i n p cm _ou t
Mad_
Monit
or
Mad_
Erro
r Dt c3 2
Arm/D c tArm/I n Arm/O u t
(b) Synthesized DCT hardware.
Figure 9: MP3 platform with DCT hardware accelerator (HWSW1).
tions) between calc sample processing of one channelon the ARM while waiting for the dct32 of the otherchannel being processed in hardware (and vice versa).
In the process of DCT acceleration, we exploredtwo different architectural variants: reuse of a pre-designed DCT IP component (Figure 9(a)), and syn-thesis of a fully-custom DCT hardware unit fromscratch (Figure 9(b)). In the latter case, the customhardware unit can be synthesized with SCE to imple-ment any bus interface. Therefore, it can be directlyconnected to and implement the AHB slave proto-col. In this case, all communication for sending inputblocks from the ARM to the DCT and for receivingtransformed results back from the DCT to the ARMwill go over the main AHB bus. Following the co-processor principle, the DCT is a slave on the mainsystem bus and the ARM controls all transfers as thesingle master on its bus. To send events for status up-dates to the ARM processor, the DCT hardware gen-erates interrupts and is connected to selected proces-sor interrupt input lines.
In the IP case, the DCT IP component is directlyconnected to and comes with its own local, dedicatedIPBus. A transducer is then added to the communi-cation architecture, translating between the two pro-tocols and connecting the IP component to the mainAHB bus. As such, all communication between theARM processor and the DCT IP has to go over thetransducer and the two busses. Again, the ARM isthe single master on its bus. The transducer is a slave
on the system bus and a master for the IP, relayingall ARM request for sending and receiving of data tothe IP. Again interrupts are used for event notificationfrom the DCT to the ARM, relayed by the transducer.
3.3 Parallelized DCT Hardware Accelera-tion
The next logical step in hardware acceleration is toduplicate the DCT unit in order to provide dedicatedco-processor instances for each of the two channels.Theoretically, including two independent LDCT andRDCT hardware PEs enables further exploitation ofavailable parallelism by allowing to run the two DCTinstances in the left and right channel concurrently atthe same time.
Figure 10 shows the corresponding architectureswith two DCT units, one for each channel. Again,we implemented both an IP-based architecture withtransducer (Figure 10(a) and an architecture with syn-thesizable DCT hardware PEs directly connected tothe AHB bus (Figure 10(b)). In the former case, itwas assumed that both DCT IPs can be connectedto a shared instance of a single IPBus. Without lossof generality, an architecture with two separate, dedi-cated busses for each IP would be a simple, straight-forward extension that is not shown here.
9
ARM (ARM7)
Ma i n B u s (AMB A_ AH B )
mas
ter0
Arbiter
MP 3 _ I N P C M_ O U T
slave
1
I P B u s
RD C T (I P )
L D C T (I P )
slave
2
slave
3
Mas
ter
Slav
eSlav
e
Mad_Decoder
Mad_S t i m u l u s
OS (round-rob i n)
s t ream _i n p cm _ou t
Mad_
Monit
or
Mad_
Error
Dt c3 2
Dct 3 2
T XArm/L D c tArm/R D c t
Arm/I n Arm/O u t
(a) IP-based DCT hardware.
ARM (ARM7)
Ma i n B u s (AMB A_ AH B )
mas
ter0
Arbiter
MP 3 _ I N P C M_ O U T
slave
1
RD C T (H W )
L D C T (H W )
slave
2
slave
3sla
ve4
Mad_Decoder
Mad_S t i m u l u s
OS (round-rob i n)
s t ream _i n p cm _ou t
Mad_
Monit
or
Mad_
Error
Dct 3 2
Dct 3 2
Arm/L D c t Arm/R D c tArm/I n Arm/O u t
(b) Synthesized DCT hardware.
Figure 10: MP3 platform with concurrent DCT hardware accelerators (HWSW2).
ARM (ARM7)
Ma i n B u s (AMB A_ AH B )
mas
ter0
Arbiter
MP 3 _ I N P C M_ O U T
slave
1
I P B u s
RI MD C T (I P )
L I MD C T (I P )
slave
2
slave
3
Mas
ter
Slav
eSlav
e
Mad_Decoder
Mad_S t i m u l u s
OS (round-rob i n)
s t ream _i n p cm _ou t
Mad_
Monit
or
Mad_
Error
I m dct
I m dct
T XArm/L I md c tArm/R I md c t
Arm/I n Arm/O u t
(a) IP-based DCT hardware.
ARM (ARM7)
Ma i n B u s (AMB A_ AH B )
mas
ter0
Arbiter
MP 3 _ I N P C M_ O U T
slave
1
RI MD C T (H W )
L I MD C T (H W )
slave
2
slave
3sla
ve4
Mad_Decoder
Mad_S t i m u l u s
OS (round-rob i n)
s t ream _i n p cm _ou t
Mad_
Monit
or
Mad_
Error
I m dct
I m dct
Arm/L I md c t Arm/R I md c tArm/I n Arm/O u t
(b) Synthesized DCT hardware.
Figure 11: MP3 platform with concurrent IMDCT hardware accelerators (HWSW3).
ARM (ARM7)
Ma i n B u s (AMB A_ AH B )
mas
ter0
Arbiter
MP 3 _ I N P C M_ O U T
slave
1
I P B u s
RI MD C T (I P ) RD C T (I P )
L I MD C T (I P ) L D C T (I P )
slave
2
slave
3
Mas
ter
Slav
e
Slav
eSlav
e
Slav
e
Mad_Decoder
Mad_S t i m u l u s
OS (round-rob i n)
s t ream _i n p cm _ou t
Mad_
Monit
or
Mad_
Error Dct 3 2
Dct 3 2I m dct
I m dct
Arm/L D c t
T XArm/L I md c t
Arm/R D c tArm/R I md c t
Arm/I n Arm/O u t
(a) IP-based DCT hardware.
ARM (ARM7)
Ma i n B u s (AMB A_ AH B )
mas
ter0
Arbiter
MP 3 _ I N P C M_ O U T
slave
1
RI MD C T (H W ) RD C T (H W )
L I MD C T (H W ) L D C T (H W )
slave
2
slave
3
slave
5sla
ve6
slave
4
Mad_Decoder
Mad_S t i m u l u s
OS (round-rob i n)
s t ream _i n p cm _ou t
Mad_
Monit
or
Mad_
Error Dct 3 2
Dct 3 2I m dct
I m dct
Arm/L D c tArm/L I md c t Arm/R D c tArm/R I md c tArm/I n Arm/O u t
(b) Synthesized DCT hardware.
Figure 12: MP3 platform with DCT and IMDCT hardware accelerators (HWSW4).
10
3.4 Parallelized IMDCT Hardware Acceler-ation
In addition to acceleration of the PCM synthesisstage, we investigated options for decreasing the de-lay in the frame decoding stage of the MP3 decodingalgorithm. As shown in Figure 7(a), both stages aresimilar in their workload and contribution to overallframe delays. Furthermore, from Figure 7(b), it canbe concluded that the Imdct block is the most criti-cal leaf behavior in the frame decoding stage, i.e. theprimary candidate for hardware acceleration there.
In order to be able to explore effects of frame de-coding optimizations independent of and unaffectedby PCM synthesis modifications, we first explored ac-celeration of only the Imdct block alone. Similar tothe Dct32 behavior in the synthesis stage, the MP3specification executes two instances of the Imdct con-currently as part of parallel left and right channel de-coding (Figure 5). Note, however, that even thoughconcurrent channel decoding is executed in a loopover the two granules that are part of each MP3 frame,parallelism does not extend across loop iterations. Asspecified, both threads have to be joined before thenext loop iteration can be started.
Therefore, we did not further investigate a so-lution with a single IMDCT hardware unit sharedacross channels. Instead, we directly implementedan architecture with separate, dedicated LIMDCT andRIMDCT PEs allowing for maximal parallelism be-tween the left and right channel decoding tasks, re-spectively.
The result of that exploration step is shown in Fig-ure 11. Following the two variants for the DCTcase, we explored both an IP-based (Figure 11(a))and a custom synthesized (Figure 11(b)) version ofthe IMDCT hardware units. In all cases, IMDCTsoperate as co-processors, i.e. they act as slaves to thesingle master ARM processor on the main system bus.In the IP case, the IMDCTs are connected to their ownIPBus and a transducer connects the IP bus as slave tothe main bus. Interrupts are used for synchronizationand event notification from IMDCT PEs to the ARMprocessor in each case.
3.5 DCT and IMDCT Hardware Accelera-tion
Based on the fully parallelized and hardware acceler-ated architectures presented in Section 3.3 and Sec-tion 3.5, we created a first combined, maximally par-allel system architecture which includes both DCTand IMDCT co-processors. To allow exploitation ofall potential and available concurrency, the resultingsystem includes separate, dedicated LDCT/LIMDCTand RDCT/RIMDCT hardware PEs for left and rightchannels, respectively (Figure 12).
Similar to previous cases, we created architectureswith both IP-based and synthesized implementationsof DCT and IMDCT co-processors (Figure 12(a) andFigure 12(b), respectively). In the IP-based solution,all four IP components are assumed (without loss ofgenerality) to be connected as slaves to a common,shared IPBus instances that is connected to the mainsystem bus via a transducer. In the case of synthe-sizable custom hardware components, all four co-processors are directly connected as and synthesizedto become slaves on the AHB bus. In all cases, co-processors are slaves listening to and generating in-terrupts for a sole master ARM processor.
3.6 Pipelined DCT and IMDCT HardwareAcceleration
Even in the most parallel system architecture (Sec-tion 3.5), the available concurrency within each MP3frame is limited by the sequential nature and the in-herent dependencies of the MP3 decoding algorithm.We can, however, increase performance further bypipelining the decoding algorithm in order to ex-pose and exploit additional parallelism that is avail-able across successive MP3 frames. This can beachieved by splitting the decoder into two parts dis-tributed across different processors such that the soft-ware on the ARM processor can start processing thenext frame while the hardware is finishing the lastsynthesis and PCM output stages of the current frame.
In the MP3 decoder this is possible because theonly dependencies are between stages in the sameframe (data passing from one stage to the next) andinside the same stage across frames (huffman and syn-thesis filter state kept across iterations). Specifically,
11
ARM (ARM7)
Ma i n B u s (AMB A_ AH B )
mas
ter0
Arbiter
MP 3 _ I N P C M_ O U T
slave
1
I P B u s 1I P B u s 2
RI MD C T (I P ) RD C T (I P )
L I MD C T (I P ) L D C T (I P )
slave
2 &
mas
ter1
slave
4sla
ve3
Mas
ter
Mas
ter
Slav
e
Slav
eSlav
e
Slav
e
Mad_Decoder
Mad_S t i m u l u s
OS (round-rob i n)
s t ream _i n p cm _ou t
Mad_
Monit
or
Mad_
Erro
r
Synth
_fram
e Dct 3 2
Dct 3 2I m dct
I m dct
Out/L D c t
T X 1
T X 2
A r m /L I m d c t
Out/R D c tA r m /R I m d c t
A r m /I n A r m /Out
(a) IP-based DCT hardware.
ARM (ARM7)
Ma i n B u s (AMB A_ AH B )
mas
ter0
Arbiter
MP 3 _ I N P C M_ O U T
slave
1
RI MD C T (H W ) RD C T (H W )
L I MD C T (H W ) L D C T (H W )
slave
2 &
mas
ter1
slave
3
slave
5sla
ve6
slave
4
Mad_Decoder
Mad_S t i m u l u s
OS (round-rob i n)
s t ream _i n p cm _ou t
Mad_
Monit
or
Mad_
Erro
r
Synth
_fram
e Dct 3 2
Dct 3 2I m dct
I m dct
Out/L D c tA r m /L I m d c t Out/R D c tA r m /R I m d c tA r m /I n A r m /Out
(b) Synthesized DCT hardware.
Figure 13: MP3 platform with pipelined DCT and IMDCT hardware accelerators (HWSW).
no dependencies exist between the PCM synthesisstage and the header or frame decoding stages of thenext frame. Therefore, in order to implement pipelin-ing of those two stages, the complete PCM synthesisand output block has to be mapped into hardware.
The resulting final, pipelined and parallelized MP3decoder system is shown in Figure 13. As describedin Section 3.1, the Output and Error stages were al-ready previously mapped into a separate PCM OUThardware. In order to enable pipelining, we alsomap the complete synth frame block into the samePCM OUT PE. As such, synth frame and Output be-haviors communicate PCM samples through the HW-local pcm out queue internally without involving theARM processor. This allows the PCM synthesis andoutput stages to run completely independent of thesoftware on the ARM.
The frame decoding software on the ARM and thePCM synthesis hardware in the PCM OUT PE areeach assisted by respective co-processors for IMDCTand DCT acceleration. Again, co-processors are du-plicated to include two dedicated PEs each for left andright channel processing. The ARM processor com-municates with the LIMDCT and RIMDCT compo-nents whereas the PCM OUT PE exchanges data withthe two DCTs. Since all four co-processors are actingas slaves, the PCM OUT has to become both a slave(for communication with the ARM) and a secondarymaster (for communication with LDCT and RDCT)on the main system bus. As such, the AHB bus im-plementation needs to include a mandatory bus arbiter
component.As in all previous explorations, we implemented
two architectures using either IP components (Fig-ure 13(a)) or synthesizing custom hardware (Fig-ure 13(b)) for each co-processor. In the latter case, allfour co-processors are synthesized to become AHBbus slaves directly connected to the main system bus.In the former case, IP components require separateinstances of their own, proprietary IP bus protocol.Transducers then connect the IP busses to the AHBsystem bus, translating between the two.
In contrast to all previous architectures with asingle ARM master component only, the two AHBbus masters (ARM and PCM OUT) can access co-processors concurrently. Therefore, to avoid poten-tial contention of concurrent accesses by competingmasters on a single, slow IP bus, we allocated twoseparate IP busses connected via two transducers. Co-processors are evenly distributed and connected to thetwo IP busses based on a separation of left and rightchannels. The two separated busses allow the ARMand PCM OUT masters to concurrently access differ-ent channel co-processors each, removing the poten-tial bottleneck of a single, shared IP bus1.
1Note that due to the speed difference between the AHB andIP busses, transactions are buffered in the transducers based ona store-and-forward principle. Therefore, the AHB bus is not abottleneck. Even though they are serialized by arbitration, AHBmasters can fill or empty the buffers in the transducers faster thanand while transducers perform slow transactions on the IP busses.
12
4 Refinement Results
Going through the different exploration and refine-ment steps of the SCE design and tool flow, we real-ized the design implementations for all explored sys-tem architectures as described in Section 3. UsingSCE’s automatic model generation and refinement ca-pabilities, transaction-level and pin-accurate models(TLM and PAM) at varying levels of abstraction wereautomatically generated for each of the design alter-natives [10]. Using SCE tools, models for all targetimplementations were generated within minutes. Fur-thermore, including time needed for validation andsimulation of models, the complete design space ex-ploration process was completed in less than an hour.
In all cases, we brought down the implementationto a final pin-accurate model ready for further hard-ware and software synthesis. For final sign-off, allmodels were executed for validation through simula-tion. Model simulations were performed on a 2.8 GHzIntel Pentium 4 workstation running Linux. Valida-tion of models was based on a testbench that exercisesthe MP3 design by decoding 10 frames of a stereoMP3 test stream with 44.1 kHz sampling frequencyand a (constant) bitrate of 96 kbit/s. Note that sincea MP3 frame consists of 1152 PCM samples, eachframe corresponds to 26.12 ms and the total decodedstream length for this setup is 0.2612 s of audio.
Results for the pin-accurate models of all exploredsystem architectures and for the initial specificationmodel are summarized in Table 1. For each model,the table shows model statistics such as lines of code(LOC) and number of behaviors (overall and leaf) andchannels. In addition, the time needed to simulate themodel, the simulated MP3 frame decoding delay andthe total runtime of the refinemenent tools for gener-ation of the model are listed.
As is always the case for a purely functional model,the initial specification executes in zero time, i.e. witha frame delay of zero. Furthermore, specification sim-ulation is very fast, running the algorithm nativelywith no extra overhead on the simulation host. Allsubsequent pin-accurate models, on the other hand,have significantly higher simulation times due to theextra implementation detail and resulting simulationoverhead in those models. Note that a large part of
the overhead at the pin-accurate level can be attributedto the simulation of events on bus wires. Accuratebus-functional models are necessary for further hard-ware synthesis. On the other hand, for simulation andvalidation, those details can be abstracted away. Ap-plying transaction-level modeling (TLM) techniques,speedups of several orders of magnitude with no lossof accuracy can be achieved [14]. However, since wefocus on synthesis in this report, we do not includeany TLM results here.
In general, model complexities as measured bymodel statistics (i.e. static code size and number ofobjects) and simulation times are correlated to thecomplexity of the target architecture (number of com-ponents and busses). On the other hand, simulationtimes also depend on the amount of dynamically sim-ulated content and functionality, which are directly re-lated to the actual frame decoding delay. Note, how-ever, as discussed above, compared to the computa-tion content, slow simulation of communication func-tionality at the pin-accurate level will have a propor-tionally higher impact on simulation speeds than itsactual contribution to overall simulated frame delays.
As can be seen from the results, a pure softwaresolution SWPE meets the frame deadline (frame de-coding constraint) of 26.12 ms, but not comfortably.However, since there is not a big enough margin tocompensate for any variations in delays when tak-ing the high-level estimates down to their final imple-mentation, the software implementation is not con-sidered to be feasible. Looking at various levels ofhardware acceleration, we can conclude that in allcases IP-based solutions have higher frame delaysthan their synthesized counterparts. This is due tothe extra overhead necessary for translation to/fromand communication over the slower IP bus protocol.Hence, there is a clear trade-off between reuse of pre-designed IP components (i.e. cost reduction) and de-lays (i.e. speed).
Results for architecture HWSW1 and HWSW2 showthat frame delays actually increase when adding DCThardware acceleration. This can be attributed to thefact that the extra overhead for communication be-tween the ARM and the DCT units outweigh the ben-efits of speeding up the DCT algorithm in a hard-ware implementation. The DCT in the PCM synthesis
13
Statistics Simulation Frame GenerationModel LOC Behaviors Leafs Channels time delay timeSpecification 14,045 44 29 2 0.01 s 0.00 ms —SWPE 22,085 96 58 29 5.67 s 25.92 ms 4.01 s
HWSW1 IP 24,922 119 72 81 254.9 s 38.67 ms 5.40 sHW 23,766 114 68 57 157.6 s 26.34 ms 5.17 s
HWSW2 IP 24,800 119 72 81 255.4 s 38.67 ms 5.93 sHW 23,710 114 68 57 158.6 s 26.34 ms 5.60 s
HWSW3 IP 25,140 123 73 85 104.7 s 25.76 ms 7.35 sHW 24,042 118 69 61 65.9 s 20.29 ms 7.10 s
HWSW4 IP 27,404 143 85 129 377.9 s 38.51 ms 10.85 sHW 25,697 136 79 89 221.1 s 20.71 ms 10.24 s
HWSW IP 28,528 148 87 150 308.5 s 17.71 ms 12.46 sHW 26,847 142 83 110 225.2 s 12.46 ms 11.92 s
Table 1: Exploration and refinement results.
stage is executed in a loop, once for every group of32 samples. For the 10 frames decoded through thetestbench, the Dct32 behavior is invoked 575 times.On each invocation, a DCT co-processor requires toreceive and send about 2 kB of data. Therefore, ex-ternal DCT processing incurs significant traffic on thebus(es) in each frame. Furthermore, note that a par-allel implementation with duplicated DCTs does notbring any benefits as the frame delay is not affected.This shows that delays in the PCM synthesis stage arelimited by the software running on the ARM, i.e. anyadditional speedup of the DCT will not further reducethe overall delay.
Comparing the IMDCT-based architecture HWSW3with DCT acceleration, results are different. Hard-ware acceleration of the Imdct block reduces framedelay compared to the software solution. In theIMDCT case, communication overhead does not be-come a bottleneck and especially the custom synthe-sized IMDCT PEs markedly improve delays (for IP-based IMDCTs, on the other hand, the additional IPcommunication overhead and acceleration gains evenout).
In the case of architecture HWSW4, when combin-ing IMDCT and DCT acceleration results are mixed.Again, adding DCT acceleration increases delays.This effect is generally more pronounced for IP-basedDCT implementations due to the extra overhead for IPprotocol translation and communication in this case.
Therefore, an architecture with custom synthesizedco-processors can maintain delay gains whereas thedeadline is violated in the IP-based variant.
Finally, only the fully pipelined and parallelized ar-chitecture HWSW can achieve the required frame de-lays with a big enough margin. Pipelining of framedecoding on the ARM and PCM synthesis in hard-ware dramatically reduces overall delays. The par-allelism available across frame iterations provides byfar the biggest potential for speed gains (at the ex-pense of significantly higher hardware costs). There-fore, architecture HWSW, either in its IP-based or syn-thesized form, was chosen as the final system designfor an ARM-based implementation of the MP3 de-coder.
5 Summary and Conclusions
In this report, we presented the application of theSystem-On-Chip Environment (SCE) tool flow to thedesign of a MP3 decoder system on an ARM-basedtarget platform. The design process starts with a spec-ification model of the MP3 algorithm described in theSpecC system-level design language (SLDL). UsingSCE exploration and refinement tools, six differentbase architectures for implementation of the MP3 de-sign with varying levels of either IP-based or synthe-sized hardware acceleration were investigated. For all
14
design alternatives, transaction-level and pin-accuratemodels were automatically generated. All modelswere validated and evaluated through simulation. Anoptimal architecture with pipelined and parallelizedhardware acceleration of DCT and IMDCT blockswas obtained as the final system design and optimizedMP3 implementation. As a result of the explorationprocess, the final pin-accurate model of the selectedarchitecture serves as the input to the backend processfor further hardware and software synthesis.
Results show the feasibility of the approach andprove the tremendous benefit of a SCE-based elec-tronic system-level (ESL) design solution. Varyingmodels for all design alternatives were automaticallygenerated using SCE refinement tools. As a result,the exploration process was completed and an opti-mal architecture was selected in less than 1 hour, in-cluding time required for model validation and sim-ulation. In summary, significant productivity gainswith design times that are several orders of magnitudeshorter when compared to traditional manual model-ing and design approaches have been achieved.
wan Shin, Andreas Gerstlauer, Rainer Domer,and Daniel Gajski. System-on-chip environ-ment (SCE version 2.2.0 beta): Tutorial. Tech-nical Report CECS-TR-03-41, Center for Em-bedded Computer Systems, University of Cali-fornia, Irvine, July 2003.
[2] AMBA Home Page. www.arm.com/products/
solutions/AMBAHomePage.html.
[3] Lucai Cai, Andreas Gerstlauer, and Daniel D.Gajski. Retargetable profiling for rapid, earlysystem-level design space exploration. In Pro-ceedings of the Design Automation Conference(DAC), San Diego, CA, June 2004.
[4] Lukai Cai, Andreas Gerstlauer, Samar Abdi,Junyu Peng, Dongwan Shin, Haobo Yu, RainerDomer, and Daniel Gajski. System-on-chipenvironment (SCE version 2.2.0 beta): Man-ual. Technical Report CECS-TR-03-45, Center
for Embedded Computer Systems, University ofCalifornia, Irvine, December 2003.
[5] Daniel D. Gajski, Jianwen Zhu, Rainer Domer,Andreas Gerstlauer, and Shuqing Zhao. SpecC:Specification Language and Design Methodol-ogy. Kluwer Academic Publishers, 2000.
[6] Andreas Gerstlauer, Lukai Cai, Dongwan Shin,Haobo Yu, Junyu Peng, and Rainer Domer. SCEDatabase Reference Manual, Version 2.2.0 beta.Center for Embedded Computer Systems, Uni-versity of California, Irvine, July 2003.
[7] Andreas Gerstlauer and Rainer Domer. SCESpecification Model Reference Manual, Version2.2.0 beta. Center for Embedded ComputerSystems, University of California, Irvine, July2003.
[8] Andreas Gerstlauer, Rainer Domer, Junyu Peng,and Daniel D. Gajski. System Design: A Practi-cal Guide with SpecC. Kluwer Academic Pub-lishers, 2001.
[9] Andreas Gerstlauer, Kiran Ramineni, RainerDomer, and Daniel D. Gajski. System-on-chip specification style guide. Technical ReportCECS-TR-03-21, Center for Embedded Com-puter Systems, University of California, Irvine,June 2003.
[10] Andreas Gerstlauer, Donwan Shin, Junyu Peng,Rainer Domer, and Daniel D. Gajski. AutomaticLayer-Based Generation of System-On-ChipBus Communication Models. IEEE Transac-tions on Computer-Aided Design of IntergratedCircuits and Systems (TCAD), 26(9):1676–1687, September 2007.
[11] Andreas Gerstlauer, Haobo Yu, and Daniel D.Gajski. RTOS modeling for system level de-sign. In Ahmed A. Jerraya, Sungjoo Yoo, Nor-bert Wehn, and Diedrik Verkest, editors, Embed-ded Software for SoC. Kluwer Academic Pub-lishers, 2003.
[13] Junyu Peng, Andreas Gerstlauer, Rainer Domer,and Daniel D. Gajski. System-on-Chip Archi-tecture Modeling Style Guide. Technical ReportCECS-TR-04-22, Center for Embedded Com-puter Systems, University of California, Irvine,July 2004.
[14] Gunar Schirner and Rainer Domer. ResultOriented Modeling – A Novel Technique forFast and Accurate TLM. IEEE Transactionson Computer-Aided Design of Intergrated Cir-cuits and Systems (TCAD), 26(9):1688–1699,September 2007.
[15] Dongwan Shin, Lukai Cai, Andreas Gerst-lauer, Rainer Domer, and Daniel D. Gajski.System-on-Chip Transaction-Level ModelingStyle Guide. Technical Report CECS-TR-04-24,Center for Embedded Computer Systems, Uni-versity of California, Irvine, July 2004.
[16] Dongwan Shin, Andreas Gerstlauer, RainerDomer, and Daniel D. Gajski. System-on-ChipCommunication Modeling Style Guide. Techni-cal Report CECS-TR-04-25, Center for Embed-ded Computer Systems, University of Califor-nia, Irvine, July 2004.
[17] Dongwan Shin, Junyu Peng, Andreas Gerst-lauer, Rainer Domer, and Daniel D. Gajski.System-on-Chip Network Modeling StyleGuide. Technical Report CECS-TR-04-23,Center for Embedded Computer Systems,University of California, Irvine, July 2004.
