In this thesis, we designed a 2-way out-of-order processor in Bluespec implementing the MIPS I integer ISA. A number of scheduling optimizations were then used to bring the initial design up to the same level of cycle-level concurrency as found in standard RTL-level designs. From this, a general design methodology is proposed to effectively express, debug, and optimize large Bluespec designs.

We describe an effort to prototype an Itanium microarchitecture using an FPGA. The microarchitecture model is written in the Bluespec hardware description language (HDL) and supports a subset of the Itanium instruction set architecture. The microarchitecture model includes details such as multi-bundle instruction fetch, decode and issue; parallel pipelined execution units with scoreboarding and predicated bypassing; and multiple levels of cache hierarchies. The microarchitecture model is synthesized and prototyped on a special FPGA card that allows the processor model to interface directly to the memory bus of a host PC. This is an effort toward developing a flexible microprocessor prototyping framework for rapid design exploration.

Abstract — Arguably, one of the biggest deterrants for software developers who might otherwise choose to write parallel code is that parallelism makes their lives more complicated. Perhaps the most basic problem inherent in the coordination of concurrent tasks is the enforcing of atomicity so that the partial results of one task do not inadvertently corrupt another task. Atomicity is typically enforced through locking protocols, but these protocols can introduce other complications, such as deadlock, unless restrictive methodologies in their use are adopted. We have recently begun a research project focusing on transactional memory [18] as an alternative mechanism for enforcing atomicity, since it allows the user to avoid many of the complications inherent in locking protocols. Rather than viewing transactions as infrequent occurrences in a program, as has generally been done in the past, we have adopted the point of view that all user code should execute in the context of some transaction. To make this viewpoint viable requires the development of two key technologies: effective hardware support for scalable transactional memory, and linguistic and compiler support. This paper describes our preliminary research results on making “transactions everywhere ” a practical reality. I.