Formal Specification of an Asynchronous On-Chip Bus

Transcription

1 Formal Specification of an Asynchronous On-Chip Bus Juha Plosila Tiberiu Seceleanu Turku Centre for Computer Science TUCS Technical Reports No 461, 14th June 2002

2

3 Formal Specification of an Asynchronous On-Chip Bus Juha Plosila Tiberiu Seceleanu University of Turku, Dep. of Applied Physics, Lab. of Electronics and Information Technology, FIN Turku, Finland, Turku Centre for Computer Science TUCS Technical Report No th June 2002 ISBN ISSN

4 Abstract The latest improvements in the technology of digital devices allow designers to build whole systems on a single silicon chip. New problems arise in this context, one of them being the complexity of interconnections. Optimizing interfaces has become a tedious design step. Another issue is the power consumption, for which globally asynchronous locally synchronous approaches provide to be a good solution. Formal methods can be used to verify the logical correctness of digital hardware. These methods are well featured for asynchronous designs and this study introduces bus-modeling aspects in the formal framework of Action Systems.

5 1 Introduction The designers of present day digital-systems face the continuously increasing complexity of the electronic devices. Modern deep sub-micron silicon technologies have given a real boost to system-on-chip (SOC) design research and development. A key issue in integrating a whole system into a single chip is to realize efficient and reliable interconnections between system modules on the chip, because the overall performance of the system is constrained by the properties of the interconnect. Furthermore, the time required to complete a design task depends strongly on the complexity of the different interconnections in the system. Optimizing interfaces has become a cumbersome process [12]. A common way to implement a digital system is to build it around a bus shared by the system modules. As the modules connected to the bus have uniform interfaces, the bus-based design approach offers a relatively rapid method to construct large systems-on-chip. In future high-performance systems, maintaining global synchrony will be increasingly difficult, if not impossible. A solution to this problem comes from the employment of asynchronous, or self-timed, design methodologies [4]. Enhanced composability is another advantage of self-timed approaches over synchronous ones. Most general purpose bus designs are asynchronous because asynchrony is more flexible in accommodating a wider range of devices, or due to the modularity of the designs [8]. Asynchronous bus designs also adapt more readily to technological advances. Therefore, the present study describes a self-timed bus structure. This means that all the components of a system employing the bus interact via handshakes on asynchronous communication channels, while locally they can operate synchronously, controlled by some local clock signal(s). The integration of processor technology into complete system approaches requires comprehensive know-how of verification and the development of SOC solutions, both at the functional / behavioral as well as at the physical levels. Formal methods of concurrent programming can be used to verify the logical correctness of digital hardware. They are especially well-suited for modeling asynchronous, self-timed behavior, where sequencing of events is based on handshakes between units [7]. This study relates to the framework of the Action Systems formalism, which has recently been applied to the area of VLSI design [11, 13]. In this paper, we present an Action Systems-based specification of an on-chip bus targeted for SOC designs. While bus-related protocols have been studied before from a formal point of view [9, 10], our study goes one step further and describes the components of a bus-based system. The specification is composed of the formal descriptions of the bus components, including the central bus controller (arbiter) and the abstract models of the master and slave modules attached to the bus. The generality of the specification allow for further derivation towards 1

6 concrete descriptions, at lower levels of abstraction, following precise rules. We only provide template-components, which can fit a large range of actual devices. From a more specific point of view, the integration of a bus model into our Action Systems framework is a part of our current work on developing a formal design flow for complex systems-on-chip. In this flow, a design process from a specification to an implementable model is viewed as a sequence of correctness preserving refinement steps. Employment of bus-based systems imposes a standardization of the elements grouped in the same design. However, no one would benefit if this would mean also imposing strong restrictions. Thus, the bus structures have to be highly versatile regarding the interaction with the components attached to such structures. Instead of trying to develop a brand new bus specification, we prefer to adapt to our needs an existing standard bus. The AMBA bus specification [1] is an established, open bus standard that serves as a framework for SOC designs. We intend to use as many as possible characteristics of this specification in our descriptions. However, mostly because AMBA is a synchronous bus, our asynchronous bus does not require some of the control issues of the original specification. On the other hand, we introduce several new control signals which are needed in asynchronous communication between system units. Thus, our representation of the bus controller and the associated masters and slaves would show some differences concerning the interfaces with respect to the AMBA specification. For the matched signals, we will use the same notations as in [1]. At this moment, we only concentrate on the high-performance part of the bus, AHB. Overview of the paper. The paper is organized as follows. In section 2 we briefly describe some notions of Action Systems which we will use in the rest of the study. Section 3 brings in the view basic concepts regarding bus issues. The following section 4 describes the elements that compose a bus-based system: masters, slaves and the bus arbiter. We continue in section 5 with a short discussion on the differences between the synchronous and asynchronous bus representation / implementation and on some techniques we could use at next levels of the design. We conclude our work with remarks provided in section 6. 2 Action Systems The Action Systems formalism is based on an extended version of Dijkstra s language of guarded commands [6]. An action is defined (for example) by Ü Ü ¼ Ê ½ ¾ ½ ¾ nondeterministic assignmentµ nondeterministic choiceµ sequential compositionµ 2

