Informing the broad computing community about current activities, advances and future directions in computer architecture. Subscribe to Get Automatic Updates
    |
Current ArticlesThis feed's current articles are shown below. Subscribe for updates to all the content available in this feed, or click through here to see the original article. Emerging cryptocurrencies, such as Bitcoin and Ethereum have reached market capitalizations in the billions of U.S. dollars and transactions volumes in the hundreds of millions of U.S. dollars per day according to coinmarketcap.com. The underlying technology of blockchains to achieve distributed consensus has been touted as a solution to many challenges in decentralized systems. A key feature of a blockchain is the presence of miners that validate and timestamp transactions. Miners achieve this by solving computationally complex challenges. Even before the recent popularity of blockchains, proof-of-work protocols have used a similar principle, requiring computation to solve a challenge, to achieve a fundamental level of trust.
In this post, I argue that building systems that require large amounts of brute-force processing for normal operation (i.e., to support benign users performing valid transactions) is not only a terrible waste of resources; it is equivalent to computer programmers and engineers waiving the proverbial white flag and surrendering any elegance in system and protocol design to a crude solution of last resort.
Attacks in distributed systems
In the absence of perfect security, the traditional approach to security has been to make the cost of a successful attack high enough to ensure that an attacker sees little benefit in pursuing the gain obtained from conducting the attack. For example, standard cryptographic operations can be performed with comparably low computational resources if an entity has access to the correct key(s). An attacker that does not have key information, in contrast, needs to conduct brute-force trials of large numbers of key guesses in order to achieve the same effect.
In large-scale distributed systems, such as the Internet, resources can be accessed by anyone without using strong identities and access control. As a result, denial-of-service attacks are a concern in these environments that involve many actors, some of whom cannot be trusted. Interactions in a distributed system typically require a commitment of resource by all entities in the interaction. If there is an imbalance between the cost of initiating the interaction and responding to the interaction, then there is an opportunity for a denial-of-service attack: An attacker can cause the target of its attack to commit a disproportionate amount of resources without committing a comparable amount by itself. As a result, the target can be swamped and not respond to other, benign requests. This problem has been observed in a number of systems, such as web servers (SYN flooding attacks) and electronic mail (spam).
Elegant protection mechanisms
Defenses against such attacks can be developed by improving the protocols that are used between the entities. The overall strategies of these solutions are to reduce the resource commitment in response to the initial request and thus defusing the impact of the denial-of-service attack. For example:
- Access control: Using authentication and access control mechanism, responses can be limited to those of authorized users. The only resource commitment at the time of first contact is that of conduction an access control check for the credentials provided by the sender. The access control verification step is typically significantly simpler than the actual response to the request. If the credentials are invalid, no further action (or resource commitment) is conducted. This technique requires a suitable setup of identities and access control mechanisms. Example: to verify a user, a simple cryptographic verification (e.g., verification of an encrypted nonce) can be used.
- Gradual resource commitment: In this case, resources are not fully committed during the first response by the system. Instead, additional interactions (and valid responses by the sender) are necessary to establish sufficient (temporary) trust to commit the full resource set. This scenario does not require identities or other trust mechanisms since trust is established by properly responding to protocol operation (and thus mutually escalating the resource commitment). Example: SYN cookies can be used to require the initiator of a web request to properly respond before connection state is established.
In these cases, somewhat elegant protocols are used. (I distinguish “elegant” from “brute force” in the sense that domain-specific operations are implemented to avoid the need for brute force.)
Blockchains and proof-of-work protocols
A solution to denial-of-service attacks that has emerged in recent years is a technique called “proof of work.” In proof-of-work protocols, the initiator is required to commit resources in order to show that they are serious about wanting to conduct a transaction. The responder sends a challenge to the initiator and requires the solution to the challenge before continuing the interaction. The challenge is designed to be difficult to solve, but easy to verify. For example, finding an input to a cryptographic hash function with a key provided by the challenger such that the last n bits are zero requires a lot of brute force testing of different inputs (since the one-way hash function is hard to reverse). Once a result is found, verifying the correctness of the result is a simple, single hash calculation. Using such an approach, the initiator of a request is required to commit considerable amounts of resources before the responder does so. Thus, a denial-of-service attack would become significantly more expensive or difficult to conduct for an attacker.
In blockchains, the idea of proof of work has been extended to protect the transaction history in the system. Miners solve computationally complex problems and then lock the current state of the system with the results of these computations. Alterations to the transaction history would require an attacker to outperform the computational power of all legitimate miners to create an alternate history of transactions. This principle of protecting transactions from alterations clearly works.
Impact on environment and society
At first glance, proof-of-work protocols and block chains get the work done. However, there are significant drawbacks to these solutions that are outside the technical scope. It has been reported by numerous outlets, including IEEE Spectrum, that the current blockchain miners consume vast amounts of electrical power. The current consumption of the Bitcoin network, as reported by digiconomist.com, at the time of writing exceeds the total electricity consumption of Ecuador. This level of computation demand has been deemed unsustainable, as described in an article on Motherboard, which shows that a Bitcoin transaction requires approximately 5,000 times the energy of a credit card transaction.
Another aspect of brute-force processing in systems is that it enhances economic imbalances across society. The ability to conduct large amounts of computations is limited to those entities that can afford the capital and operational expenditures necessary for the underlying computing infrastructure. Thus, only wealthy individuals, businesses, and countries can be major players in this environment. This is contrary to the design of other large-scale systems, such as telecommunications and the Internet, which have aimed to make access to information more accessible to everyone – independent of economic status. Considering the wide use of (even low-end) smartphones in all parts of the world, such design goals can actually translate into real achievements.
Where do we go?
Committing huge processing resources makes economic sense for the miners since fees are paid to them for recording transactions in the blockchain. However, in the larger perspective, these operations are a huge waste of resources for the small value that they provide to a system. Recording a transaction with suitable privacy such that its outcome is immutable should not require an energy consumption that is comparable to an entire country’s energy budget!
There is ongoing work to develop new principles for blockchains, such as shifting from proof of work to proof of stake. However, we also need to explore the underlying desire for using blockchain-based systems. The properties provided by blockchains, such as immutable consensus, can easily be achieved by (physically or logically) centralized systems. However, the concern about control of a centralized system is deeply rooted in some communities. What is the right tradeoff between anonymity, privacy, distributed control and the danger that we put a huge burden on the environment and society through massive brute-force computation because we mistrust centralized systems?
About the Author: Tilman Wolf is Senior Associate Dean and Professor of Electrical and Computer Engineering at the University of Massachusetts Amherst.
Memory architecture is a key component of modern computer systems. Memory hierarchy importance increases with the advances in microprocessor performance. Traditional memory hierarchy design consists of embedded memory (such as SRAM and embedded DRAM) for on-chip caches, commodity DRAM for main memory, and magnetic hard disk drives (HDDs) or solid state disks (SSD) for storage. Technology scaling of SRAM and DRAM, the common memory technologies used in the traditional memory hierarchy, are increasingly constrained by fundamental technology limits. In particular, the increasing leakage power for SRAM and DRAM and the increasing refresh dynamic power for DRAM have posed challenges to circuit and architecture designers of future memory hierarchy designs.
Memory that never forgets. Emerging memory technologies, such as spin-transfer torque RAM (STT-RAM), phase-change RAM (PCRAM), and resistive RAM (RRAM) are being explored as potential alternatives to existing memories in the future computing systems. Such emerging nonvolatile memory (NVM) technologies combine the speed of SRAM, the density of DRAM, and the nonvolatility of flash memory, as attractive alternatives for the future memory architecture design. After many years’ foundematel research, these NVM technologies are getting mature and could possibly become main stream technologies in the near future. For example, four foundries including GlobalFoundries, Samsung, TSMC and UMC, have planned to start offering spin-transfer torque magnetoresistive RAM (ST-MRAM or STT-MRAM), possibly starting later this year. Two months ago, Everspin has begun sampling its new 1Gb STT-MRAM with lead customers, delivering a high-endurance, persistent memory with a DDR4-compatible interface. Intel and Micron have worked together to develop a NVM technology called 3D XPoint, which became available on the open market a few months ago .
Modeling NVM technologies. To assist architecture-level and system-level design space exploration of NVM-based memory, various modeling tools have been developed during the last several years. For example, NVsim is a circuit-level model for NVM performance, energy, and area estimation, supporting various NVM technologies, including STT-RAM, PCRAM, ReRAM, and legacy NAND Flash. NVmain is an architectural level simulator equipped with NVM support as well as high flexibility to support both DRAM and NVM simulation, including a fine-grained memory bank model, MLC support, more flexible address translation, and interface to allow users to explore new memory system designs.
Architectural Opportunities. As such emerging memory technologies get mature, integrating them into the memory hierarchies provides new opportunities for future memory architecture designs. Specifically, these NVM have several characteristics that make them promising as working memories or as storage memories. One characteristic is that, compared to SRAM and DRAM, these emerging NVMs usually have higher densities, with comparable fast access times. Another characteristic is that, because of nonvolatility, NVMs have zero standby power and are immune to radiation-induced soft errors. A third characteristic is that, compared to NAND-flash SSDs, these NVM are byte addressable. For example, leakage power is dominant in SRAM and DRAM arrays. On the contrary, because of nonvolatility, PCRAM or MRAM arrays consume zero leakage power when idling but consume far more energy during write operations. Hence, the tradeoffs between using different memory technologies at various hierarchy levels should be studied. For example, last year in ISSCC, Toshiba has presented a 65-nm embedded processor prototype that integrated with 512KB STT-RAM cache. The memory circuit offers 3.3-ns memory access, which is fast enough for use as cache memory, and consumes less than 1/10th of the energy that conventional SRAM does. This offers the highest power performance in the world for integrated memory.
Leveraging the nonvolatility in architecture design. The most unique advantage for such emerging memory technologies is the nonvolatility. For example, HP labs has proposed a low-overhead check-pointing device with PCRAM for future exascale computing systems, instead of using HD or SSD. The scalability of future massively parallel processing (MPP) systems is challenged by high failure rates. Current hard disk drive (HDD) checkpointing results in overhead of 25% or more at the petascale. HP’s solution leverage the nonvolatility of Phase-Change Random Access Memory (PCRAM) technology and propose a hybrid local/global checkpointing mechanism after a thorough analysis of MPP systems failure rates and failure sources. The proposed PCRAM-based mechanism can ultimately take checkpoints with overhead less than 4% on a projected exascale system. Another usage of nonvolatility is to design novel persistent memory architecture，as described by another blog “A vision of persistence”.
About the author: Yuan Xie is a professor in the ECE department at UCSB. More information can be found at http://www.ece.ucsb.edu/~yuanxie
 MICRO-50 Summary
 2017-10-23 13:00 UTC by Joe Devietti
