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
Dead-Lines:
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
- 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:
- Implement the turbo encoder model and test for the functionality.
- 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.
- 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.
- 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:
- Write-Back and Write-Through cache.
- 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.
- 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).
- Floating Point Unit:
- Rich set of FPU operations (compliant to some standard).
- Can
generate exceptions (and interrupt processor).
What needs to be decided?
- 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
- 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)
- 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
- 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.
- Intelligent Electric Power Metering System:
For information about this project click here.
- Bus Station Display:
For information about this project click here.
|