7 È ½ ½ ¾ guarded actionµ prioritized compositionµ where È and Ê are predicates, Ü is a variable or a list of variables, and ½ and ¾ are actions. Semantic of an action is defined by the weakest precondition for to establish a post-condition É, denoted ÛÔ Éµ. The guard of an action, is defined by ÛÔ Ð µ. An action is said to be enabled, if its guard is ØÖÙ, disabled otherwise. Actions are considered atomic, meaning that whenever one is selected for execution, it will be completed without interference. Ý ÒØ Ö Ð Øµ Ú Ö ÐÓ Ð Ú Ö Ð Ð Ö Ø ÓÒ ÓÒ Ø ÐÓ Ð ÓÒ Ø ÒØ Ð Ö Ø ÓÒ ÜÔÖ ÓÒ ÜÔÖ ÓÒ Ù ØÓ Ø Ö Ð ØÝ Ø ÓÒ Ø ÓÒ Ð Ø Ò Ø Ò Ø Ð Þ Ø ÓÒ Ó Ú Ö Ð Ó Ø ÓÒ ÓÑÔÓ Ø ÓÒ Ó Figure 1: A partial action system representation. An action system is an iterative composition of actions. It has the form shown in Figure 1 [14]. Here, the interface list defines the global variables through which communicates with other systems. The var and constclauses define the local variables and constants, visible only within. The expressions clause defines shorthand notations for some expressions used within. The items declared here are evaluated every time they are met in the execution of the system. The actions clause describes the atomic actions present in the system. A unique name is given for each action. An action can also be composed of, partly or completely, other actions defined in the actions clause. For instance: ½ ¾ µ. Here, the actions ½ ¾ are called included actions with respect to the action Atomicity means that whenever an action is selected for execution, it will be completed without interference. One atomic action may be a composition of other atomic actions, realized by using atomic operators, such as,, or. In the init clause, all the local and interface variables are initialized. In the case of the latter, special care has to be exercised, as these variables have to be initialized with the same values in all the systems that share them. The system s do-od loop contains a composition of the actions defined in the actions clause. The composition can be realized using the atomic operators 3

8 and and the macro operators such as the non-atomic sequential composition operator ; which is actually defined in terms of the non-deterministic choice ( ) and an auxiliary local variable. In the loop, one enabled action is executed at the time. Parallel behavior is modeled by two or more actions that are enabled simultaneously and can be executed in any order without affecting the result of the computation. Notation. A substitution operation within an action A is denoted by Ò Û ÓÐ where ÓÐ refers to an element (variable, predicate, component action etc.) of the original action, and Ò Û denotes the new element which replaces ÓÐ in. The same notation may also be used in connection with action systems. Composing action systems. The parallel composition of two action systems ½ and ¾, denoted ½ ¾, is defined to be an action system whose loop has the form do ½ ¾ od, where ½ and ¾ represent the action compositions within the loops of the constituent systems ½ and ¾, respectively. The composed system merges the global variables of the components keeping the local variables and action identifiers distinct. Quantified composition. Any composition operator can be quantified. This applies to the different compositions of actions and the parallel composition of action systems. The notation is defined as follows: [ ½ Ò µ ] ½ Ò [ ½ Ò µ ] ½ Ò Here the asterisk denotes any action constructor mentioned above. Note that in general the index variable does not have to run through a range of values. In this case, the set of values is defined explicitly, for example: ¾ ¾. The leftmost value is considered first, the rightmost value last. The actions µ are called parameterized actions, and, naturally, is the parameter. The same applies also for the action systems in the second definition above. The action and the action system are called template action and system, respectively. For every quantified composition, one has also to specify what the parameter stands for, in the representation of the template action / system. In the descriptions of section 4, for instance, the parameter related to the template of a master system is used to identify a communication channel. The behavior of a given action represents the manner in which the action updates its variables. The behavior of a system is described in the system s do od loop and it is a composition of the behaviors of the involved actions. 4

9 3 Bus Components and Communication Protocols A bus is a data communication connection between two or more communicating devices. They provide a cost effective way to organize data transfers within a large chip (SOC) or between physically distinct devices, which may include the CPU, main memory, and I/O devices. Data, addresses and control signals build up a bus structure. The components of a concrete bus-based system can be described as masters, slaves and arbiters. A master is a system that will request services from other systems connected to the bus, the slaves. Only one master at a time may transfer data on the bus, thus there is need for arbitration. The arbitration scheme may be distributed or centralized: In a distributed organization, such as a SCSI bus [2], all the potential initiators of a transaction must agree on the next owner of the bus, following certain priority schemes. In the centralized approach, one uses a central unit that acts as the arbiter. The master devices request the bus, and the arbiter grants the bus to only one device at a time. This requires dedicated request and grant wires between each device and the arbiter. The studies presented in [1, 5, 15] fall into this category. In this section, we describe the variables and communication protocols that we use to model an asynchronous bus inspired by the AMBA AHB [1], supporting up to 16 bus masters. The interface between the bus components in our approach is shown in Figure 2. The actual Action System specifications of the components are presented later in Section 4. We already opted then for a centralized arbitration scheme. A distinct system in our representation will implement the functionality of the arbiter which decides what master will be granted the ownership of the bus. The components of a bus-based design communicate through different channels that implement the control signals. Data is exchanged on the common data bus. Communication protocols. In a synchronous implementation, the clock signal synchronizes the access to the bus of all the elements of a design. Timing aspects are of high concern, but the presence of the global clock simplifies the transfer protocols. The asynchronous realization of the bus introduces more complex communication protocols than the synchronous one, mainly due to the fact that the participants to a given transfer have to know when data is actually ready to be either read or written. Hence, in asynchronous communication the active party sends a request signal to the passive party, which then responds by sending back an acknowledgement signal after completing the requested task. We build then a simple communication channel consisting of a variable with values in the set 5

10 schan HWRITE mchan[j] bsize[j] HSPLIT Master HMASTLOCK Arbiter HMASTER Slave HADDR dbus HRESP Figure 2: System interconnections. Ö Õ. We will use in the following both this type of channel in the master - slave communication protocol and a more complex channel in the master - arbiter communication protocol. Master - Arbiter communication. The communication between the bus controller and every master in the system is realized by means of a set of signals [1]: HBUSREQx Bus request signal. Emitted by the master. HLOCKx Locked transfers request from the master. HGRANTx Bus grant. Emitted by the arbiter, in response to a request. We group the above signals in a channel defined as Ñ ÒÌ ÝÔ Ö ÖÐ Ö ÓÒ Ð where Ö corresponds to HBUSREQx, ÖÐ to HLOCKx and Ö to HGRANTx. Whenever a single transfer (possible a part from a burst transfer) completed, the master sets the channel to done. In the case when the master has been granted a locked access, signaled by a corresponding value (true) of the variable HMAST- LOCK, done is issued only in the case of a SPLIT or RETRY situation, otherwise the arbiter releases the channel when the whole transaction has been completed (the channel is set on idle). The value idle of the master - arbiter channel is also used to represent the situation when no master requests the access to the bus. Master-Slave communication. The master-slave communication channel is modeled by the variable schan of the type schantype req, ack. This is accompanied by the natural-type variables dbus and HADDR that model the data and address signals of the bus, the boolean variable HWRITE which specifies whether 6

