Final Report (Message from Onur)

Dear 740 students,

  • Deadline: As you know, the project reports are due December 18, 11:59pm Eastern Time. There are *no extensions* to this deadline, as we will need to turn in the grades soon afterward.

Basically, write your report as if you are writing a submission to a top conference. You need to motivate the problem, describe its importance, describe related work and its shortcomings, explain the key ideas of your solution, and describe it in detail in a precise manner so that the reader (i.e., we) can understand what you are exactly doing. You should describe your experimental methodology to evaluate your solution and provide an analysis of your results.

  • Sections: It is very important that your report have all the sections that comprise a good computer architecture paper:
    • Abstract
    • Introduction (Problem and Motivation)
    • Related Work and its Shortcomings
    • Description of the Techniques (designed and evaluated)
    • Evaluation Methodology
    • Results and Analyses
    • Conclusion/Summary
    • References

Please incorporate all feedback you received during the poster session when preparing your report and make your reports as strong and as clear as possible.

  • Page limit and format: I am increasing the page limit to 12 pages double-column, single space, including references. You can add an appendix that can be as long as you wish, if you wish to provide supporting data, proofs, explanations, etc. Please use the Latex template (along with instructions) provided on the 740 project website at http://www.ece.cmu.edu/~ece740/f11/doku.php?id=wiki:project

You have read many seminal and recent research papers during the course of the semester on a very wide variety of research topics, and by now are familiar with the level of clarity, preciseness, insight, and strength of evaluation that makes a paper a good research paper. I expect your reports will reflect similar quality.

Looking forward to your clear and insightful reports.

Onur

Final Report

  • Please use latex
    • If you are not already doing so, please try to use latex to typeset your final project report.
    • It's like all other Unix tools: the learning curve is a little steep in the beginning, but once you get rolling, life becomes so much easier.
    • Another advantage: citing related work and organizing your bibliography.
  • Report Format
    • Must be in pdf
    • Single-spaced, 10pt, 2-column
  • Latex Template: Download
    • Files
      • Makefile
      • template.tex: equivalent to “main.h”
      • paper.tex: equivalent to “main.c”
      • abstract.tex: placeholder empty file
      • introduction.tex: placeholder empty file
      • sample.tex: has working examples of lists, tables, figures, algorithms, and etc.
      • ref.bib: has a minimal bibliography (you can get more citations from papers hosted on ACM and IEEE by looking for a link called “BibTex”).
    • Troubleshooting
      • If the latex template doesn't compile using the simple “make” command, it might be due to missing Latex “packages”, which are similar to “headers” in C files.
      • In that case, you need to do a complete Latex installation (for aptitude package manager based systems it would be “sudo apt-get install texlive-full”) or remove references to those packages in “template.tex” and corresponding examples that use those packages in “sample.tex”.
  • File name
    • When assigning a file name to your final report, please include the last names of your group members. For example, “meza_kim.pdf”.
  • Paper size
    • Please check that the paper size of your final report is “letter” (8.5” x 11”). You can check this by opening your pdf file using your favorite pdf viewer, and opening the “properties” menu to find the paper size.
  • Vector-graphics
    • Latex plays nicely with vector-based graphics (for figures or graphs). If you want to include graphics you generated using Windows-based tools, you'll have to either i) convert them to jpeg/gif/png (which would introduce visual artifacts, more so since you have to shrink/enlarge them), or ii) convert them to eps/pdf (which would not introduce visual artifacts). If you have questions on the latter, we can help.

Poster Session

Milestone III Meetings

Tuesday, December 6

1:00 pm

  • Brian Pak and Lincoln Roop

1:20 pm

  • Hongyi Xin and Donghyuk Lee

1:40 pm

  • Joe Berman & Abeer Agrawal

2:00 pm

  • Timothy Zhu and Huapeng Zhou

Thursday, December 8

1:00 pm

  • Filipe Militao, Ligia Nistor, Bernardo Toninho

1:20 pm

  • Abhijeeth Nuthan, Siva Penke, Edward Ma

1:40 pm

  • Ben Jaiyen, Jamie Liu & Richard Veras

2:00 pm

  • Padmanabham Patki, Yifei Yao, Paul Kennedy

Milestone II Meetings

Tuesday, November 22

1:00 pm

Abeer Agrawal, Joe Berman

1:15 pm

  • Hongyi & Donghyuk

1:30 pm

  • GROUP NAMES HERE

1:45 pm

  • Edward Ma, Abhijeeth Nuthan, Siva Penke

2:00 pm

  • Brian Pak, Lincoln Roop

2:15 pm

  • Bernardo Toninho, Ligia Nistor, Filipe Militão

2:30 pm

  • Padmanabham Patki, Paul Kennedy, Yifei Yao

2:45 pm

  • Jamie Liu, Richard Veras, Ben Jaiyen

3:00 pm

  • Timothy Zhu and Huapeng Zhou

Project Groups

  • Group 0: Brian Pak, Lincoln Roop, !!!LOOKING FOR THIRD MEMBER!!!
    • Topic: Exploiting Non-Volatile Memory
    • Background/Problem:
      • Non-volatile memories, such as phase-change RAM (PCRAM), are emerging recently to replace both the hard disk drives and DRAMs for more scalability. These memories are much more physically stable and faster; so everything seems good. However, they suffer from write endurance problem – a.k.a. wear-out problem. In order to prevent a single cell or a line in the memory to be worn out faster than others, there have been many research on wear-leveling algorithms. Then, attackers followed along as well. Some researches showed that it is possible to exploit the current implementations of wear-leveling algorithms, which work well with typical applications, but when targeted for an attack, become vulnerable. Thus, there have been few researches on how to mitigate these attacks by introducing detection mechanisms, better leveling algorithms, and so on.
    • Direction:
      • The general belief is that the proposed solutions and mitigations are not enough. What are the things that these researches have missed? What are the limitations? How do we attack/exploit those limits? Can we come up with better algorithms – faster, simpler?
      • Is the exploitation of wear-leveling algorithms the only way to attack these memories?
        1. Can we make an application that will cause a starvation of the resource (read/write) of memory for other applications running together?
        2. What does it do when the power goes off suddenly? How can we leverage this to attack the memory? How do you protect it?
    • Related Papers:
      1. Practical and Secure PCM Systems via Online Attack Detection (https://researcher.ibm.com/researcher/files/us-moinqureshi/papers-hpca11.pdf)
      2. FREE-p: Protecting Non-Volatile Memory against both Hard and Soft Errors (http://lph.ece.utexas.edu/merez/uploads/MattanErez/freep_hpca11.pdf)
      3. Enhancing Lifetime and Security of Phase Change Memories via Start-Gap Wear Leveling (http://dl.acm.org/citation.cfm?id=1669117)
  • Group 1: StudentName0, StudentName1
    • Topic: Building the most secure computer ever
    • Short summary:

Project Statement

The project statement can be viewed here.


Personal Tools