Suggested 244 Project Topics for Fall 2005: Mentor: Sanjit Seshia (sseshia@eecs) (The topics below are described quite broadly. If you're interested in these topics or anything related, come and discuss with me to further define the scope of your project.) -------------------------------------------------------------------------- 1. Hardware Security ------------------ CONTEXT: Smartcards and embedded devices can be susceptible to physical attacks that compromise security. For instance, for a device that performs encryption with an embedded secret key, it is possible to reduce the search space for discovering the key by observing power consumption, or timing behavior. Solutions to the above problems have been suggested using both traditional synchronous design methodologies as well as asynchronous (clock-less) solutions. PROBLEM: Pick a class of physical attacks (say, differential power analysis). Compare different async and sync design methodologies with respect to their robustness to attacks. Identify limitations and suggest alternative strategies. Where would one need software-based solutions? Is there a niche for async design? -------------------------------------------------------------------------- 2. Bit-vector Decision Procedures ------------------------------ CONTEXT: A variety of verification problems, whether in embedded/systems software, or at the RTL level, or in microcode, ultimately require reasoning about word-level (finite-precision bit-vector) operations. In particular, one needs to find whether a given Boolean expression over bit-vectors is satisfiable, i.e., we need a decision procedure for bit-vector arithmetic. This is an NP-hard problem. While one always has the option of translating such a problem into Boolean satisfiability by expanding all bit-vectors into as many bits as the word-size, this does not work well in practice. The main difficulty arises with non-linear operators, such as multiplication, division, mod, etc. PROBLEM: Come up with a bit-vector decision procedure that handles some subset of non-linear arithmetic operations and improves over the state of the art. IDEAS: One doesn't always need to reason at the word-size. For example, many computations are narrow bit-width, so this problem structure could be detected and exploited. Another idea is to use "iterative refinement": start with a small bit-vector size and increase it "on demand." -------------------------------------------------------------------------- 3. Automatic Abstraction of Verilog Models --------------------------------------- CONTEXT: Formal verification (FV) always involves an abstraction step, wherein the system to be verified (as described by Verilog code, e.g.) is "simplified" into a model suitable for reasoning about with mathematical logic. At present, this is usually done manually and limits the applicability of FV. A good abstraction technique can have a big impact. PROBLEM: Come up with an automatic technique to abstract Verilog code into a higher level "extended state machine" model that the UCLID verification system can accept. The key point would be to see how functional blocks and data can be selectively abstracted while retaining enough bit-level information. One could also ask the question: Can one re-write the Verilog in a way that makes it easier to abstract and verify? This could lead to interesting questions about designing a hardware description language *for verification*. BACKGROUND: See the UCLID homepage (www.cs.cmu.edu/~uclid) and also the recent DAC'04 paper by Andraus and Sakallah.