11 the master is reading (HWRITE = false) or writing (HWRITE = true) data. The slave signals the status of the latest transaction by setting accordingly the variable HRESP: HRESP OKAY in case of a well terminated transfer. HRESP ERROR in case of a transmission error (for instance, write access to read only memory location, [1]). HRESP ¾ SPLIT, RETRY when the current request cannot be completed by the slave at the given moment. Once the access to the bus is granted by the arbiter, the granted master first sets the HWRITE signal, the slave address HADDR, and also data dbus if HWRITE = true indicating a write operation, and places the channel schan to req. The selected slave tries to execute the requested operation and assigns then an appropriate value to HRESP. If HRESP OKAY and HWRITE false indicating a successful read operation, the slave also assigns a valid value to dbus. Then it acknowledges the master s request by setting schan to ack. In the case of a successful read, the master stores the value of dbus set by the slave. If HRESP OKAY and HMASTLOCK true, i.e., a successful locked transfer event (write or read) took place, the master initiates immediately a new communication cycle with the slave as long as the burst has not yet been completed (bsize ¼). If the slave sets HRESP to ERROR as the response to a locked transfer event, it is up to the master to decide whether to continue the locked burst with the slave or to interrupt it by communicating with the arbiter. In the AMBA AHB specification, the slave may delay the transfer on the bus by making use of the HREADY signal. Basically, both the data and HRESP signal values are ignored, unless HREADY is high. Thus, the slave may insert wait states in the transaction flow. Due to the asynchronous communication protocol on the channel schan, the HREADY signal is not needed in our descriptions, as the master waits for the slave to set the channel schan to ack in every transfer event. Another difference is that our abstract model does not contain an explicit decoder which generates the slave select signals HSELx from the address HADDR as in the AMBA AHB specification. Instead, a slave itself performs this selection based on the value of the address variable HADDR which is shared by all the slaves. Arbiter - Slave communication. The interface between the arbiter and the slaves consists of the shared variables HMASTER, HRESP, and HSPLIT. The arbiter reports the number of the master that is currently accessing the bus by assigning this identification number to the variable HMASTER. The arbiter 7

12 reads the value of the variable HRESP which is set by a slave as a response to a transaction requested by the master accessing the bus. If HRESP SPLIT, the slave has decided to split the current transfer, i.e., to postpone a part of the transfer burst. In this case, the arbiter masks or disables the request signal of the master identified by HMASTER. When the slave is later ready to continue the burst with the masked master ( ¼ ½ ), it sets the boolean variable HSPLIT to true. The arbiter then responds by removing the mask allowing the master to access the bus again. If HRESP = RETRY, the slave wishes to retry the latest transaction with the master HMASTER. The arbiter gives the bus to this master immediately, if there are no higher priority requests present. Overall Communication. Every master communicates with the arbiter by a distinct single channel of the type mchantype. On the arbiter side, there may be up to sixteen channels of this type, each corresponding to a different master. The arbiter may assign the control of the bus to other master only after the master currently owning the bus has signaled done on the channel. The communication is initialized by any master that whishes to get access to the bus by placing its own channel of the type mchantype on either Ö or hrl. Eventually, the control of the bus is passed by the arbiter to this requesting master, by changing the value of the channel to gr. Now the master delivers data on the address and / or data bus, changes the value of the slave communication channel to req and waits for the slave to accomplish the request. In any of the above situations characterized by a certain value of HRESP, the master places the master channel on done and the control is passed to the arbiter. If a higher priority master is requesting the bus, the arbiter has now the possibility to pass the control to this new master. If there is no such a request and the original size of the transfer has not been yet reached (bsize ¼), the arbiter again sets the master channel to gr and the transfer process restarts with a new transaction. If the master has been granted a locked access to the bus, the arbiter only checks for termination of the transfer (bsize) and the bus remains granted if the transfer is not yet completed and there is no RETRY or SPLIT answer from the slave. Types and variables. Next to the already mentioned types mchantype, schan- Type, several other types can be defined so that we can have a good representation of the variables used to model the different kinds of data and control signals present in the specification of the bus. Some of the variables appearing in our descriptions have the same name as the ones originally described in the AMBA bus specification, such as HMASTER, HMASTLOCK, HADDR, etc. However, the type of these variables might be adapted to the specific level of our representations, as described in the following. 8