The 50th Annual International Symposium on Microarchitecture was held earlier this week in Cambridge, Massachusetts.
Day One
PC Chairs Joel Emer and Daniel Sanchez kicked things off by sharing some data on conference submissions and reviewing. MICRO-50 used a revision-based model similar to MICRO 2015. Memory systems (the most popular topic among MICRO submissions this year) were well-represented in the program, with one session on DRAM and another on persistent memory. The best-paper runner up (discussed more below) also focused on improving the performance of accessing persistent memory.
Accelerators were another popular area, with two sessions on GPUs, and one on other kinds of accelerators. Deep learning was of special focus within the topic of accelerators, with an entire session dedicated to it. A best-paper nominee, the DeftNN paper, also focused on accelerating deep learning by pruning unutilized parts of the deep neural network and moving computation closer to memory. Tuesday’s keynote, from Microsoft’s Doug Burger, also showed how the company is using FPGA hardware at scale to accelerate deep learning. Our community is pursuing many different directions to improve the performance of this important workload, from bit-level to algorithm-level optimizations. It will be interesting to see if research continues to pursue different layers or if a consistent abstraction evolves. The accelerator and memory system trends flowed together in the “In/Near Memory Computing” session, which included a paper on Oracle’s now-cancelled RAPID project, which built near-memory accelerators into the memory controller.
In addition to the expected categories of papers, I was struck by the breadth of topics covered at MICRO this year. In my estimation, it was much broader than typical recent architecture conferences. There were three papers on quantum computing, as our community grapples with the system design issues for this radically different computing fabric. These papers surely would have been their own session were one of them not the best paper award winner (discussed more below). Back in the classical realm, other papers described a mixed-signal accelerator for solving PDEs, architectural trade-offs for processors made from biodegradeable transistors, using perceptron branch predictors for power management in brain-machine interfaces in rats, and a thought-provoking paper using statistics to model the risk that a processor design will fall short of its performance expectations. We’ve come a long way from SimpleScalar.
Keynote: “To a Trillion and Beyond: the Future of the Internet of Things”
Krisztián Flautner, VP of Technology at ARM, gave the opening keynote titled “To a Trillion and Beyond: the Future of the Internet of Things”. His talk discussed the importance of data and the difficulty of obtaining trustworthy systems. The data collected by IoT devices is a valuable resource so companies tend to hoard it, even though society might be better off if they shared. For example, with 1 trillion miles driven needed to achieve reliable autonomous vehicles, it may be difficult or impossible for a single carmaker to accrue sufficient experience. But if experience were shared across carmakers, safe autonomous vehicles could be realized sooner. The second part of the keynote discussed how trust can be achieved via stability, governance and transparency. Humans have an unfortunate tendency to trust based on superficial characteristics such as facial features. For systems like autonomous vehicles that demand high levels of trust, we must strive to achieve this along several dimensions while avoiding human biases.
“Legends of MICRO” panel
After lunch the “Legends of MICRO” panel was held with Tom Conte, Matt Farrens, Gearold Johnson, Yale Patt and Nick Tredennick as panelists and Rich Belgard as moderator. Margaret Martonosi from Princeton respectfully read a statement before the panel began. She raised awareness about the unfortunate bias that has characterized MICRO’s history — no female PC chairs in the past 26 years, just two female keynote speakers in the conference’s 50-year history (Margaret being one of them). As she read the statement, more and more audience members stood up in support of her message, culminating in a standing ovation. A community conversation about how to address these issues was deferred to the MICRO business meeting (see below), which drew record attendance.
The panel itself discussed conference history, such as how MICRO got its logo (it’s a “uA”, for microarchitecture, under the ISCA architecture pyramid) and how it successfully rebooted itself in the late 1980s, upgrading from the “Workshop on Microprogramming” in 1987 to the “Symposium on Microarchitecture” in 1991 (with a stop at “Workshop and Symposium on Microprogramming and Microarchitecture” in 1990, for completeness) that we know today.
Aquarium Panel
In the evening, at the Boston Aquarium, another panel discussion was held with Arvind, Bob Colwell, Phil Emma and Josh Fisher as panelists, and moderator Srini Devadas. Bob Colwell and Josh Fisher shared their experience at MultiFlow Computer, building one of the earliest VLIW processors and a compiler to target it. Their core observations of the amount of ILP available in ostensibly-sequential code would have a powerful impact on processor design, especially embedded systems and DSPs, and would influence Bob’s later work at Intel making out-of-order designs a commercial reality. Asked to share advice for future generations of architects, Phil Emma encouraged moving beyond the limited interface that current instructions adopt, to richer data structures and more sophisticated operations. Arvind noted that it’s important to study the most sophisticated designs (typically general-purpose processors) to deepen one’s skills. These fancy techniques are often applicable in surprising ways, such as using way prediction to save energy even in microcontrollers.
Day Two
Keynote: “Specialization and Accelerated AI at Hyperscale”
Day two began with a keynote from Doug Burger, Distinguished Engineer at Microsoft, on “Specialization and Accelerated AI at Hyperscale”. He described Microsoft’s work using FPGAs to support streaming computation at huge scale within production datacenters. Given the mass and breadth of code running in Microsoft’s Azure public cloud, reconfigurable hardware is a natural choice to support a wide range of use-cases and to allow developers to gradually “harden” (i.e., port software to an FPGA implementation) portions of their applications. Burger shared the history of the Catapult platform, starting with FPGAs added to Bing servers to accelerate web search. Their current design couples an FPGA with a high-speed network card, and allows the FPGA to process all traffic going into and out of a server. With this in-network programmable hardware, it becomes possible to run an entire microservice on FPGAs, wholly decoupling it from conventional servers. This, in turn, has helped enable Microsoft’s Brainwave project for high-performance deep learning. With Brainwave, FPGAs provide key components of deep neural network inference as a hardware microservice, allowing for very low latency. Because of the programmable hardware, optimizations such as reduced-precision data types are very natural to implement. Burger emphasized the importance of system-level design: reconfigurable hardware has led to new datacenter organizations. Many of these innovations have resulted from working in the “cracks between sub-fields”, e.g., between architecture and security, networking or distributed systems.
Awards Ceremony
At the awards ceremony, 6 folks were inducted into the MICRO Hall of Fame; membership requires 8 or more MICRO papers. Bill Dally, Chita Das, Reetuparna Das, Daniel Jiménez, Aamer Jaleel and Yuan Xie were presented plaques for their contributions to MICRO.
Guang Gao from the University of Delaware was presented with the B. Ramakrishna (Bob) Rau Award, “For contributions to compiler techniques and microarchitectures for instruction-level and thread-level parallel computing.” In his speech, he noted the importance of thinking at the intersection of microarchitecture, compilers and the OS. Hardware heterogeneity, e.g., due to machine learning accelerators, makes this work challenging but also full of opportunities.
The MICRO Test-of-Time Award was presented to Mikko Lipasti and John Shen for their paper “Exceeding the Dataflow Limit via Value Prediction” from MICRO-29 in 1996. The authors noted graciously that at the time of their work, 3 other groups were simultaneously investigating value prediction. While the modest performance benefits and power costs of value prediction initially dampened industrial enthusiasm, several industrial teams are currently investigating its potential.
Business Meeting
The second day closed with the MICRO business meeting, where it was revealed that MICRO-51 next year will be in Fukuoka (“foo-coh-kuh”), Japan. The main event, however, was an extended discussion of diversity within the MICRO community. Attendance at the business meeting was extraordinary – standing room only the entire time. The conversation was wide-ranging and covered many topics. I’ll cover a smattering here, but Adrian Sampson has tweeted about many over on @acmsigarch. Attendees discussed term limits for Steering Committee members, cooldowns on PC membership, a new Diversity Chair or Ombudsperson role, the need for more concrete data on gender and ethnicity within the community (the conference organizers estimated the number of female MICRO attendees at 11%, based on the jacket sizes given out), special programming for 1st-time attendees, and the need to track graduating PhDs so they can reliably be considered for PC membership and conference organization roles.
Day Three
Best Paper Session
On day three, the conference ended with the best paper nominees session. It was great to see people sticking around until the end of the conference: attendance was comparable with the keynote talks. The best paper award went to “An Experimental Microarchitecture for a Superconducting Quantum Processor”, by Xiang Fu et al. from Delft University of Technology. Fu presented the first microarchitecture for a quantum computer. The QuMA (for Quantum MicroArchitecture) design bridges the gap between the classical and quantum domains, showing that conventional digital logic can be used to control underlying qubits. The evaluation was particularly impressive: the authors implemented their microarchitecture on an FPGA and used it to run a program on a real 1-bit quantum computer. The best-paper runner-up was “Hardware Supported Persistent Object Address Translation” by Tiancong Wang et al. from NC State. In anticipation of upcoming persistent memory technologies, their work proposes hardware support to translate the ObjectIDs of persistent objects into virtual addresses, as persistent objects can be mapped anywhere within the virtual address space. ObjectIDs effectively form a new kind of address space, and hardware translation support is needed to allow fast access to persistent objects. The other two best-paper nominees were the DeftNN deep learning accelerator (discussed above), and the intriguing DEMIS paper. DEMIS showed that compiler and architectural techniques can have significant impact on the electromagnetic radiation that a processor emits. This radiation in turn can interfere with WiFi or LTE signals and reduce their bandwidth, but a processor can be designed to adapt dynamically to avoid interference.
About the author: Joseph Devietti is an Assistant Professor in the Department of Computer & Information Science at the University of Pennsylvania.
I was proud to work with Margaret and many collaborators over a rollercoaster last few days to help enable the now famous diversity statement at MICRO-50. As a woman, this issue touches my life intimately, and as SIGARCH chair, I strive to use the platform entrusted to me to make change. That is why I worked with Margaret et al. to drum up support for a long overdue public call to action. That is why I changed my plans and flew to Boston on Sunday night just so I could stand with Margaret and our community the next day. And that is why I need all of you who stood for, tweeted, and endorsed the diversity statement this week to stay engaged and work with us to make real change for all.
Our community is represented by four organizations: ACM SIGARCH (co-sponsor of ISCA and ASPLOS), ACM SIGMICRO (co-sponsor of MICRO), IEEE TCCA (sponsor of HPCA and co-sponsor of ISCA), and IEEE TCMicroArch (co-sponsor of MICRO).
SIGARCH does not sponsor the MICRO conference and has no purview on it. But what taints one organization taints us all. We must all work together to establish a common set of documented best practices and programs for the entire computer architecture community.
The SIGARCH executive committee is a working committee that strives to create an environment of openness and inclusivity for all. While outcomes remain imperfect, SIGARCH has long worked towards increasing diversity. We created a pioneering program for travel grants for childcare and supporting people with disabilities about 15 years ago. In 2008, SIGARCH adjusted the eligibility criteria for the Maurice Wilkes award to account for documented family-related or medical leaves from employment. We have been a significant sponsor of CRA-W’s grad cohort workshop. Just in the last two years we have started several new initiatives. We started the Computer Architecture Today blog, which has provided a platform for ongoing diversity discussions. We relaunched Women-In-Computer-Architecture (WICArch), led by Natalie Enright Jerger, as our subcommittee that will continue to keep diversity issues front and center. We started a mentoring program at our flagship conference where senior architects sign up to meet one-on-one with students to convey the welcoming and open environment we seek to foster. Our annual report describes the full range of our activities.
There is much more to be done. We call on our sister organizations to coordinate their efforts with SIGARCH’s efforts. We call on you to make your voices heard and get involved to make change.
Contact me at chair_SIGARCH@acm.org to tell me what concerns you and ask what you can do to help. If you hesitate to contact me, contact a friend but get your voice heard.
About the author: Sarita V. Adve is Richard T. Cheng Professor of Computer Science at the University of Illinois at Urbana-Champaign. She is currently chair of SIGARCH, a member of the executive committee of the ACM SIG Governing Board, and a member of the board of the Computing Research Association. She is (distressed to be) the only woman to have received a major career award in computer architecture (Maurice Wilkes, a mid-career award, in 2008) and the first woman of South Asian origin to be named ACM Fellow (in 2010).
 Several of us reached a “flashpoint” after reading a SIGARCH blog post about gender diversity and then seeing aspects of the MICRO-50 conference program including an all-white-male panel entitled “Legends of MICRO.” We felt we needed to take public, visible action to express our concerns. Through email and social media posts, a core group of collaborators and supporters on these issues took shape: Natalie Enright Jerger and Kim Hazelwood via their blog post, Kathryn McKinley through her email to the MICRO-50 conference chairs and steering committee, Sarita Adve in her purview as SIGARCH Chair (different from SIGMICRO which sponsors the MICRO conference), and myself through two tweets about MICRO that called for ACM and IEEE action.
