CS812: High Level Design and Modeling, Semester II, 2001-02

SystemC Exercises


General Guidelines

You can do projects in a group of maximum size two students. For system level modeling exercises:
  • Write architecture independent specifications.
  • Take some architectural decisions (in particular, do hardware - software partitioning and decide the interface between the two)
  • Refine the specifications to reflect these architectural decisions

Submitting project choices: 1.3.2002
Submission of detailed report for proposed work: 11.3.2002
Final submission of models and report: 31.3.2002

Application Modeling

  1. Turbo Encoding/Decoder modeling in SystemC:
    Turbo Codes were presented in 1993 and are going to be the defacto standard in the third generation wireless system. The basic design of the Turbo coding system consists of a transmitter (Turbo Encoder), a receiver (Turbo Decoder), and a channel model. The turbo encoder receives the input message (frame) and sends the encoded message to the channel. The channel adds noise to the message and this noisy observed data is the input to the Turbo decoder. The Turbo decoder receives the noisy data and analyses the frame to retrieve the message sent from the transmitter (Turbo encoder). The exercise is to use SystemC modeling for:

    1. Implement the turbo encoder model and test for the functionality.
    2. Implement the turbo decoder model and test for the transmitted message and the received message.

    Note: Turbo encoding and decoding mathematical model along with the channel model will be provided.


Implementing a System Simulator

The goal is to have a system simulator with a few variable parameters. Each group is expected to do a small part. Each of the projects listed below consitute a part of this system simulator. The models should be developed keeping integration in mind. The ALU is expected to operate on symbolic instructions and not binary data. You can download a PS file of the architecture here. With all the following five assignments you will find a few topics under What needs to be decided?. You should try to answer these questions in the detailed report for proposed work which is to be submitted.

  1. Cycle accurate simulator for a simplified RISC-Core:
    • Allows to vary pipeline depth
    • Allows to plug in another FU
    • Allows interfacing with a Co-Processor (basically special instructions)
    • Understands interaction with memory hierarchy and has capability to stall.
    • Capability to handle exceptions (interrupts).
    • Decode unit directly bypasses FPU type instructions to FPU (if present).

    What needs to be decided?
    • RISC Instruction Set Architecture, Register file structure, FUs and interconnects. You can look up MIPS site, http://www.mips.com for the specifications of the R2000 MIPS processor. This should give you some idea about the ISA. The Instructions are supposed to operate on symbolic data and not binary.
    • Cache/memory access modes. These would need to be decided along with the group who is trying to model cache.
    • Co-Proc interface instructions. These again you can get from the MIPS site.
  2. Cache hierarchy simulator:
    • Allows to vary usual cache parameters like associativity etc (direct mapped to fully associative).
    • Allows to separate I and D caches.
    • Allows to grow the cache hierarchy.
    • Should understand the different internal bus protocols.

    What needs to be decided?
    • Interface with the RISC core. This needs to be decided in consultation with the group who is implementing RISC core.
    • Exact set of variable cache parameters. You have to atleast implement the following:

      1. Write-Back and Write-Through cache.
      2. Buffered or unbuffered writes. The depth of the buffer itself is variable.

    • Interface with the local bus. This again needs to be decided in consultation with the groups who are modeling memory controller and internal bus.
  3. Physical memory simulator, DMA and External Bus Arbiter:
    • Allows unlimited simultaneous writes to buses
    • Supports different modes for arbitration (Round-robin, priority based etc.).
    • Support for different communication modes in memory (Ref: Panda's book).
    • Different types of memory banking etc.

    What needs to be decided?
    • The exact interface signals for arbiter and memory.
    • Exact set of memory interconnects. For this I suggest that you look at some freely available memory models. Some can be downloaded from the url, http://tech-www.informatik.uni-hamburg.de/vhdl/models/sram/sram.html. This is just for looking at the interfacing part.
    • Address space and word sizes. These should ofcourse be parameterized (variable).
  4. Floating Point Unit:
    • Rich set of FPU operations (compliant to some standard).
    • Can generate exceptions (and interrupt processor).

    What needs to be decided?
  5. Memory controller and CPU internal bus:
    • Suitable set of variable parameters for Memory controller which are possible.
    • One or two different protocols for the bus.

    What needs to be decided?
    • Exact interface with the memory and cache. This needs to be decided in consultation with the appropriate groups.
    • Your memory controller should understand the different modes supported by the memory.


Modeling a Complete System

  1. Telephone with in-built Directory:
    Today major metro directories are available in CD form. It may be useful to build a standalone telephone with a CD drive. The telephone should support special functions to search for numbers, store in a separate area and dial.
    Specifications should include:
    • Functions required
    • Memories required (area where often used numbers can be stored)
    • Interface with the CD drive
    • Dialing functinalities
    • Display interface (4 or 6 line LCD display)
  2. A Novel Software Security Device:
    At one time hardware locks were used for protecting software. These have more or less been discarded due to a variety of reasons. But a lock based on FPGA which is enabled in an online mode (that is when you are logged on to a site - the keys are atutomatically configured) can provide for very interesting ways for protecting software. It can also provide for security in applications like e-stamping etc.
    Specifications should include:
    • Key encryption mechanism
    • Interface with the PC
    • Perhaps encryption required

  3. DAISY books play back machine:
    DAISY is a format of recording audio files which are saved in wave or mp3 formats. Appart from the audio files a book contains indexing files which follow xml code. There are standard codes and formats of files and the DAISY consortium makes them available to developers of equipment for these books.
  4. Intelligent Electric Power Metering System:
    For information about this project click here.
  5. Bus Station Display:
    For information about this project click here.

Last Updated April 26, 2002 by Anup Gangwar