13 Masters and slaves. The bus controller, after granting the bus to a specific master sets HMASTER to the appropriate value, to indicate which master owns the buses. The variable HMASTER is an integer, ranging from 0 to 15. The slaves identify themselves by a local variable SlaveId. As we do not specify even a maximum number of possible slaves in the system, we consider SlaveId as an integer ranging from 0 to a generic value of NrSlaves. The response from the slave comes, as described earlier, in the value of the variable HRESP. We have: HRESP SlaveResponseType SlaveResponseType {OKAY, ERROR, RETRY, SPLIT } Communication variables. Each master accesses a single variable of the type MchanType, called mchan. At the level where we have the overall description of the whole system, the arbiter collects all mchan variables from every master in the system in the vectored variable with the same name, and the dimension given by the number of masters in the system. In the descriptions presented in section 4, we have mchan ½ mchantype, which means that we have 16 masters in the system. The same is valid when discussing the variable bsize, which represents the number of transactions to performed, once a master gained the control of the bus. Within the master description, this is defined as a natural number, ranging from ¼ to ½. When the whole system is considered, we have to assign a different bsize variable for each master, therefore, at this level, bsize is a vector variable. Address bus. The (32) address lines carry both the information about the data to be processed and the information used to select the appropriate slave. We model this element of the system as a natural, HADDR : natural. This allows us to avoid complex referrals to the elements of a vector, in case the address bus would have been modeled as a vector of bits, for instance. Every slave can read the address bus and check if the latest granted master has selected him as the target slave. This is performed by comparing the own ID with a value extracted from the value of the HADDR variable: SlaveId = HADDR / 2 ¾ Æ, where ¾ Æ is the number of slave systems present in the design. Data busses. There are two data buses in an AMBA based system, used for writing or reading purposes. At the initial level of our representations we may model both of them as a single data bus dbus, accessed in either modes. Further, as the width of the bus is not fixed, we prefer to represent it as a natural type variable, too: dbus: natural. All the masters and the slaves present in the system share the variables HRESP, schan, HADDR, dbus. 9

14 4 Specification In this section we describe the representation of the three elements composing a possible system: masters, slaves and the arbiter. We do not describe in detail any of these systems. Instead, they are to be considered as templates one would use to construct a concrete system. The overall description of the whole system: masters, slaves, arbiter is given by the following composition, where we already took into account the representations of the bus components, as described in the forthcoming sections: Ö Ø Ö ¼..½ Å Ø Ö Ñ Ò Þ Ñ Ò Þ ¼..ÆÖËÐ Ú ËÐ Ú ËÐ Ú Á 4.1 The Master A master is the system requesting services from any / some slave systems. The request, however, has to be granted not only by the slave itself, but also by the arbiter, due to the employment of shared busses. In the following, we describe a template that can be used to describe a master system. The action systems representation is shown in Figure Actions composing the Å Ø Ö system Action Å ½ This action represents the request for the bus, from the master to the arbiter. This can occur only when the private channel to the arbiter, mchan has the value idle. First, the master sets the characteristics of the transfer it wants to perform, such as the size of the transfer (bsize), the write / read access mode (the local variable write) and it also establishes which slave it wants to address (the local variable ssel). The values of this local variables are to be assigned to the interface variables HWRITE and HADDR when the access to the bus has been granted (action Å ¾ ). After this, the master starts requesting the control of the bus, either in a simple" or in a locked manner: mchan := m.m ¾ hr,hrl. Action Å ¾ Once the access to the bus is granted (mchan = gr) the master assigns the interface variable the appropriate values. In case it asks for a write mode transfer, it also places the data bus to an arbitrary natural value (dbus := db.db ¾ natural). At the end, it sets the communication channel to the slave on req and waits for the slave answer. Observe that the address variable HADDR is locally composed of two parts (two local variables): ssel and addr. The reason for this is that when starting 10

15 Ý Å Ø Ö Ñ Ò Å ÒÌ ÝÔ Ò Ë ÒÌ ÝÔ Þ Ò ØÙÖ Ð ¼º º½ ÀÅ ËÌ ÄÇ Ã ÀÏ ÊÁÌ ÓÓÐ À Ê Ò ØÙÖ Ð ¼º º¾ ¾ ½ Ù Ò ØÙÖ Ð ÀÊ ËÈ ËÐ Ú Ê ÔÓÒ Ì ÝÔ µ Ú Ö Ø ÓÒ Ñ Ñ Ð Ö Ò ØÙÖ Ð ÛÖ Ø ÓÓÐ Å ½ Ñ Ò Ð ÛÖ Ø Þ Ð Û Û ¾ ÓÓе ½ ½ µ ¼ ¾ Æ ½µ Ñ Ò Ñ Ñ ¾ Ö ÖÐ Å ¾ Ñ Ò Ö ÀÏÊÁÌ Ö ÛÖ Ø ¼ ¾ ¾ Æ ½ À Ê ¾ ¾ Æ Ð Ö ÀÏÊÁÌ Ù ¾ Ò ØÙÖ Ð ÀÏÊÁÌ Ôµ Ò Ö Õ Å Ò ÀÊ ËÈ Çà ÀÏÊÁÌ Ñ Ñ Ù ÀÏÊÁÌ Ôµ Þ Þ ½ ÀÊ ËÈ ÊÊÇÊ Þ Þ ½µ ¼µ ÀÊ ËÈ ¾ ËÈ ÄÁÌ Ê Ì Ê Ôµ Å ÀÅ ËÌÄÇ Ã Þ ¼µ ÀÊ ËÈ ¾ ËÈ ÄÁÌ Ê Ì Ê µ Ñ Ò ÓÒ ÀÅ ËÌÄÇ Ã Þ ¼µ ÀÊ ËÈ ¾ ËÈ ÄÁÌ Ê Ì Ê µ Ôµ Å Å Å Ò Ø Þ Ñ Ñ Ð Ö À Ê Ù ¼ Ñ Ò Ð Ò ÛÖ Ø ÀÅ ËÌ ÄÇ Ã ÀÏ ÊÁÌ Ð ÀÊ ËÈ ÇÃ Ó Å ½ Å ¾ Å µ Ó Figure 3: The Asynchronous Master Specification. a new transaction of a burst transfer, the master should not compute again the address of the slave (represented here by the variable ssel) but only the effective address part (represented by the variable addr which is assigned a new value in this action). Thus, the variable HADDR is a concatenation of the two local variables, computed every time the master is granted the access to the bus. Action Å This action describes how the master updates the variable bsize after the slave finished one transaction, signaled by the value ack of the corresponding communication channel (schan = ack). The decision is done based on the value of the variable HRESP: HRESP OKAY means that the transfer finished with no problems. If it was a read mode access ( HWRITE) some local memory variable mem is assigned the value of the data bus. Then the remaining number of transactions is decreased (bsize bsize - 1). If HRESP ERROR the master may decide either to continue with the following transaction (modeled by a decrement of bsize), or to renounce the control of the bus (modeled by setting bsize to 0). In the situation when HRESP ¾ RETRY, SPLIT, the value of bsize remains unchanged, as the master, which may loose the access to the bus if 11