Over the five days from the initial “flashpoint” to the Legends panel itself, we found our initial sharp reaction honing itself into something more strategic and productive. I wrote 7 iterations of a statement to be read at the beginning of the panel. Each statement responded to feedback we received from a broad cross-section of the community including program and general chairs of current and past MICRO conferences, and many other men and women. As the statement iterated, we gained more and more supporters: male, female, junior, senior. We requested and—eventually—got a 5-minute slot to read our final version of the statement (see below) at the beginning of the Legends panel. The majority of conference attendees signaled their support by standing with us as the statement was read. The SIGMICRO business meeting today will include these issues on its agenda and we hope to make progress.
The teamwork and collaborations that led to this simple but important publicly visible statement of concerns, coupled with the outpouring of support we have received from all factions of our community speak to the intrinsic strength of our community and energize us as we move forward to address these concerns. If you agree with the statement below, we would value your endorsement in the comments section of this post and if you are at Micro, we look forward to seeing you at the business meeting.
Text of the Statement
This statement is the result of a deeply collaborative process over the past few days, and I want to thank the core colleagues who worked with me on it. They are standing here now.
I am Margaret Martonosi from Princeton University. I stand here with respect for the technical ideas and innovation this conference community has generated over the years, and—true to this panel’s topic—a sense of retrospective for the conference’s history.
To introduce myself briefly: I’ve been a publishing member of the MICRO community for nearly 20 years, have two MICRO best paper awards, am in the Micro Hall of Fame, have served on the PC several times, have been general co-chair of the conference, and was introduced last year as the first female keynote in MICRO history, although happily I just learned yesterday that I am actually the second.
But what I say here is not just for myself, but for the researchers who stand with me here today, for the many other researchers who support these ideas, and for the community as a whole.
 Photo by Tim Sherwood I’ll start by stating a basic belief I feel we all share: that the MICRO research community benefits when it can attract and nurture a rich pool of talent. And admittedly like other conferences, MICRO faces challenges due to a lack of diversity in the overall pool of computer scientists, and on the hardware side of the field in particular.
