16550 UART Structure 

Context in source publication

Context 1

... can imagine more advanced types of join-points, e.g. including the execution of commonly used control structures like loops or case-statements. However, even these simple join-points can be quite useful when designing hardware. Section 4 describes a real-world example that makes use of these join-point types. Analogous to the aforementioned AOP languages, pointcuts for VHDL consist of a set of join-points combined using first- order logic formulae and wildcards to create a set of join- points. In the case of VHDL, its inherent concurrency has interesting consequences. Consider, for example, combining join- points at the setting of a signal using the “and” operator. In programming languages, a combination of two call(...) join-points using an && operator normally would not match anything. In VHDL, however, signals can be set concurrently, so a pointcut combining two such join-points would actually make sense. Additionally, it would be useful if one was able not only to describe single events, but rather to capture a sequence of events. Here, temporal logic could be used to create more complex pointcut descriptions[1]. This is also an interesting area for future research. Special care must also be taken when combining join- points that reside in concurrent vs. sequential parts of the VHDL code. This is discussed in detail below. As a first approach, the types of advice useful in an aspect- oriented extension of VHDL can be modeled after well- known advice types. However, due to the concurrent nature of VHDL, before and after advice are only well-defined in the context of processes. An around advice, however, can replace a signal assignment in a concurrent environment. Depending on the context, the proceed statement contained in the advice code will have to behave differently. If the related join-point is inside of a process, it will cause the original code (e.g., a signal assignment) to take place at the point in time proceed is executed. Outside of a process, however, timing is not relevant, thus proceed will create an additional, concurrent signal assignment. One important question is whether the code inside an advice is concurrent or sequential. If a pointcut for an advice includes join-points in concurrent structures, including concurrent code in the advice will result in additional, possibly conflicting, signal settings. Using a process inside that advice would be analogous to including the signal set at the related join-point in the sensitivity list of that process. If, however, a pointcut for an advice contains join-points in sequential VHDL code, then the execution of the advice code as a sequential process in the context of the original process containing the join-point is the only useful alternative. Overall, the most important differences between AOP in hardware description languages to classical aspect-oriented programming languages are caused by the implicit conocur- rency in HDLs (which may also be a problem for aspects in parallel programming languages). While a process is similar to a kind of advice, crosscutting concerns can still be found inside the code of a process. These properties are demon- strated using VHDL code in the following section. In analogy to the open source software movement, the approach of describing hardware using a HDL has led to an open hardware movement. This gives the chance to take a look at HDL implementations of complex circuits. Such an analysis was formerly impossible since hardware developers were guarding their intellectual property. 4 In this section, we verify our assumptions about crosscutting concerns by examining an implementation of a UART 5 as an example of a circuit used in real-world applications. A UART – Universal Asynchronous Receiver and Transmitter – is a circuit used for bit-serial communication between computer systems and peripheral devices like modems or printers. One common UART is the 16550, which is available as an open source VHDL implementation from QuickLogic, Inc. [11]. The 16550 UART consists of five interconnected entities (see fig. 5): transmitter, receiver, modem interface, bau- drate generator and interrupt controller. This structure is reflected in the VHDL source code, which consists of the files uart16550_baudgen , uart16550_intgen , uart16550_modem , uart16550_rx and uart16550_tx . In addition, the file uart 16550_top contains the top-level description of the circuit, i.e., its external bus interfaces. Each of the VHDL source files contains an entity part describing the components’ interface and an architecture part consisting of several parallel processes implementing the required functionality. One common problem of digital circuits is the handling of RESET conditions, in which the component is to be ini- tialised. This code is usually scattered over the various components of the design, each process that includes state, that has to be reset asynchronously has the RESET signal in its sensitity list, see fig. 6. Overall, there are 14 processes in the UART’s source code that are sensitive to the RESET signal contained in the source spread over five source code files. The code implementing the various reset functions can be factored out into an aspect. Fig. 7 shows a hypothetical VHDL AOP extension. Here, the pointcut describing the affected code positions has to match all functions that are sensitive to a reset. Since a process is started when any of the One important repository for open source hardware is 5 Universal Asynchronous Receiver and Transmitter signals in its sensitivity list change, this pointcut includes all of the functions that include RESET in their sensitivity list. The corresponding advice function can then implement the reset of all signals. Another crosscutting concern in the UART code is clock handling. There are eight different processes that depend on the system clock ( SCLK ). The processes are distributed over the source files for the receiver, transmitter, and the top level design file. In each of these processes, the level sensitivity of SCLK is checked via Here, one possible application for aspects is to change the clock base by introducing a local signal and creating a clock divider. When implementing this additional functionality, code at all of join-points, the eight processes that include the SCLK signal in their sensitivity list, is affected. The earliest mention of aspect-oriented approaches in hardware design can be found in Kiczales’ original paper on aspect-oriented programming[12]. Here, he discusses the Ptolemy project[7], which studies modeling, simulation, and design of concurrent, real-time, embedded systems with a focus on assembly of concurrent components. Interaction between heterogeneous components in Ptolemy is handled with concepts that are similar to aspects. In [6], AOP is applied to applications developed using SystemC [17] and AspectC++ [15]. Important system aspects like metrics measure, communication and cache policies are modelled. However, synthesizing real hardware from SystemC descriptions is difficult, so this approach is rather more useful in the area of simulation and verification. ADH [3] is a domain-specific HDL focusing on control modeling problems as well as the signal and image processing domain. A compiler translates the ADH descriptions into VHDL for synthesis. ADH supports the definition of pointcuts in hardware descriptions and before, after and around advice. However, the nature of the join-points in ADH does not take the inherent parallelism into account, it mostly concentrates on using AOP in sequential control flows for signal and image processing. In [18], aspect-oriented approaches to verification of digital systems using the e hardware description language [10] are described. While the paper gives a good overview of possible causes for crosscutting concerns in hardware description languages, the e language itself is rather limited in its sup- port for AOP. For example, there is no notion of pointcuts, since an advice may only relate to a single join-point. In addition, e is restricted to the verfication of hardware. Due to the lack of quantification, we consider this approach as highly-limited AOP – if at all. In [4], the authors describe a first idea to use AOP to for- mulate crosscutting concerns in hardware description languages. However, the only example given is the management of distributed clocks in hardware systems; an implementation does not seem to exist. The options approach [5] is the application of a concept from economy to the problem when to introduce AOP-based constructs in hardware design. However, the AOP concepts this decision relies on is based on the concepts presented in the paragraph above[4], so it should be re-evaluated when a more complete understanding of AOP for hardware design has evolved. The analysis of related work on aspects in hardware design has shown that there is considerable interest in applying AOP techniques in this domain. However, the existing approaches concentrate on design verification rather than ...