16 HRESP RETRY and it certainly losses it if HRESP SPLIT, has to keep on requesting the bus in order to finish the whole transfer, as specified by the initial value of bsize. Action Å After deciding on the new value of the bsize, the master has to signal to the arbiter the completing of a transaction. If the master has been granted a locked access, the channel to the arbiter is set to done only at the end of the whole transfer (bsize = 0), or in case a RETRY or a SPLIT response was received from the slave. The channel may also be assigned a value of done if the master has a nonlocked access and the slave answered with an OKAY or an ERROR response. Action Å This last action of the system Å Ø Ö specifies that the action Å follows the action Å in an atomic manner. 4.2 The Arbiter In this section, we concentrate on the representation of the bus controller, which we assimilate to the system Ö Ø Ö (Figure 5). The original AMBA bus specification is shown in Figure 4. Notice that there are several differences between our approach and the arbiter in Figure 4. Some of them come, naturally, from the different design style, asynchronous vs. synchronous, others because we describe the systems at a higher level of representation: The absence of the clock signal. The bus request and grant lines are collected in the same channel variable mchan, as described in section 3. The selection of the requested slave is done by the AMBA arbiter. In our descriptions this is left as a local decision of the slave, as explained in section 4.3. Thus, in Figure 2 the Ö Ø Ö system does not access the address lines (the variable HADDR). Similarly with the HREADY signal (section 3) we also do not make use of an HTRANS signal, which would characterize the type of transfer requested by the master. Part of the utility of this signal is passed to the master - arbiter communication channel (the idle value of the channel), part of it is not necessary (as it is a non-clocked communication, the master does not have to insert wait states). Also, as we do not describe wrapped transfers, the other values of HTRANS are not used. The signal HBURST is replaced in the Ö Ø Ö by the variable bsize, assigned by the master claiming ownership. 12

17 From the slave response signal HRESP, our arbiter only takes in the RETRY and the SPLIT signals. A re-arbitration is required in the case of a split operation, while this may also appear after a RETRY has been issued. Figure 4: AMBA AHB Arbiter. In the following, we analyze the behavior of the system Ö Ø Ö, by describing the behavior of its actions. In the actions clause of the system we specified six actions. The notation also provides a generic aspect, illustrated by the action parameters and. We describe the behavior of the controller with respect to a single master, and the parameters help generalizing, so that we cover all the other masters. In the following, we refer to the system s actions without mentioning the parameters. Action Grant. This action is responsible for granting the bus ownership to a master requesting it (mchan ¾ hr, hrl ), while the module is not masked, or it received an HSPLIT update ( mask HSPLIT ) and the bus is not reserved. Consequently, the bus is granted, not before updating the system with the right information concerning the current master and the mask value. It is important to notice the reservation of the bus (reserved := true) which means that until there is a done signal from the owner of the bus, no other grant may be issued, and the permission given to other masters of the same priority to take the bus, in the future (disable[j] := false). Action ChkResp. The second important action is the arbiter models the answer of the controller following the different possible results communicated by the operating slaves. The behavior is constructed on the included actions, Split, Retry and Ok_or_Error. The communication variable mchan is updated correspondingly 13

18 in each situation characterized by a given HRESP value. At the end, the bus is no longer reserved (reserved := false) and it may be granted to another requesting master (the previous owner included). Action Split. The slave may decide to not answer immediately to the request coming from the current owner of the bus. We modeled this by assigning an arbitrary value to the slave s local variable busy (Figure 6). If the slave issues a SPLIT answer to the request of the master, the arbiter then inhibits the master from taking part in the arbitration process by setting the corresponding mask element to false The value of every mask element is checked in the action Grant. Whenever the slave decides to allow the master to (re)start the operations, it informs the arbiter by setting the corresponding element of the HSPLIT vector to true This is also checked by the action Grant. If the slave is ready to resume a previously split connection, then the mask is updated next time the specific master obtains the access to the bus. Ý Ö Ø Ö Ñ Ò ½ Å ÒÌ ÝÔ ÀÅ ËÌ Ê Ò ØÙÖ Ð ¼º º ½ ÀÅ ËÌ ÄÇ Ã ÀËÈ ÄÁÌ ½ ÓÓÐ Þ ½ Ò ØÙÖ Ð ¼º º ½ ÀÊ ËÈ ËÐ Ú Ê ÔÓÒ Ì ÝÔ µ Ú Ö Ñ ½ Ð ½ Ö ÖÚ ÓÓÐ ÓÒ Ø ¼ ¼ ½ ¾ ½ ½¼ ½½ ¾ ½¾ ½ ½ ½ ÜÔÖ ÓÒ Ò Ð µ ¾ Ò Ð µ Ø ÓÒ Ö ÒØ µ Ñ Ò ¾ Ö ÖÐ µ Ñ ÀËÈ ÄÁÌ µ Ò Ð µ Ö ÖÚ ÀÅ ËÌÄÇ Ã ÀÅ ËÌ Ê Ñ Ò Öе Ñ Ö ÖÚ ØÖÙ Ð Ð Ñ Ò Ö Ê Ô µ Ñ Ò ÓÒ ËÔÐ Ø µ Ê ØÖÝ µ Ç ÓÖ ÖÖ µµ Ö ÖÚ Ð ËÔÐ Ø µ ÀÊ ËÈ ËÈ ÄÁÌ Ñ Ð Ê Õ µ Ê ØÖÝ µ ÀÊ ËÈ Ê Ì Ê Ð ØÖÙ Ê Õ µ Ç ÓÖ ÖÖ µ ÀÊ ËÈ ¾ Çà ÊÊÇÊ Þ ¼ Ð ØÖÙ Ê Õ µ Þ ¼ Ñ Ò Ð Ê Õ µ ÀÅ ËÌÄÇ Ã Ñ Ò Ö ÀÅ ËÌÄÇ Ã Ñ Ò ÖÐ Ò Ø Ñ ØÖÙ ÀËÈ ÄÁÌ Ð Ö ÖÚ ÀÅ ËÌ ÄÇ Ã Ð Ñ Ò Ð ÀÊ ËÈ ÇÃ Þ ÀÅ ËÌ Ê ¼ Ó ¼º º ¾ ¾ Ö ÒØ µ Ê Ô µµ Ó Figure 5: The Asynchronous Arbiter. Action Retry. Similar with the above action Split, this action, by assigning Ð true, does not allow any other master from the same priority group with the current owner of the bus to gain access. If there is no higher priority master requesting, 14