The MICRO conference has its own unique culture though, and that includes being perceived by some to favor so-called insiders. Intertwined with that perception is a concern about the diversity of the conference community along different dimensions: gender, racial and ethnic diversity yes, but also by academic lineage.
Thanks to double-blind reviewing and the care this community places in its review process, we don’t see these issues in paper selection, but they do appear in other technically prestigious conference roles. For example, many attendees were not even born yet when MICRO had its last female Program Chair in 1991.
Why be so public? Why not find a quieter way to work on this? I raised some of these issues 2 years ago with members of the MICRO community including at least one member of the MICRO SC. I provided a list of 48 women’s names at different seniority levels that could be considered for a range of conference roles such as PC chair, PC membership, or keynote. But we have not seen the quiet route result in sufficient, substantive change, and I am concerned that newer researchers in our community may believe there is tacit approval of the status quo. So today, we step to the microphone instead.
The steering committee of a conference should steer the conference into the future. It should reflect and cultivate the values and norms of the community. We believe the steering committee must show leadership in helping the conference move away from the sense that there is an insider’s edge, and towards a stance where researchers can feel they will be welcomed and treated fairly regardless of their gender, their ethnicity, or their academic lineage. Our conferences must acknowledge how a diverse set of viewpoints can lead to the most useful and thought-provoking technical discussions.
These statements are supported by those standing in this auditorium today, and by others who could not be here today, including members of the MICRO Hall-of-Fame, and previous conference chairs. We have concrete ideas for how the incoming steering committee leadership can help bring about substantive change to make MICRO a leader on diversity and inclusion and can consequently benefit technically. I don’t want to derail the panel, so we won’t discuss this here. Rather, we plan on discussing these ideas with that leadership during this conference and time permitting, at tomorrow’s business meeting.
To conclude, MICRO’s next chapter starts here. MICRO’s next chapter starts now. Thank you.
About the author: Margaret Martonosi is the H. T. Adams ’35 Professor of Computer Science at Princeton University, where she also directs the Keller Center for Innovation in Engineering Education. She is currently co-chair of CRA-W, and a former SIGARCH Vice-Chair. With her co-authors, she received the 2015 ISCA Long-Term Influential Paper Award. She is an ACM and IEEE Fellow.
There appears to be a distaste towards attack papers in the architecture and the systems community. Based on talking to a statistically insignificant sample of colleagues, we get the sense that attacks are considered brutish and not constructive. There also appears to some confusion about the how attack work should be evaluated. We have heard more than one respected researcher say things along the following lines: “They found a bug? Is this really computer science/engineering?!”
In this blog post we will discuss the importance of attack research through examples and we will also lay out a framework for thinking about attack research.
Let us begin with the obvious question: Why research and demonstrate attacks? We motivate computer architecture research by referring to technology trends and/or changes in programming models and methods. We motivate defensive work in security by referring to real and anticipated risks. Identification of risks is, thus, a key part of security research. Typically risks are assessed by conducting “attacks”, which, roughly speaking, give us a way to understand the factors influencing risk.
Now some samples of recent attack research. Consider the example of remote car hacks. Published in the early part of this decade, researchers have shown how attackers can, via the cars’ built-in Internet-connected components, take control of core vehicle functionalities such braking or opening the car doors. While the attack vector – exploiting buffer overflow to gain control (“a bug”) – is not entirely novel, the paper highlights a design principle that the car manufacturers have grossly neglected: the cars’ core control circuits should be kept separate from the Internet-connected ones. The work clearly has had significant impact in terms of improving vehicle security architectures as evidenced by cyber security improvements in newer vehicles.
Next let us consider an attack paper of a different kind: one that doesn’t exploit a latent vulnerability but shows how a vulnerability can be created in the first place. In a paper that appeared in IEEE Security and Privacy conference in 2016, researchers showed how to create an analog backdoor on a chip. This attack was demonstrated on a taped out chip, and was a call to action to investigate solutions for this dangerous type of backdoor. These type of attack papers, ones that explore new vulnerabilities are extraordinarily valuable as they allow defenders to understand future attacks, and potentially prevent them from happening by creating appropriate defenses.
Our last example is our recent work, the CLKscrew attack, that we demonstrated in USENIX Security 2017. We showed how the DVFS mechanisms on a commodity chip/architecture can be manipulated to break the root of trust in these devices. We disclosed the attack to the vendors before the publication of the paper and they are currently working towards mitigations for current and future chips. Similarly, in CCS 2015, we showed how microarchitectural side channel attacks can be carried out remotely through a web browser which resulted informing standards and mitigations in several major browsers. Notably this mitigation approach was suggested as potential fix in an earlier ISCA 12 paper. These two examples underscore the importance of attacks to getting defenses implemented and shipped: in both cases the vulnerability impacted millions of devices and users, and mitigations will reach, or have already, reached a very large number of users.
To be clear, just like regular architecture and systems papers, attack research work ranges from trite, to highly original and impactful. The more interesting papers usually score high on some of the factors below.
Novelty: A novel attack paper would expose a new class of vulnerability. Some examples of attacks that expose new classes of vulnerabilities are the exploitation of memory safety vulnerability (specifically buffer overflows) in 1988 for the Morris worm, Differential power analysis attacks on smart cards in the 90s, and the first microarchitectural side channel attacks in 00s. Discovery of a completely new vulnerability classes, or even sub classes, are obviously very rare events.
Requirements: Attacks that require little access and/or low investment (from the point of view of attackers) are likely to be more widespread. For instance, for mass attacks, attacks that can be executed remotely may be considered more desirable than attacks that need local access; similarly, attacks that can be applied quickly and with little preparation are, generally speaking, more desired. Thus, advancement in optimizing attack requirements towards reducing the amount of access, or reducing time are valuable.
Automation: An aspect closely related to access is the ability to automate vulnerability discovery and exploitation. To date, most attacks tend to be manual heroic efforts with little automation (just like computer architecture prototyping). It remains an open question if automatons can discover and deploy attacks: discovery of vulnerabilities and attack engineering requires a level of creativity that may be hard for machines to match.
Impact: Even if the attack does not meet any of the above criteria, if the attack has large scale impact and raises awareness of security issues it could be extraordinarily valuable (e.g., car hacks). On the other hand, if the attack ends up leaking information that is already publicly known, it is, obviously not interesting.
Pedagogy: A valuable security attack can also be a great educational tool to help learn about the nitty gritty engineering details of systems, and in this way it is similar to the benefits of prototyping chips in computer architecture. A good attack paper will have enough details to teach students about the attack and perhaps repeat the attack on different systems.
Ethics: Good attack papers also disclose vulnerabilities responsibly. It is important to give the affected industry vendors or developers some time to address the issue before publishing the attack. Also some (tasteless) attack papers indulge in juvenile chest-thumping; fortunately, this is not pervasive in academic security conferences but it is always good for authors of these works to explicitly ask if statements made in their papers will lead to constructive dialogue and fixes.
The above list is not meant to be comprehensive. Determination of what is really a good attack also have to take into account contextual information such as how does the specific attack compromise full-system security and usability.
We hope you are convinced that making and breaking are equally vital for securing systems and that we would do better if we supported breaking activities in our community.
About the Authors: Simha Sethumadhavan is an associate professor in the Computer Science Department at Columbia University. His research interests are in computer architecture and computer security. Adrian Tang is a PhD candidate in Computer Science at Columbia University. His research explores security as a full-system property by scrutinizing the interplay between hardware and software in the computing stack.
In academia, your teachers/advisor lays out well defined goals: Get an A in the class to prove your knowledge of the material; Publish in top tier conferences or journals to prove your research capabilities. Finish all the required classes and/or publish the requisite number of conference papers and write your thesis, and you will graduate. There are relatively objective standards by which your work is judged, and students understand what is required to succeed in school.
Most graduates with degrees in a technical field will work in industry, even those with PhDs. So what are the metrics by which one is measured in industry? How does one “succeed” and what exactly is success anyway? In this article, I’ll discuss some thoughts on this subject colored by my own experience and knowledge gleaned from twenty plus years in industry.
Grades Aren’t Everything
In the article by Simard and Gilmartin, 1,795 successful senior technical leaders were asked what traits were key attributes for success. The obvious attributes of “analytical ” and “innovator” were at the top of the list. What is more interesting is that the least important attribute of all was “Isolated at keyboard”. Why is this? In school, you were graded on your ability to work independently. If you completed all your work and did it well, you got an ‘A’. In industry, the path to success and recognition is less direct. First, you rarely if ever get to work alone. Most jobs are complex and require teams of people to complete the task. Communication and collaboration are a significant part of the work, and Simard and Gilmartin note “collaboration” as one of the top 5 attributes for success. Second, good work is just the start. The work you do may not get recognized because it is either not critical, not visible, or not differentiated from that of others.
Critical work is generally that which directly impacts products and company profits. I spent most of my career in industrial research groups, and in every performance evaluation my ranking was strongly based on the impact I had on products rather than my publication record. Research is important, but transferring that research to products was the key to success. Visibility is another key aspect for success. You need to shine a spotlight on your work and its relevancy. For some, this means presenting the data/analysis/results to others outside of your local group. For others, it might mean working on projects that are naturally in the spotlight because of management interest. Either way, if you work in a vacuum, you will not be recognized. Finally, you need to be able to differentiate your work from that of others. If you are doing the same work that someone with less skills, education, or experience can do, then there is no value to your higher skill set or experience and your reviews will reflect this. I have seen cases where an employee receiving mediocre reviews in one job suddenly blossoms when given the opportunity to work on a task with higher skill requirements. In the end, your success is a function of good work combined with the right projects and tasks that highlight your abilities.
A Company is Only as Good as Your Manager
The person who has the most influence on your career is your manager. Your manager can guide you towards success or push you towards failure. As a friend of mine noted as he was leaving his company in frustration after many years, “… people join companies and leave managers”. To paraphrase Gallup CEO Jim Clifton, nothing can fix a bad manager… not benefits, salary, friends or company culture.
A good manager clearly defines your goals and objectives, values/understands your contributions, promotes your work, and advocates for you. The first three traits of a good manager are reasonably obvious. The last, advocacy, is less so. Many companies have mentorship programs where the mentor guides you through your career trajectory. A mentor takes a passive role in the relationship, offering guidance when asked or needed. An advocate does what mentors do and more. As noted in the paper “Advocacy Vs. Mentoring“, “[a]dvocates stick their neck out. While a lot of mentoring can be done behind the scenes, [advocates] put their name next to your performance and make their support highly visible.” For me personally, the managers who were technically senior to me have also been my best advocates. Not only did they quickly understand and appreciate the work I did, but they also had the seniority in the company and/or the academic community to push for additional opportunities such as putting my name forward to be on a program committee or reassigned tasks to give me the work that I wanted.
Even the best managers cannot work in isolation without feedback from their employees. As much as I hate writing weekly or bi-weekly reports, I have found them to be a helpful communication tool with my manager. If your manager does not know what you did or what you want to do in the future, then they will be unable to effectively advocate for you when it comes to salary, promotions, or new opportunities.
Networking: It’s Not Who You Know, It’s Who Knows You
Networking is one of the best ways to find interesting opportunities whether that be in the same company or a different one. However, unlike the old adage it’s who you know, the reality is more about who knows you and your work. This once again ties into making sure your work is visible both inside and outside the company. If you are known for good work, the network of people that know you and your work from managers within your company to past co-workers and recruiters will reach out to you when a position is available for your skill set. More often than not, my opportunities have come from people who have approached me about available positions rather than the other way around.
The Biggest Risk is Not Taking One
In her book “Lean In”, Sheryl Sandberg talks about her decision to join Google in its early years. She had many offers whose pros and cons she meticulously charted in a spreadsheet and the Google job did not meet her criteria. She pointed this out to Eric Schmidt, the CEO of Google at the time, who told her “[i]f you’re offered a seat on a rocket ship, don’t ask what seat. Just get on.” Eric Schmidt was referring to Google’s growth potential and impact. The same could be said for other jobs or tasks with significant upside along with significant risk. Being engineers, we try to analyze the costs and benefits of each opportunity. We are fully aware of the costs… more work, steep learning curve, potential for failure, etc. However, we cannot fully assess the benefits of opportunities that are outside of our knowledge base and comfort zone. Sometimes we just have to close our eyes and take a leap. Even if the job or task ends in failure, it still holds benefits because you may have developed new skill sets along the way in addition to growing the network of people who know you and your work.
In the past, I tried to take the ‘safe’ route by sticking to tasks and jobs in my technical comfort zone especially when facing work/life balance issues. In some cases, this was the right decision. However, doing this too often meant that my skill set stagnated and this cost me dearly until I rectified the situation. These days, if an opportunity piques my interest, I first say yes before I think too hard about it and scare myself. Afterwards, I figure out how to make things work, whether it be negotiating with my boss about my current workload or negotiating with my family about household responsibilities. My experience has been that for the right opportunity, you will always figure out a way to make it work.
Life is Short… Have Fun
The famous author and poet Maya Angelou once said, “… making a ‘living’ is not the same as ‘making a life’ “. You spend most of your waking life at work. Regardless of how others define success (higher salary, more responsibility, moving up the technical or management ladder, working for a famous company, etc), if you are not happy, then something needs to change. Research shows that you need five things to be happy at work: 1.) Work that challenges you; 2.) A sense of progress or accomplishment; 3.) No fear (of losing your job); 4.) Autonomy; and 5.) Belonging. If your job is not meeting these requirements, then you will not be happy. Many engineers, me included, have left “better jobs” by all objective standards, from tenured faculty positions to coveted industrial research jobs, to do something different. In the end, each person decides what challenges them and provides a sense of accomplishment and independence. In other words, we all define our own metrics for success.
About the author: Dr. Srilatha (Bobbie) Manne has worked in the computer industry for over two decades in both industrial labs and product teams. She is currently a Principal Hardware Architect at Cavium, working on ARM server processors.
Part One: We’re Just Going to Leave This Here
TL;DR – In part one of our series on gender diversity within the subdiscipline of computer architecture, we present some data that provides signal on where our community stands today with respect to gender diversity.
There was a general air of optimism at the annual Women in Computer Architecture (WICArch) breakfast at ISCA 2017 in Toronto, where the photo below was taken. It was the morning of Day One of ISCA and the WICArch crowd was the largest group in recent history.
 Figure 1: The WICArch Breakfast at ISCA 2017. (Nota Bene: WICArch is relaunching itself with several exciting new initiatives. To subscribe to our mailing list, join SIGARCH or SIGMICRO and specify your gender in your ACM account profile.) That optimism began to fade moments later, however, when we arrived at the Lightning Talks, which are a preview of many of the 50 presentations that would follow over the course of the next three days.
