System-on-a-Chip (SoC) Design

EE382V, Fall 2014

Lab #2

Due: 11:59pm, Oct 13, 2012

 

Instructions:

•     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.

 

1       Overview

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.

 

2       Isolating the Viterbi Decoder

Here are some guidelines as to generating a standalone Viterbi decoder module in SystemC:

  1. 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 archive drm-1.2.4-fxp.tar.gz.
  2. Most of the files you might have to work on reside in the common/mlc directory:
    1. ViterbiDecoder.cpp/.h: Implementation of the Viterbi decoder
    2. MLC.cpp/.h: The place where the Viterbi is called
    3. FXP.h
  3. The following two parts should be isolated and merged into a single function:
    1. CViterbiDecoder::Decode
    2. CViterbiDecoder::Init
  4. You will need to define the following variables as your function arguments:
    1. data_in: Encoded bit stream passing into the Viterbi decoder
    2. data_out: Decoded bit stream coming from the Viterbi decoder
    3. punc: Puncturing patterns (see note below)
    4. dataout_size: Size of data_out

Define any required parameters as you proceed with the isolation.

  1. 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.
  2. 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 interface.
  3. 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 more information.

 

3       DRM Application Mapping

To setup a simulation of the DRM application running on the virtual prototype of our target platform, the following steps need to be performed:

  1. 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.
  2. 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.

  3. (Extra 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.

 

4       Lab Report Submission

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 module.

•     Source code for the HAL and driver code.

•     A README file that describes how to compile and run your platform simulation.