19 the ownership of the bus will remain to the current master. Action Ok_or_Error. From the point of view of the arbiter, an OKAY or an ER- ROR answer from the operating slave bears the same significance. The decision in an erroneous situation is taken by the master (action Å, Figure 3). The arbiter only checks on the value of the corresponding bsize element and either puts the specific channel on idle, or continues in a normal manner, updating also the corresponding element of the disable vector. Notice the usage of the local variable (disable) in both actions Retry and Ok_or_Error. In these situations (when the slave answered with an OK or a RETRY), if there is no higher priority master requesting the bus, only the current owner may get the bus. A false value of the variable disable[j], for a given, means that the corresponding master does not hinder another master in the same priority group to request and obtain the ownership of the bus. A value of true for the same variable signals that the current master ( ) finished one transaction which ended with either an OK or an RETRY answer, and no other same priority master may take the ownership in this round of arbitration. Global behavior. The behavior of the arbiter is described further by the composition ¼ ¾ ¾ Grant µ ChkResp µµ The actions within the innermost quantified composition deal with masters coming from the same priority group. The outermost quantified composition describes the priority scheme. 4.3 The Slave In this section we describe a very abstract specification of a slave, as presented in Figure 6. Thus, this slave either reads the data bus and saves the data in a local variable (mem) or does the reverse procedure, that is, it writes on the data bus the content of the local variable mem. This operation depends on the HWRITE flag signaled by the master that controls the bus and requests the services of this slave. We identify the slaves in the overall system by the variable SlaveId, which ranges from 0 to a maximum number, MaxSlaves. If this identifier s value equals HADDR / 2 ¾ Æ, decoded from the address lines, the slave is activated. Every slave communicates with the master that controls the bus by means of the channel schan. The slave describes the way in which a certain transfer completed through the variable HRESP. This is set to a new value after the slave has either read or written the data bus (dbus) and before placing the channel schan to ack. In our modeling, we assign an arbitrary value to the variable HRESP. In case of a split operation (HRESP SPLIT), the slave has to save the information on the current master, so that it can resume the operation at a later moment. We model this by introducing the local variable MastQ, a sixteen boolean element vector. The index of an element represents one of the masters of the system (iden- 15

20 tifiable from the value of the variable HMASTER). A value of true means that the slave has split a transfer initiated by the corresponding master. Once a transfer was split, the arbiter masks the request line of the master currently accessing the bus and gives the control to another master requesting access. Whenever the slave decides it can resume a split transfer, it sets the corresponding element of the MastQ variable to false and it places the index as the HSPLIT signal. The arbiter will unmask the request line of the corresponding master. Ý ËÐ Ú À Ê Ò ØÙÖ Ð ¼º º¾ ¾ ½ ÀÅ ËÌ Ê Ò ØÙÖ Ð ¼º º½ Ù Ò ØÙÖ Ð Ò Ë ÒÌ ÝÔ ÀËÈ ÄÁÌ ½ ÀÏ ÊÁÌ ÓÓÐ ÀÊ ËÈ ËÐ Ú Ê ÔÓÒ Ì ÝÔ µ Ú Ö Ñ Ñ Ò ØÙÖ Ð Å ØÉ ½ Ù Ý ÓÓÐ ÓÒ Ø ËÐ Ú Á Ò ØÙÖ Ð Ø ÓÒ Ë ½ Ò Ö Õ ËÐ Ú Á À Ê ¾ ¾ Æ Ù Ý ÀÏ ÊÁÌ Ñ Ñ Ù ÀÏ ÊÁÌ Ù ¾ Ò ØÙÖ Ðµ Ù Ý Ôµ Ù Ý ¾ ØÖÙ Ð Ë ¾ Ù Ý ÀÊ ËÈ Å ØÉ ÀÅ ËÌ Ê ËÈ ÄÁÌ ØÖÙ Ò Ø Ó ÀÊ ËÈ Ê Ì Ê µ Ù Ý ÀÊ ËÈ ¾ Çà ÊÊÇÊ Ë Ë ½ Ë ¾ Ò Ë Å ØÉ µ ÀËÈ ÄÁÌ Å ØÉ ØÖÙ Ð Å ØÉ ÀÏ ÊÁÌ ÀËÈ ÄÁÌ Ù Ý Ð Ò Ñ Ñ À Ê ÀÅ ËÌ Ê Ù ¼ ÀÊ ËÈ ÇÃ Ë Ë Ó Figure 6: The Asynchronous Slave Specification Actions composing the ËÐ Ú system Action Ë ½ The first action of the system describes the operation of the slave whenever there is a request from the bus controller. Thus, this is performed when schan = req and the request is sent to this slave (SlaveId = HADDR / ¾ ¾ Æ ). The slave updates either the local memory variable to the value of the data bus, or the opposite, depending on the value of HWRITE. Action Ë ¾ The mode in which the transaction completed is signaled by the variable HRESP. In here, we assign to HRESP an arbitrary value from the set {OKAY, ERROR, RETRY, SPLIT }. Action Ë If the slave is splitting the transfer, then the number of the master (HMASTER) indicates which element of the MastQ is set to true. 16

