Embedded Systems Conference San Francisco 2002 The SpecC System-Level Design Language and Methodology, Part 1 Class 309 Rainer Dömer Center for Embedded Computer Systems Universitiy of California, Irvine, USA Abstract A well-defined design methodology supported by a system-level design language (SLDL) is the key for managing the complexity of the design flow, especially at the system level. Only with well-defined and unambiguous models and transformations can we achieve productivity gains through synthesis, verification and tool interoperability. This paper presents the SpecC system design language. After a general overview of SLDL requirements, it describes the SpecC language as an example of a language specifically developed to support a formalized design flow. This is the first paper in a two-part series. This part introduces the SpecC model and the SpecC language. 1 Introduction Systems-on-Chip (SOCs) are faced with a huge increase of design complexity. A well-known solution in computer science for dealing with complexity is to exploit hierarchy. This effectively reduces the complexity in terms of the number of objects to be handled at one time. Figure 1 illustrates this principle for digital systems. An embedded system, which at the lowest level consists of 10ths of millions of transistors, typically reduces to only thousands of components at the register-transfer level (RTL). Furthermore, RTL components are grouped together at the algorithm level. Finally, at the highest level, called system level, a single system is composed of only few components which include microprocessors, custom hardware units, memories, a variety of IPs, and busses. Please note that the level of abstraction is a trade-off with the level of accuracy. The higher the abstraction level, the lower the accuracy, and vice versa. Level Number of components 1E0 System 1E1 Ab Algorithm 1E2 Ac str cu 1E3 ac ra RTL tio cy 1E4 n Gate 1E5 1E6 Transistor 1E7 Figure 1: Abstraction Levels. 1 From Figure 1, it is obvious that the design of a complex embedded system is easier at the system level than at the detailed gate or transistor level. Thus, one solution to deal with the increased complexity is to move to a higher level of abstraction, called the system level. From the system level, the SOC design methodology then works its way through several refinement steps down to the implementation. The design process of a new system usually starts from an abstract specification model and ends with a highly accurate implementation model that reflects the real system with all its details. The advantage of such a top-down approach is that all necessary design decisions can be made at an abstraction level where all irrelevant details are left out of the model. This allows designers to work with a model of minimum complexity. 2 The SpecC Model The following section takes a closer look at the SpecC model, including its components and its features. C1 P1 P2 B1 B2 s1 v1 s2 v2 s3 v3 (a) (b) Figure 2: (a) Traditional Model, (b) SpecC Model. 2.1 Traditional Model For the design of embedded systems, the key representation for any design is a block diagram. Block diagrams consist of a set of blocks and a set of interconnections between the blocks. The blocks in the diagram represent components that perform a particular function or computation. Also, the blocks can communicate with each other through the interconnections. Here, it is important to note that there are two distinct actions performed by the blocks, namely computation and communication. The traditional model of a block diagram, such as in VHDL or Verilog, is shown in Figure 2(a). Two processes, P1 and P2, are communicating via variables s1, s2 and s3. By assigning values to the signals, according to some predefined protocol, the processes can communicate and exchange data. In this scenario, the processes P1 and P2 contain code for both communication and computation. The communication part is highlighted in the figure. Because communication and computation are freely intermixed in the code, they cannot be identified by any tool. As a result, it is not possible to automatically change the communication protocol when design constraints change. On the other hand, it is also impossible to automatically switch to a new algorithm to perform the computation. 2.2 SpecC Model The SpecC model does not have this problem. In the SpecC model, communication and computation are clearly separated. Computation is encapsulated in behaviors, and communication is encapsulated in channels, as shown in Figure 1(b). Here, the computation is encapsulated in the behaviors B1 and B2, and the communication is contained in the channel C1. More specifically, the channel C1 encapsulates the communication in form of functions, such as send and receive. These functions define the interfaces of the channel. The channel also encapsulates the communication media, i.e. the variables v1, v2 and v3. On the other hand, the behaviors only contain computation. In order to communicate, the behaviors call the functions provided by the connected channel. 2 As a result of the separation of communication and computation, the SpecC model supports “plug-and- play”. The communication protocol can be easily exchanged by use of another channel with compatible interfaces, whenever this is desirable in the design process. In the same manner, the behaviors can also be exchanged with others, without affecting the communication protocol. 2.3 Protocol Inlining In SpecC, behaviors and channels are used throughout the design process, i.e. in the specification model and during design exploration and refinement. This way, the “plug-and-play” capability of the SpecC model can be exploited at any stage in the design flow, whenever it is useful. However, in the final implementation model, channels are reduced to variables representing wires by a process called protocol inlining. C1 B1 B2 B1 B2 v1 v1 v2 v2 v3 v3 (a) (b) Figure 3: Protocol Inlining, (a) before, (b) after. For the implementation of a channel, its functions are inlined into the connected behaviors and the encapsulated communication media are exposed. This is illustrated in Figure 3. After the inlining process, the channel C1 has disappeared. The encapsulated variables v1, v2 and v3 are exposed and the communication protocol is integrated into the behaviors B1 and B2. Please note that in this final implementation model communication and computation are no longer separated. Moreover, the resulting model is essentially the same as the traditional model discussed earlier. This allows a straightforward translation of the implementation model into the traditional VHDL or Verilog models. As a result, the SpecC design flow can be easily integrated with a conventional design process. 2.4 Plug-and-Play with Computation Now that the basic “plug-and-play” feature of the SpecC model has been introduced, the reuse of intellectual property (IP) components will be addressed. First, the reuse of computation IP is shown by use of “plug-and-play” with the so-called adapter model. B T IP A v1 (a) (b) v2 Synthesizable Transducer Adapter IP behavior Figure 4: Computation IP, Adapter Model. Figure 4(a) shows a synthesizable behavior B. Note that the behavior is still missing the code for a communication protocol, which will be inlined later from a connected channel. On the other hand, Figure 4(b) shows on the right a fixed IP core with a built-in communication protocol. In order to allow “plug-and-play” with the IP core, it is connected to an adapter channel. An adapter is a channel that has ports just like a behavior. These ports are connected to the variables v1 and v2, which in turn are mapped to the ports of the IP. Communication with the IP is established by use of a set of high- level communication functions provided by the adapter. These functions contain the detailed interface 3 protocol to drive the wires connected to the IP. Thus, by using the adapter functions, other behaviors can easily communicate with the IP. Further, a transducer T is needed to make the components on the right side equivalent to the synthesizable behavior B on the left. A transducer is a synthesizable behavior used to connect two channels. Later in the design process, the transducer T will incorporate two communication protocols. The reason for the need of a transducer stems from the fact that two channels cannot be directly connected because they are passive components. In order to connect passive channels, an active transducer behavior is needed in the middle. As a result, the synthesizable behavior B on the left can be replaced by the IP adapter model on the right at any time in the design process without affecting any other objects. B1 IP B1 IP A v1 v1 v2 v2 (a) (b) Figure 5: Protocol Inlining with Adapter, (a) before, (b) after. The process of inlining with an adapter channel is shown in Figure 5. Before the protocol inlining, the IP adapter is connected to a synthesizable behavior B1, as shown on the left hand side. On the right hand side, the same example is shown after protocol inlining. After the adapter has been inlined, the IP communication protocol has been integrated into the behavior B1 and the variables v1 and v2 directly form the connecting wires to the IP. Note that the adapter A has completely disappeared. 2.5 Plug-and-Play with Communication Similar to IP cores for computation, “plug-and-play” also works for communication IP in the SpecC model. A proprietary implementation of a communication protocol is represented by an IP channel in SpecC, such as the one shown in Figure 6(b). With one exception, this channel is not different in its usage compared to the virtual channel on the left.