lunduniversity.lu.se

Computer Science

Faculty of Engineering, LTH

Denna sida på svenska This page in English

Guidelines

These sections are meant to help you choosing the project, writting the proposal and the report, making a good presentation, and as well making suggestion in organizing and conduction your work.

Project Suggestions

You should choose your project taking into consideration a few things. First, your project should not focus exclusively on software - this is not a software design course. Neither should it focus only on hardware solutions. Also, pick a project that allows you to explore different architectures - you will gain more by examining different solutions of a rather simple problem than solving a large problem in a unique way. The most likely configuration you will end up with is a microprocessor (MicroBlaze) centered system with a few peripherals around, including your own hardware IP core written in VHDL/Verilog/Bluespec System Verilog. You are required to have both a software and a hardware design part in your project. Third, don't be scared of a bit of VHDL/Verilog (we'll help you if you need help) - design your own cores based on the wrapper provided in Xilinx EDK. The example design that is available for the Digilent Nexys-2 does include a VGA controller, a PS2 controller and a mouse controller, but they must be adapted to the PLB bus that is the backbone of your MicroBlaze system. Fully custom designs of the VGA (or any other) controller are most welcome. The peripheral modules (speaker, temperature, LCD) may require fully custom cores designed by yourself. You will need to decide how to interface them with the MicroBlaze. 

A few project suggestions are listed in the following. Depending on your interest and plans for the future, choose a project that helps you achieve your goals rather than something easy.

A few more challenging and research oriented projects (discuss them more with me if you are interested):

  • Genetic Algorithms Acceleration. Usually GA are computationally intensive, requiring many evaluations of often expensive "fitness" functions. Depending on the problem, implementing such functions and even genetic operators in FPGA will lead to impressive speedups. Applications benefiting are, for instance, tuning stock trading strategies, code optimization/rewrites or expression rewrites.
  • Design and Evaluation of a Vector Unit for Microblaze. This will require extending the Microblaze processor with a vector processing unit, able to speed up operations on vectors and matrices. An evaluation and comparison to the initial processor is also required.
  • Fault-tolerance in a Microblaze system. In hostile environments transient faults may lead to execution errors, so systems need to be fault-tolerant. Error detection and error correction techniques you could look at are, for instance, checkpointing (using interrupts with Microblaze), dual modular redundancy or triple modular redundancy with voting.

A few more development oriented projects are:

  • A Simple Video Game: ``TV'' Ping-Pong, Space Invaders, Tetris,... Essential parts in this project are:
    • a processor (MicroBlaze)
    • a (custom) VGA controller (some might not even need a memory - ping-pong, others might need more complex DMA based approaches to handle the resolution)
    • a PS/2 keyboard/mouse controller (or any other user input)
    • using a sound/microphone would be a nice addition
  • Sound Processor: Using the microphone and the amplifier modules you might choose to do some interesting sound processing (echo, voice altering, etc.) Include a frequency visualizer on the VGA controller and you got a project.
  • TCP/IP-based Client for a Surveilance System: Those of you who took the RT-project course know what this project is about - Basically displaying JPEGs arriving through a socket. A rather good VGA controller is required here. User input can be done using the push-buttons on the board. This would require some more work, as the NET1 boards cannot be directly connected to the Nexys-2 boards - custom cabling is required.
  • Video Terminal: Implement a VT100 and other terminals using the RS232 port, a VGA display, and keyboard. Configuration selectable using on-board dip-switches. A text based VGA controller using character maps would be a good choice here.

We also encourage projects that involve more than one group in them, such as:

  • Head-to-head games: Each group works on its own solution (AI, graphics) for a simple game (5-in-line or other board games, Space Invaders, Pacman), but only implements one (not all) of the opponents. The boards will then need to communicate their moves or decisions between them (using RS232, SPI, RF or any other way) and together make up the fully functional game demo. (e.g. group 1 implements the "o" player while group 2 implements the "x" player, which then will compete against each other. Or, group 1 implements "Pacman" group 2 implements a few "phantoms" that try to catch Pacman, group 3 implements the maze, the display and coordinates the game,...)
  • Multi-board gizmos: For example, an RF "video cable" or a multi-input video signal switch or mixer. Group 1 implements the video input (might need AD converters) and the RF transmitter, while group 2 implements the RF receiver and VGA output.

Of course, if you have other ideas that you would like to put in practice, you are welcome to come up with a totally new project specification. You may also find an interesting project on the net, for instance:

Finally, if you still have difficulties in defining your project, discuss it with us.

Writing the Project Proposal

 

Once you defined your project, it's time to specify it in as many details as possible. It's better to think most of the things through now. Although you will be able to do slight changes, considering you are not familiar with the possibilities of the working platform, these should be rather small. Don't rush into over-specifying a ``video game'' and end up implementing an ``ethernet switch''...