21 Action Ë After the response has been established and the possible split situation properly indicated, the slave is sending acknowledge to the master, by setting schan ack. This action is an atomic composition of the previous actions, plus the assignment to the variable schan. Action Ë The last action of the system describes the resuming of a previously split operation. The variable HSPLIT takes the value of one of the indices of the vector MastQ, for which the value evaluates to true. While this assignment may also be subject to a priority mechanism, for our descriptions we allow an arbitrary selection of the master ID. The action Ë has lower priority than Ë, as specified by the prioritized composition. This means that first the slave has to try serving the master that currently controls the bus (even if by issuing a SPLIT signal), and only if there is no such request, it may try to reactivate a split transaction. 5 Discussion 5.1 Bus Access In the original AMBA bus specification [1] the bus is governed by a global clock. All the transfers relate to this signal, which synchronizes the data transfers and the control lines. In the previous sections we described an asynchronous approach to bus control. Instead of the clock signal we introduced communication channels that identify the moments when data or control signals are valid on certain lines. The transfers allowed on the synchronous bus are not only limited in size, but also, based on the clock frequency, in time. Thus, a sixteen-bit transfer can be realized in sixteen clock cycles if the master that controls it receives no interruption. Knowing the clock frequency, one can establish a period of time in which a normal executed transfer takes place. In the asynchronous representation, even though the transfer size is also limited, one cannot be certain of the time period in which a sixteen-word transfer, for instance, is completed, in an uninterrupted execution. Even though, at this level of the description, the period of time in which a certain master controls the bus was ignored, we can also think of means by which one can control this aspect of the arbitration. For instance, a local synchronous counter can be attached to the arbiter so that it monitors, in steps that can be related to the actual time of the processing, the actual time a master has been accessing the bus. Another solution could be the employment of a specific master, which would implement the same counter. This master would have the highest priority in the system, and thus, could interrupt the access to the bus of any other master. By not addressing any slave, the interrupt requests sent by this master cannot be 17

22 masked by a possible split or retry operation. 5.2 Refinement issues The abstract bus specification, given above as an action system description, is intended to be developed into a hardware-realizable model in a stepwise manner using Refinement Calculus-based [3] transformation rules. Such a disciplined design flow yields a concrete system model which is a logically correct implementation of the initial abstract specification, satisfying possibly a set of auxiliary logical constraints which are necessary for successful circuit implementation. This lays a solid ground for the technology mapping process, where the final formal description is transformed into a layout of actual circuit components. The Action Systems-based formal design flow of an asynchronous system contains four main phases [11]. In the initial derivation, the initial specifications of the bus arbiter, and the involved masters and slaves are further decomposed or partitioned into parallel compositions of action systems each of which describes some essential functional aspect of an original system component. Each decomposition step is a refinement, where a new asynchronous communication channel is created between the separated parties. The majority of the introduced channels are local to the system components, which means that they do not change the bus itself. However, some transformations may involve the bus as well. For example, if the address decoding operation is extracted from the slaves, a new global control block is created for the bus. Splitting the variable dbus, which models the data bus between the masters and slaves, into two separate variables modeling write and read buses is an example of another kind of global refinement. Notice that if a master or a slave is intended to be implemented as a synchronous circuit, we can choose to model it as a synchronous action system [13] from the beginning. Decomposing such a system creates synchronous communication channels rather than asynchronous ones. The other possibility is that we first model each bus master or slave as an asynchronous system, and transform it into a synchronous form after the decomposition. The initial derivation is followed by the handshake expansion, a non-trivial data refinement [3], where the description is brought closer to the circuit level by implementing each abstract communication channel with a set of boolean variables. As an example, let us consider a master-arbiter channel mchan which has five possible values { hr,hrl,gr,done,idle }. We can implement it using 5 boolean handshake variables or signals, say Ö, ÖÐ, Ö, done, and next. They are related to the 18

23 original variable by the relations Ê ½ Ñ Ò Öµ Ö ÖÐ Ö ÓÒ Ò Üصµ Ê ¾ Ñ Ò Öе Ö ÖÐ Ö ÓÒ Ò Üصµ Ê Ñ Ò Öµ Ö Öе Ö ÓÒ Ò Üصµ Ê Ñ Ò ÓÒ µ Ö Öе ÓÒ µ Ö ÖÐ ÓÒ µµ Ö Ò Üص Ê Ñ Ò Ð µ Ö ÖÐ Ö ÓÒ Ò Üص Hence, the resulting communication channel is considered idle when all of its handshake variables are false (Ê ). The channel is put to a request state, when the master sets either Ö or ÖÐ to true, or when the arbiter decides to remove grant by setting the grant signal Ö to false and asserting the next signal (Ê ½, Ê ¾ ). The arbiter puts the channel to the grant state by setting Ö to true as the response to the asserted request Ö or ÖÐ, or by setting the variable next to true as the response to the asserted ÓÒ signal while keeping Ö true (Ê ). The done state indicates that the master has set either the variable done to true or the request Ö or ÖÐ to false (Ê ). In the former case, the master has just transmitted or received a data word, but the burst has not yet been completed. In the latter case, the last data of the burst has just been transmitted or received, which means that the arbiter can put the channel to the initial idle state. In Figure 7, we illustrate the correspondence between the abstract channel and the refined, concrete one. The figure however, is a simplified representation, as it does not include the ÖÐ value of the abstract channel. The design flow continues, after the transformation of the communication channels, with the circuit extraction, where the formal description of each system component is stepwise refined into a concrete description from which an actual circuit implementation can be easily derived. This means that an asynchronous unit is derived into a speed-independent action system [11] which satisfies a set of logical constraints that make a stable self-timed circuit implementation possible. A unit described as a synchronous action system, in turn, is derived into a form which corresponds to a synthesizable register-transfer-level hardware description language (HDL) model. The Action Systems-based design flow ends with the implementation or technology mapping step, where an asynchronous speed-independent action system is refined into a composition of primitive action systems each of which corresponds to an actual circuit component in a component library available to the designer. A synchronous action system, in turn, can be compiled into a synthesizable HDL model which is then mapped onto some component library using an available synthesis tool. Observe that the design flow becomes more fluent, if our component library contains abstract action system models for large circuit components that have been 19

