Oct 13, 2012
This lab is a team exercise.
Please use the discussion
board of Canvas for Q&A.
All reports and code MUST be submitted to the
digital assignment of Canvas.
The goals of this lab are to:
Partition the DRM code into software on the ARM and
external hardware accelerators.
Prototype the target platform in a SystemC TLM2.0 environment.
The assignment of
this lab includes the following:
Isolate the Viterbi decoder and convert it into a SystemC hardware module.
Develop a hardware abstraction layer (HAL) for
access to the external Viterbi hardware from the ARM.
Cross-compile the DRM application to run under
Linux on the ARM board.
Simulate the DRM application running on a virtual
platform model to validate the HW/SW implementation.
the Viterbi Decoder
Here are some guidelines as to generating a standalone Viterbi decoder
module in SystemC:
- Make sure to
start from a Viterbi decoder that has already been converted into a
fixed-point version. You can start with the code you developed in Lab 1.
Alternatively, a reference solution for Lab 1 is available as an updated
- Most of the
files you might have to work on reside in the common/mlc directory:
Implementation of the Viterbi decoder
- MLC.cpp/.h: The place
where the Viterbi is called
- The following
two parts should be isolated and merged into a single function:
- You will need
to define the following variables as your function arguments:
- data_in: Encoded
bit stream passing into the Viterbi decoder
- data_out: Decoded
bit stream coming from the Viterbi decoder
- punc: Puncturing
patterns (see note below)
- dataout_size: Size of data_out
required parameters as you proceed with the isolation.
- Turn the
function into a SystemC process and wrap it in a
SystemC module. Insert wait()
statements with estimated delays into the Viterbi decoder process.
- The module
will have to communicate and synchronize with the ARM to exchange input
and output parameters. Using the Adder example in the QEMU/SystemC tutorial of lab 1 as a reference, choose
the communication parameters and implement a corresponding TLM2.0 slave
- Integrate the
SystemC model of the Viterbi accelerator into
the virtual QEMU/SystemC platform.
Note: The punctured coding technique has not been introduced in class.
The basic idea of the punctured code is basically to increase the coding rate.
Please refer to the bottom of this link for
To setup a
simulation of the DRM application running on the virtual prototype of our target
platform, the following steps need to be performed:
- Using the
application example in the tutorial as a reference, develop a hardware
abstraction layer (HAL) that can serve as a stub for the Viterbi
functionality. The HAL should be a drop-in substitute for the existing CViterbiDecoder class, i.e.
it replaces the ViterbiDecoder.cpp file with an implementation that makes
equivalent calls to the external hardware instead. Make any necessary
modifications to the fpga_drv if you need to.
- Integrate your HAL into the DRM application, compile
the 'drm' executable, add it to the simulated
platform and run the complete setup in the emulated ARM+FPGA environment.
Verify that the hardware/software interaction is working properly and that the
correct DRM output is produced.
credit) Parallelize the processing chain to exploit any available
concurrency between the Viterbi running in hardware and the rest of the
software running on the CPU. Refer to the instructions in Lab 1 about
general parallelization hints and strategies. Note that this may require
you to turn the software side into a multi-threaded application, such that
a larger part of the processing chain containing the Viterbi runs in
parallel with other parts of the DRM receiver.
Submit your report
and files to Canvas.
The report should summarize your work flow, describe your simulation setup,
document the model and application code modifications, and analyze your
simulation results. Attach an archive (.tar.gz or .zip) that includes:
The QEMU/SystemC platform
model, including sources.
Source code for the Viterbi SystemC
Source code for the HAL and driver code.
A README file that describes how to compile and run
your platform simulation.