Margaret Martonosi was perhaps the first to point it out. “Two.” She said, and we all knew what she was referring to – the number of female speakers out of the 50+ presentations that would make up the ISCA program.
We know what you’re thinking. Is that correct? Is that typical? What happened? These are excellent questions with, in some cases, measurable answers. So let’s not bother speculating, and instead, dig a little deeper and see what we can find.
And that’s how this all started. We decided to take a look at the numbers to see just how “typical” this low representation of women speakers was across four major computer architecture conferences: ISCA, Micro, HPCA, ASPLOS over the last two years. We also committed then and there to publish our findings as well as various recommendations in a series of blog posts to raise awareness.
The Data
Knowing exactly how many women comprise any dynamic community is a challenge. The community expands and contracts, and the boundaries of the community are ambiguous. These are healthy traits, yet they make the task of quantifying metrics particularly challenging. Gathering metrics such as “percentage of female speakers” is particularly challenging, as this is not documented in any consistent manner. At best, female speakers can only be estimated using other signals, such as first author designations. We did our best to gather various signals that can be used as a proxy to estimate traits about the computer architecture community.
First, we try to gather signal about the community as a whole. This is challenging. The ACM Special Interest Groups provide some signal on the overall computer architecture community, though admittedly, our community spans multiple SIGs, and many members of our community do not belong to any SIG. Nevertheless, the following graph shows the membership breakdown by gender across some of the relevant SIGs that are associated with most of the top computer architecture conferences: SIGARCH, SIGMICRO, SIGPLAN, and SIGOPS. (SIGPLAN and SIGOPS both contribute to ASPLOS.) Overall, we see that 7% (79 members) of SIGARCH identify as female, along with 6% (15 members) of SIGMICRO, 5% (80 members) of SIGPLAN, and 4% (20 members) of SIGOPS. If those numbers seem unsurprising, we’ll point out that between 17-24% of CS undergraduates at R1 institutions identify as female, 13% of CE undergraduates, as well as 17% of those holding technical roles at the large tech companies that release annual diversity reports (We’d love to know more specifically about PhDs working in computer architecture related industrial research labs. If data is available and can be shared publicly, please pass it along to the authors.). So there is either a gap between the general pool and the computer architecture community, or at the very least, a gap in the community and the membership in the various SIGs.
 Figure 2 – Gender breakdown of members of special interest groups. Next, we look at active conference participation in Figure 3. This is an interesting metric both in itself, as well as when broken down by service versus leadership roles. Are women in the community less likely to attend conferences? Are they less likely to serve an active role at those conferences, like speaking, and instead participate only in a service capacity, like program or session chair? Again, a full data set did not exist, so we had to undertake the tedious and manual task of scraping this data using Google searches and emails. The following figures show conference participation in various roles including across the four architecture conferences in the last two years: Program Committee, Session Chair, Author, and Speaker. (Note: Speaker data is estimated based on gender of first author. This may be particularly inaccurate for conferences that require visas for travel, e.g., ISCA in Toronto as many advisors spoke on behalf of their students who were unable to attend.) We followed up with the 4 female first authors for ISCA 2017. Only 2 out of 4 of them presented at ISCA; 2 were unable to travel due to visa issues making the percentage of female speakers at ISCA 2017 less than 4%. A breakdown of conference attendance by gender is difficult to come by; for ISCA 2017, 11% (63 out of 560) early registrants identified as female. For ISCA 2016, 9% (74 out for 789 registrants) identified as female.
 Figure 3 – Active female participation in various roles at computer architecture conferences. One interesting insight that seems consistent across all conferences is that women are much more likely to participate in technical service roles (program committee and session chair) versus traditional technical roles (author and speaker). Furthermore, women are more likely to be provide higher rates of program committee service than men. Diversity is desired on PCs but with a small pool of women to choose from, many women serve on a high number of PCs. This is a common and well-known problem for academic committees. Across the last 8 program committee for ISCA, Micro, HPCA and ASPLOS, there was a total of 420 program committee members of which 346 were male and 74 were female. However, there were fewer unique females in the aggregate list (53% vs 60%) as shown in Figure 4. The maximum service by a member of the community was 5 program committees out of 8.
 Figure 4 – Unique individuals making up program committees by gender. While women generally comprise 20% of program committee members, these numbers do not translate to women serving as program chairs for these conferences, as shown in Figure 5. ASPLOS stands out in this regard with 32% of past program chairs being female. This may be due to the interdisciplinary nature of ASPLOS; however 5 out of the 7 female ASPLOS PC chairs come primarily from the architecture community.
 Figure 5 – Gender breakdown of Program Chairs. Next, we look at the individuals who hold decision-making roles for the major computer architecture conferences, and therefore set the tone for the conference and community. Steering committees wield influence into general/program chair selection, program committee composition, and possibly keynote speakers and panelists. In most cases, we do not suffer from too many “brogram committees” (exception being Micro 2015). However, the steering committees driving these conferences are particularly homogenous. The consistent track record of diversity in ASPLOS program chair selection mirrors the diversity seen in the steering committee. At the other extreme, the track record of the Micro conference reflects the lack of gender diversity on the Micro steering committee, as shown in Figure 6.
 Figure 6 – Gender breakdown of conference steering committees as of September 2017. Finally, we look at ways in which women in the community are recognized for their outstanding technical contributions. Recognition is key to retention and advancement (the subject of an upcoming blog post). In our community, recognition primarily comes in the form of keynotes, panels, and awards. Figure 7 shows the percentage of female keynote speakers over the last 5 years. Across 20 conferences, each featuring 2-3 keynote speakers, women have given just 4 keynotes (out of 45 total keynote addresses).
 Figure 7 – Gender breakdown of conference keynote speakers in last 5 years. Is women’s participation in the architecture community being recognized at the highest levels? Hall of Fame awards are given in recognition of high number of papers being published in a given conference series (typically 8). As shown in Figure 8, women constitute 9% (7 members) of the ISCA Hall of Fame, 9% (5 members) of the MICRO Hall of Fame, 8% (3 members) of the HPCA Hall of Fame and 16% (7 members) of the ASPLOS Hall of Fame. These percentages are fairly consistent with membership data. Women’s share of major awards including Eckert Mauchly and Bob Rau (career-long awards), Maurice Wilkes (mid-career) and TCCA Young Architect (Early Career) stands at 1 female recipient total.
 Figure 8 – Gender breakdown of Hall of Fame members and award winners. We’ve presented a great deal of data that illustrates a multi-dimensional problem in the computer architecture community, as well as providing some first order approximations on potential causes of the lack of diversity, including low diversity at the leadership level as well as low recognition for excellence.
