SystemC For System Design: Our Academic Experience
Ravi Shankar, Carlos Krieghoff · 2008
ion and use of system level description languages. Such languages would model software and hardware together; address the issues of concurrency, synchronization, and communication; and allow one to perform what-if scenarios at various levels of abstraction. SystemC is a modeling language that was developed by the Open SystemC Initiative (OSCI) planning group, to address the needs of system level software-hardware codesign. SystemC is based on the C++ language. SystemC 1.0 provides a set of modeling constructs that are similar to those used in RTL (register transfer level) and behavioral modeling within an HDL. SystemC 2.0, released in 2001, improves upon SystemC 1.0, to enable system level modeling – that is, modeling of systems above the RTL level of abstraction, including systems which might be implemented in software, hardware, or some combination of the two. It introduces a new set of features for generalized modeling of communication and synchronization, called channels, interfaces, and events. The language supports multiple levels of abstraction, a common environment for design and verification, and hardware-software co-design. Currently the SystemC language is undergoing standardization, but has already been adopted by over one hundred design companies. The infrastructure requirement is quiet low as SystemC is open source. Visual C++ and Open source OSCI simulator provide sufficient support to develop SystemC code. SystemC is designed with a small general purpose modeling foundation, so that one can easily add various models of computation, design libraries, modeling guidelines, and design methodologies as required for system design [OSCI, 2002]. We detail below our experiences over the past two years with an undergraduate computer engineering core course entitled “CAD-Based Computer Design.” In earlier offerings, the course used, first VHDL, then Verilog HDL, to design, a 16-bit central processing unit. Though the course attracted a few computer science majors on occasion, the job trends and the difficulty in learning a new concurrent language made it primarily a computer engineering course. However, several recent trends persuaded us to rethink the status quo: The number of world-wide ASIC designers is shrinking, thanks to the automation unleashed by the EDA (engineering design automation) industry, and resulting increase in productivity; The technology continues to shrink the transistor and provide more functionality at lower cost, blurring the cost differential between ASICs (application specific integrated circuits) and FPGAs (field programmable gate arrays); Consumers are continuing to demand more complex functionality in their (typically) mobile wireless embedded systems; Increasing system complexity from all these trends has led to significant design reuse and the evolution of many IP (intellectual property) design companies; and Complexity management with a divide-and-conquer approach and 3 party IP bocks has actually led to system level issues as the major show stoppers for the high tech industry. Thus, we concluded that new productivity challenges (and hence, jobs) are at the system level, specifically with regard to software-hardware co-design, coverification, and performance tradeoffs (One can add executable specifications to this list, which is beyond the scope of this paper). Further, Dataquest has predicted that the primary growth in the EDA industry will come from ESL (electronic system level) tools [DataQuest, 2002]. Thus, we concluded that similar to the digital design tools of the 1990s, the current and future ESL tools will drive the job market in the SoC (system-ona-chip) domain over the next decade. Fortunately for us, two years ago, the competition between SystemC and System Verilog was heating up. It gave us an opportunity to compare two approaches that originated from two distinctly different philosophical perspectives. SystemC proponents wanted both software and hardware practitioners to interact more comfortably, while the System Verilog proponents viewed system design as primarily the forte of the hardware engineer who was already familiar with Verilog and had access to good back-end automation tools. The jury is still out as to which approach will ultimately succeed, since we see pros and cons to both sides of the argument. However, we decided to go the route of SystemC, for a number of reasons: (1) Since it is C++ based, software engineers will accept it, while hardware engineers, at least the recent graduates, will have familiarity with the C++ language. Thus, a common platform for communication existed; (2) One could use low cost tools for simulation. Traditionally, the EDA tools have needed a steep learning curve and a large budget (relative to the cost of software tools) to maintain; and (3) SytemC allows modeling and design at multiple levels of abstraction, with the prospect of supporting software developers with a truer hardware model, system architects with high and mixed level models for their what-if scenarios, and hardware designers with EDA support for automated translation/synthesis [Shankar and Suryaprasad, 2002]. However, SystemC simulations are slow relative to the simulation speed achieved by stand-alone software and hardware development environments. We view this as a current limitation and technologies exist/ will evolve to address this, if indeed SystemC turns out to be a viable medium for system design. As such, our role, as an academic institution, was deemed to explore SystemC fully and thoroughly, and provide feedback on our experiences. 2. Methods 2.1 The Course Outline: Carlos, Include material from Surya’s paper here. Start at ‘Course Content’ on page 2 and use most of his writeup through the end of page 3. The majority of the students taking the CAD Based Computer Design course are in their junior or senior year. As a result, they all have C++ programming experience from other required courses such as: Foundations of Computer Science or Data Structures where they become familiar with this particular programming language. The first surprise the students have though is when they learn that we will be modeling hardware using a programming language. They feel motivated. Thus, we begin the CAD Based Computer Design course by exploring the history of hardware-software co-design during the past several years. Subsequently, we introduce to the students the different SystemC constructs that allow us to model hardware using C++. Such SystemC constructs are new defined data types and concepts like ports and signals, and the declaration and implementation of processes using SC_METHODs or SC_THREADs. The usage of the SystemC constructs is shown to the students through a variety of simple examples (1-bit adder, multiplexer, counter, etc). Figure 1 shows the basic SystemC structure used to simulate systems. The system that is simulated is instantiated with the driver and monitor SystemC modules. The driver will generate the stimulus to the system and the monitor will gather the results. The results can be displayed on the screen, saved on a text file or saved as a waveform format. 2.2 Our Course Offerings: We have taught the “CAD-Based Computer Design” three times, over the past 2 years, using SystemC. In the first offering, we had a class of 52 seniors from computer science, computer engineering, and electrical engineering undergraduate programs. We taught SystemC and the conventional concepts of hierarchy, modularity, reuse, and state machine design. Since this was our first offering, we kept our designs close to the RTL level as covered in an excellent introductory book [Bhasker, 2001]. However, to inject the perspectives of cooperation and competition, we also involved the class in a half-semester long project that simulated the IP (Intellectual Property) market dynamics. The goal was to provide students with a real-life experience of IP development and usage and provide an entrepreneurial experience while providing credit for their participation. The IP market we simulated had 3 major participants, namely the IP developers, EDA vendors, and System Designers. The IP companies developed basic building blocks for digital design. Their deliverables included IP design models, source code, and application notes. These were then submitted to EDA vendors whose primary objective was to rank these IP on a scale of 1 to 5. EDA vendors were also invited to develop tools to facilitate IP development and integration. System companies chose the better ranked IP blocks to integrate and model their system talk. By self-selection, the class ended up with 16 IP companies, 4 EDA companies, and 6 System companies. The project goal was to build a fixed point (16/32-bit) or floating point (IEEE Standard) ALU (arithmetic and logic unit) sc_main