24 verified formally beforehand. For example, we could have an entire bus master or slave, or a significant part of it, as a single library component. Furthermore, once the shared bus controller (arbiter) has been designed from an abstract specification to the circuit implementation, it is placed in a library and re-used from there. Then the design flow of a system built around the bus discussed in this paper consists mainly of the initial derivation phase, where the abstract models of the pre-defined library components are stepwise extracted from the initial system specification. If our library contains for each complex component, in addition to the final circuit implementation, several action system models, each corresponding to one abstraction level or design phase in the design flow, the last 3 derivation steps (handshake expansion, circuit extraction, implementation) become straightforward. We just replace a pre-defined action system model of a component with a more concrete pre-defined action system model, and finally we replace the most concrete formal models with the corresponding circuit implementations. hr* gr* done* next* idle # hr # gr # done # concrete -* channel components # abstract - channel components Figure 7: The transformation of the channel mchan. 6 Conclusions We presented in this study a formal representation of an asynchronous bus structure. It originally started with the intention to describe an asynchronous AMBA bus, which, in comparison with similar approaches to bus modeling [5, 15], seemed to be a less complex structure. Due to the specifics of the asynchronous architecture the descriptions, the modeling eliminated several characteristics of the original AMBA structure. Some of the common aspects are the centralized arbitration, the split transfer features and the selection of the slave. Some details of the AMBA 20

25 specification are abstracted away in our presentation, only due to the higher level of description. This is the case with the data bus, the communication channels and aspects of the slave selection. One of the purposes of this study was to integrate the analyzed bus structure into our formal framework for digital hardware design as a means of allowing different devices to communicate and exchange data. By representing the bus in the same framework with the other systems in a design process, we have the possibility to apply the same techniques on both the systems modeling the digital hardware devices and the systems describing the underlying connectivity. The (successive) transformations one needs to perform in order to bring the descriptions of these systems to more concrete levels are executed in the formal framework of Action Systems, thus ensuring a correct derivation process. As an example, we described the transformations applied to the communication channel mchan in order to bring its representation at a lower level, where physical interconnection lines can be identified in the description. We can apply the same technique in order to bring the representation of the slave channel schan closer to hardware implementation levels. We provided templates for the components to be included in bus-oriented design architectures. There is no specification on the internal architecture of these devices, as they may be either synchronous or asynchronous implementations. There are several other aspects of bus design that are subject to subsequent studies. For instance, we did not specify, yet, how the arbiter may terminate the ownership of the bus in case of a prolonged access, although we offered some possible scenarios. An immediate follower of this work can start with the analysis of the other possibilities offered by the original AMBA specification, the System Bus (ASB) and the Peripheral Bus (APB). References [1] ARM Limited. AMBA Specification (Rev 2.0), [2] American National Standards Institution. Small Computer System Interface (SCSI), [3] R. J. R. Back and J. von Wright. Refinement calculus: A Systematic Introduction. Springer. April [4] W.J.Bainbridge. Asynchronous System-on-Chip Interconnect. PhD. Thesis, University of Manchester, UK, [5] W.J.Bainbridge and S.B.Furber. Asynchronous Macrocell Interconnect Using MARBLE. In Proceedings of the Ø International Symposium on Advanced Research in Asynchronous Circuits and Systems (ASYNC 98) San Diego, CA, March 30 - April 2, [6] E. W. Dijkstra. A Discipline of Programming. Prentice-Hall International, [7] J. C. Ebergen, J. Segers, I. Benko. Parallel Program and Asynchronous Circuit Design. Asynchronous Digital Circuit Design, G. Birtwistle and A. Davis (eds.), Springer,

26 [8] J.D. Garside et All. AMULET3i - an Asynchronous System-on-Chip. Proceedings of the Ø International Symposium on Advanced Research in Asynchronous Circuits and Systems, Eilat, Israel, 2-6 April [9] J. Hooman. Verifying Part of the ACCESS.bus Protocol using PVS. Proceedings 15th Conference on the Foundations of Software Technology and Theoretical Computer Science, LNCS 1026, Springer-Verlag, pages , [10] A. Mokkedem, R. Hosabettu, M. D. Jones, G. Gopalakrishnan, Formalization and proof of a solution to the PCI 2.1 bus transaction ordering problem. Formal Methods in Systems Design, vol. 16, no. 1, pp , January [11] J. Plosila. Self-Timed Circuit Design - The Action Systems Approach. Ph.D. Thesis, University of Turku, Dept of Applied Physics, Turku, Finland, [12] Colleen Purtell-Tappen. Platform Express to Accelerate Platform-Based System-on-Chip Design and Verification. ECN Magazine, September [13] T. Seceleanu. Systematic Design of Synchronous Digital Circuits. Ph.D. Thesis, Abo Akademi, Turku, Finland, [14] T. Seceleanu, J. Plosila. Hardware Oriented Action Systems. Manuscript. To appear as Technical Report. [15] A. Zitouni et All. Design of an Asynchronous VME bus Controller for Heterogeneous systems. Dedicated Systems Magazine Q3 ( 22

27

28 Turku Centre for Computer Science Lemminkäisenkatu 14 FIN Turku Finland University of Turku Department of Information Technology Department of Mathematical Sciences Åbo Akademi University Department of Computer Science Institute for Advanced Management Systems Research Turku School of Economics and Business Administration Institute of Information Systems Science