We hope this data will serve to open the dialogue and get the community talking about ways to ensure we have the most welcoming community possible, and that we all take an active role in eliminating the unconscious biases that may exist.
To facilitate further discussion, we have planned a series of follow-up blog posts with concrete recommendations as well as additional data. Already on our agenda are follow-up posts on the following topics:
- A deeper look at “the pipeline” with data from R1 PhD granting institutions since 1980.
- The three “pillars” of diversity: recruitment, retention, and advancement, and the importance of weighting all three equally.
- Conflicting advice: The hidden downsides of “speaking up”.
- Be an ally: What to do (and what not to do)!
- The upside of intolerance: Calling out the unwelcoming behaviors in our community.
We hope you’ll join us on this journey. Even better, please join us an active contributor. We encourage general chairs and program chairs to collect conference participation data so we can perform longitudinal studies. This data collection could capture additional aspects of diversity including under-represented minorities and LGBTQ members of the computer architecture community. Active involvement from SIGARCH and SIGMICRO in automating or funding these studies would be a great step; we hope other SIGs will be inspired by this analysis and perform their own similar studies. Further ideas on how to automate and centralize data collection, or any suggestions for future content will be greatly appreciated!
About the authors: Natalie Enright Jerger is the Percy Edward Hart Professor of Electrical and Computer Engineering at the University of Toronto; she is currently leading the WICArch revamping effort. Kim Hazelwood is a Senior Engineering Manager in Facebook’s Infrastructure division. Her team focuses on datacenter server and storage architectures, performance analysis, and characterization of AI/ML workloads.
It is with great regret that I pass on the news that our colleague and friend Nathan Binkert is no longer with us. Nate passed away unexpectedly on September 21st after collapsing at the gym.
Nate was a computer scientist of remarkable breadth, equally at home working on architectures, operating systems, or databases. I was incredibly fortunate to have him as a PhD student at the University of Michigan. From there, his career took him to HP Labs, Amiato (a startup he co-founded), and, most recently, Amazon Web Services. He was also a phenomenal hacker. His leadership in developing and guiding the M5 and gem5 simulation systems is a tremendous and ongoing legacy in our community. He also served as the SIGARCH Information Director from 2008 to 2011.
Most importantly, Nate was a wonderful person. He was always smiling and full of energy, and unafraid of any challenge. He was a loving and dedicated husband and father. Please keep his wife and three children in your thoughts and prayers.
In this blog article we touch the subject of architectural evaluation methodology. We took the effort to interview some experts and collect opinions from experts on this subject. While everyone raises unique points, there seems to be some consensus..
The picture below is a good take-away. If your idea has good paradigm compatibility then simulate! Yes, some revolutionary ideas can have good paradigm compatibility (e.g. SMT). Of course be careful about your simulator configuration and verify its ground truth. If your idea requires a software overhaul – perhaps take the effort to build an FPGA prototype. FPGAs will provide the speed you need to run the new software stack. If your idea is incompatible with conventional paradigms or has components which today’s digital circuits can’t mimic – go forward and build a prototype. Show the faith and put in the effort! Even then be smart about choosing which component of your system to prototype and which components can be simulated. Minimize the pain. Hopefully the open-source hardware movement will be one way to minimize the pain.
*Disclaimer: The para above is my views based on expert opinions and own experience. It does not reflect any one expert’s opinion.
When to Prototype? When to Simulate? When to emulate on FPGAs?
Snippets from experts in alphabetical order : Todd Austin, David Brooks, Doug Burger, Lieven Eeckhout, Babak Falsafi, Karu Sankaralingam, Michael Taylor, David Wentzlaff.
Todd Austin “I will rephrase the question to – when can I not simulate? Prototyping is expensive both in terms of time, money and opportunity costs. One could potentially invest the time in other innovative research. It is not clear what can be learned by fabricating ASICs which cannot be learned from just completing design-time backend-placement – the last step before fabing an ASIC. Sometimes, the outcome of an ASIC is a validation of backend tools, which isn’t very valuable.
So, when can I not simulate? When there are parts of your system which are not 100% digital. For example our Razor project taped out a chip to test metastability issues, and we recently taped out the A2 malicious circuit chip to test analog attacks. Another example is your compute cache work which does in-cache gymnastics on bit-lines. Even in these scenarios you only need to fabricate a piece of the system which actually has the mixed-signal characteristics – for instance in Razor, we did not fabricate a complex multi-processor.
Beyond providing a window into the analog portions of your design, prototyping has the added advantage of high visibility. Prototyped projects generate a lot of attention and become a lightning rod of interest – so if you do go the route of building a chip, there is a good payback in project visibility for the expensive cost.
An FPGA as an ASIC evaluation platform is not particularly useful because it does not provide any clear insights about how an ASIC would perform, in terms of critical path delays and overall power. But I’m still a big fan of FPGAs, because they are useful to speedup up simulations and design prototypes, when you really need the operational speed.”
David Brooks “There are at least three scenarios where prototyping can help. First, when the research includes a new circuit (e.g. mixed signal analog-digital) or operating paradigm (e.g. near-threshold computing) in which the physical characteristics are hard to capture in high-speed, high-fidelity simulations. Such ideas are best evaluated in prototypes and ideally lend themselves to publications in both the VLSI and computer architecture communities. A circuit precursor shouldn’t negate the architectural contributions, in fact it makes them more tangible. But it isn’t necessary to build a Xeon processor. A small chip focused on the novel circuit component is sufficient and simulations can bridge the gap to larger systems. The second scenario is when the research has a critical software component. As examples, recall the RAW and TRIPS projects from MIT and UT-Austin respectively. These architectures required new OS and compiler infrastructure. It is hard to motivate software researchers to write code for a machine that doesn’t (and may never) exist. Of course, the added benefit is that the prototype will be orders of magnitude faster than simulations. Third, when researchers contemplate a start-up or other tech transfer. The recent surge in silicon startups is a boon for the computer architecture community. Silicon prototyping is useful to transition technology from a research lab to a start-up. Investors want to see something tangible and proof that the team can take ideas to the next level. Prototyping provides credibility and visibility, and Berkeley’s succession of RISC-V chips is a great example of this.
These are three scenarios when prototyping can make a big difference. Otherwise simulate! Simulations are great for getting ideas out in a rapidly moving field or evaluating ideas which build on top of well understood baselines. Consider simultaneous multi-threading. The intuition behind the idea was backed up with simulations. Although the idea was revolutionary, it built on top of a well-known micro-architecture so industry practitioners could immediately see the value. Another scenario where simulation is necessary is where the core technology (e.g. 3D stacking or other advanced packaging technologies) is not mature enough to be available.
Of the three scenarios described, FPGAs can be quite useful for the second scenario – new architecture that also require an overhaul of the software stack. If we were to re-do the TRIPS project with today’s available high-end FPGAs, an FPGA prototype may be sufficient. FPGAs are perhaps not that useful for startups, because they often can’t provide power-performance quality of design metrics equivalent to ASICs. They are least useful for the first scenario because it is hard to emulate physical characteristics in an FPGA.
As the Catapult project from Microsoft shows, high-end FPGA are making their way into massive datacenter deployments. Amazon’s EC2 now offers an FPGA instance. These projects open up enormous opportunity to prototype ideas at scale for cloud workloads, which has traditionally been impossible for most researchers due to the staggering cost of building ASICs for 200-600 mm2 dies. On the other hand, small ASICs targeting mobile/IoT systems are well within the capabilities of most academic groups.”
Doug Burger “It’s not just simulation or prototyping. There are three buckets: modelling, simulation, and prototyping. In many scenarios modelling is sufficient – think how many times you have used Amdahl’s law or Little’s law. However as system complexity grows, simulations become more important. Simulations are really useful when the paradigm is well understood and researchers have a good mental model. SimpleScalar is a great example. Everyone knew how an out-of-order core works. Simulations were good to evaluate techniques which extending it or improving it.
Final bucket: prototyping. Prototyping is useful for several reasons, primarily because it lowers the levels of abstractions. First, to capture lower-level RTL complexity or physical design speed or power or other design aspects which are “abstracted away” in simulators. Second, training of students and faculty. Prototyping gives a deep understanding and researchers develop an intuition for future design- what will work well in hardware. Third, the pressure to tape-out leads to rigorous verification of design. Fourth, understanding the phenomena at scale. Prototyping produces fast hardware on which you can run complex software. This is essential for modern, beyond the SPEC world. Further, prototyping allows you to study large scale distributed systems. The Catapult project distributed hardware prototypes over 1632 servers, in a real datacenter. Physical deployment at scale brings forth interesting challenges and problems which can’t be understood by using single node systems or mimicking few number of nodes. Simulations are too slow to mimic large scale. Fifth, prototyping builds confidence, trust and leads the way to commercial impact. This is especially necessary for weird, unconventional architectures where there is a fear of not knowing the unknowns.”
Lieven Eeckhout “There is no single tool or methodology that fits all needs. We need to pick the right tool for the job. For some experiments, this may be cycle-accurate simulation. For others, this may be hardware prototyping. For yet other experiments, this may be analytical modeling. The key point is to make sure the methodology is appropriate and drives the architect in the right direction. An inappropriate methodology may lead to misleading or even incorrect conclusions.
For chip-level or system-level performance evaluation, I’d argue for raising the level of abstraction in architectural simulation. Cycle-accurate simulation is simply too slow to simulate the entire chip or system. Ironically, the level of detail gets in the way of accuracy, i.e., because the simulator is so detailed, it is extremely slow and hence one cannot use the tool to simulate large systems nor can one simulate a representative long-running workload. Hardware prototyping using FPGAs enables modeling large systems at a sufficiently high simulation speed, however, simulator development and setup time may be impractical.
Raising the level of abstraction in architectural simulation has the potential to achieve high accuracy for modeling large systems at sufficiently high speed, while keeping development cost modest. By combining the strengths of analytical modeling with the strengths of architectural simulation, one can achieve a powerful hybrid modeling approach that enables the architect to quickly explore the design space of increasingly complex systems. This was proven a useful methodology for modeling multi/many-core systems. Moving forward, I believe it will be an indispensable method in the architect’s toolbox to model future heterogeneous SoCs with general-purpose multicore processors along with a set of integrated accelerators”
Babak Falsafi “The days of sticking to one simulator and one set of workloads are over (used to be SimpleScalar and SPEC, now gem5 and SPEC/PARSEC). The post-Dennard, post-Moore era calls for using the right tools at the right time. To make a strong case for a design we need to pick the right set of tools to measure performance, power and area.
Profile-based sampling (common practice) works for user-level apps with distinct phases (e.g., DNN’s, graph processing). Workloads with deep software stacks and frequent interaction among software layers not only require much larger measurement windows (e.g., TPC or server workloads) but also are often not phase-based. One practical way of extracting a representative measurement from them is statistical sampling (e.g., SMARTS).
With FPGAs launched in the mainstream with enhanced toolchains and a development ecosystem on the one hand, and open-source technologies, on the other, we will be relying more than ever on FPGAs in design evaluation. Fabbing chips will remain a niche with limited access only to those (in academia) who have the budgets and resources for them.”
Karu Sankaralingam “When simulations are used, the most important thing that researchers must realize is that simulators are not meant to be used as black boxes. They should at least internally verify their simulators and understand the details of how they work for the scenarios they are considering in their research. Researchers must also be extremely cautious when using these tools for configurations outside the validated point. Furthermore, it is very useful to consider simple first order models as well instead of always looking for cycle-level simulation. When ideas span multiple layers of the system stack cycle-level simulation becomes less and less important and useful.
Prototyping by building ASIC chips or mapping to an FPGA is another vehicle for research exploration. Prototyping is extremely useful for researchers and students in particular as a learning vehicle and to work in interdisciplinary ways with application developers since they are more likely to use an FPGA model or ASIC than a (slow) simulator. Building a prototype helps flesh out the entire system stack and learn about design constraints and complexity of the implementation that can only be uncovered by doing.”
Michael Taylor “I employ both simulation and prototyping extensively in my research group.
Simulation’s greatest strength is that it gives you incredible agility in exploring design spaces at low cost. The challenge is that, as the adage goes, simulation is doomed to succeed. Since software does not need to obey physics, it’s easy for bugs or assumptions to creep in, especially the larger and more complex the simulation, and the less we spend verifying the code and the assumptions (I spend a lot of time on this, much to the chagrin of my students eager to get the next paper out!). Sardonically, in the Arch 2030 workshop, I gave a basic algorithm for simulation that highlights some of the troubling issues in our community below:
performance simulation:
repeat (modify_c_simulator())
until (perf>=10%
|| sim_bug_in_my_favor
|| overtrained_on_my_10_benchmarks )
assert (it_would_really_work_in_hw)
power simulation:
assert(we_used_McPat && no_space_to_describe)
Prototyping great strength is that it exposes your design to the three iron laws: Physics, Amdahl, and Real World Crap. Prototyping autocorrects those simulator bugs, and often exposes the real challenges in building systems.
Some ideas are particularly sensitive to the laws of physics and make a lot of sense to prototype to just make the research believable; for example, operating at near threshold or protecting from power side-channel attacks. Or, anything that is truly transformative in terms of energy/power. Other ideas, for example, the MIT Raw Tiled architecture and UCSD GreenDroid, result in systems that are very different than prior designs and need to have a reasonable baseline implementation that enables accurate simulators and enough confidence for follow on research to be done.
Especially with the availability of open source processors like Berkeley’s Rocket generator, reusable IP libraries like Basejump STL, ASIC bootstrap infrastructure like Basejump and HLS, it becomes possible to prototype real versions of your system with far less effort and time than ever before. Our recent Celerity SoC tapeout had 5 Linux-capable Rocket cores, a 496-core manycore, a binarized neural network accelerator and a high-speed I/O interface. My team, Chris Batten’s team, and Ron Dreslinski’s team taped this out in TSMC 16nm in 12 months. Why mess with simulators when you can build the real thing? All of the team members learned a ton about designing HW, and we get to explore creative designs far outside of what industry is doing.
I think that the longer a community researches something based only on simulation, the more likely they are to make a wrong turn somewhere and end up researching something based on false hypotheses or optimizing the wrong thing. Think for instance, the presumed dominance of VLIWs like Itanium over x86 OOO processors. More prototyping could potentially have corrected these assumptions earlier and accelerated our research progress as a community.”
David Wentzlaff “Prototyping is incredibly valuable when doing computer architecture research. It can provide insight way beyond what simulation or analytical models can provide. Having said that, I am also a firm believer that you should only prototype research ideas after they have been thoroughly modeled or simulated. Philosophically, I believe that researchers should build prototypes not products. As a researcher, hardware prototypes should push the boundaries of research, test out novel ideas, and be designed in order to scientifically evaluate the ideas (ex. include extensive power monitoring, extra performance monitoring, extra flexibility, and the ability to disable new features in order to evaluate with and without the new ideas if possible). In particular, I have found building complex processors such as the 25-core Princeton Piton Processor is important when evaluating ideas at scale and at speed. The scale and speed provided by building complex prototypes enables classes of research and insight that are just not feasible at simulation speed such as operating system/hardware co-design, research that involves running real operating systems, real hypervisors, complex programs with full inputs (ex. Piton runs Doom (video game) and SPECint on full size inputs), and research that requires large numbers of cores working together (scale). Building prototypes also provide much more ground truth fidelity for historically difficult to model parameters such as energy modeling, clock speed, wire delay, and process-level constraints which are becoming increasingly important as feature size shrinks. Prototyping can also be essential when using novel devices, for instance, our recent work on biodegradable and organic semiconductor processors is in a technology that does not even have much intuition or ground truth, necessitating prototyping.”
About the Author
Reetuparna Das is an assistant professor is University of Michigan. Feel free to contact her at reetudas@umich.edu
Browser-Friendly feed by FeedBlitz RSS Services, the premium FeedBurner alternative. | 