First give a brief description of the functionality, without many implementation details.

Continue with identifying the I/O processes - usually seen as user interaction points. Once you decided what you will use (i.e. a VGA display), go into more details specifying the data exchange at that interaction point (i.e. actual resolution, frequency, virtual resolution). Decide how often / what data / in which direction the data should pass at that interaction point (say 60Hz for the VGA frames, interrupt based keyboard reading, etc). In the implementation you will use either a hardware IP or a software process to handle these exchanges.

Try to identify the type and amount of memory you will need. It's quite comfy to work with BRAMs only, forgetting about the SD or Flash memory. But the on-chip memory may be too small for your processing requirements (especially if you decide to have a high resolution video memory). Depending on the type of memory, the access time varies. Since the speed of accessing data is important in many cases, think of alternatives that can speed it up (cache, lower resolution, hardware vs. software). Be aware that the fastest memories are the BRAM and the distributed RAM. Since you will most likely use a MicroBlaze, find out in the documentation how many cycles it takes to read data from these on your PLB bus or any other interconnection you use. The exact figures for all these are not very important - yet be prepared, and present an alternative in case you do not have the desired data throughput available.

Think of possible improvements, different methods of implementing the system - number of processors, memory architecture and communication structure. Which are the parts that you think will require most computational power to perform? Alternatively, how much can you simplify your system without affecting performance?

Finally, it is essential to write down a time plan. Split your project into phases (not necessarily equally large), decide how much work you should do in each. Do not forget to include the work needed for the presentation and writing the final report. Split the work among the group members.

Note: Please send your proposals (~3 A4 pages) to edan85 either in .tex, .pdf, or .ps (no Word docs), using your student IDs in the subject.

Working on the Project

to be completed

Writing the Final Report

The report should contain a general description of your project, details on the hardware and/or software you had to design yourselves, and conclusions, including lessons learned, possible improvements or better alternative implementations that you could have chosen. The language of preference is English, so that all the participants in the course can read your report if interested. In particular, the report should have the following components:

  • Title page with the project title, date, your names and email addresses.
  • Abstract page, briefly describing your project and some conclusions.
  • Contents with chapter and section pages (number your pages, chapters, sections).
  • Introduction describing the project, briefly showing a hardware architecture overview and software solution. Mention how and why this differs from the initial proposal.
  • The intro should contain (at least) a figure showing your hardware architecture, emphasizing the components you had to implement/modify as opposed to those you instantiate from XPS.
  • Details on your hardware solutions (VGA controller, 7-seg cores, ...) with figures (RTL or block schematics). Please do mention the device occupancy for your hardware architecture, and/or particular cores.
  • Details on your software solution, operating system if any, threads, processes, interrupt routines, etc. Do not forget to mention the memory size requirements.
  • Brief installation and user manual. If anyone would have access to your project and a board, how would one get it running and use it.
  • Problems you encountered during your work on the project and how you solved them or got around them. Mention things that you would do differently if you could start over.
  • Lessons learned and other interesting insights that you got from working on this project.
  • Do write a Contributions section where you give credit to each group member correspondingly according to their contributions to the project (This IP by A and B, this software component by C, testing by D, section 2 in the report by A). In the lessons, solutions and suggestions do identify sources (which of your group members) put forward that particular idea.
  • Eye candy and extras: screen shots, diagrams, schematics, address the project can be downloaded from,...

We will read your reports and probably suggest some corrections or improvements for the second version of the report. The second version of the report and packed project files (after you cleaned the hardware and software) would need to be available for publication online, on the course home page or website of your choice.

Good luck! For any clarifications please contact me.

Note: Please send your reports either in .tex, .pdf, or .ps (no Word docs) and your cleaned packed (.zip) project to edan85.

Making the Presentation

 

The project presentation should be a summary of the final report. Emphasize the custom parts, the problems you encountered, your solutions to these and lessons learned.

Essential points:

  • Expect to talk for 15 minutes + 5 minutes questions/answers
  • Choose at most two people from the group who would actually talk
  • Have an intro slide with your project name, group member names and contact info
  • Present an overview of the hardware/software architecture
  • Present problems, solutions, lessons, conclusions

Expect no demo to take place during the presentation - this will happen during the last labs day.

Note: Please send your presentations either in .pdf or Open Office format to edan85. Alternatively bring your presentation on a memory stick or on your own laptop.

Grading

You will grade the presentation (33% grade) and the demo (33% grade) for your classmates. We will read and grade the reports (33% grade). (1% remains to be given by providence)

For this to happen, please show up for your colleagues presentation and demo! For the presentation you will have to grade the presentation style and the technical content. For the demo you will have to grade the realization, complexity and usability. You will be distributed forms you just need to check boxes in, on the presentation day.

NOTE: The decision of who passes is still ours, the course leaders'.