Adding support for power management in OCP

In which the concept of interface disconnection is introduced and the OCP disconnect protocol is detailed as an implementation of this concept.

Introduction

According to Moore's law, System-on-Chip (SoC) devices are continually becoming more complex and integrating more components, enabled by the continuing size reduction of silicon technologies. On the other hand, power consumption does not follow the same reduction ratio due to increasing leakage in deep sub-micron technologies. Hence, new power management techniques are being progressively used within the SoC in order to reduce power dissipation as much as possible.

This paper exposes some of the new architectural problems that exist in today's complex SoCs involving power management techniques. The concept of interface disconnection is introduced as a possible solution and the OCP disconnect protocol is detailed as an implementation of this concept. Finally several examples of use in a power management framework are given.

Emerging problems

A typical SoC can be partitioned into several domains that can be managed more or less independently with respect to power management. Several power management techniques may be used such as lowering clock frequency, lowering voltage, gating the clock, switching to retention mode or switching off. This list is not exhaustive and power management techniques are not the focus of this paper. However, one must realize that with some of these techniques, the affected components are not responsive to any input. At most, signals from a component in such a state can be forced to a pre-defined value thanks to a clamp technique. Such states will be referred to as "sleep" states in the rest of this paper.

On the other hand, the Open Core Protocol (OCP) defines a point-to-point fully synchronous interface protocol that can be used as an internal communication method. Figure 1 shows an example of a simple SoC with several power domains, using OCP for interconnection.

Figure 1: SoC architecture example

Putting a slave domain to sleep: A slave domain is a domain having at least one OCP slave interface at its domain boundary (e.g. D3, D4, D5). Before putting a slave domain to sleep, one must ensure that any OCP interface from another domain, connected to one of the slave ports of the domain, is in a state where all OCP transactions are completed (i.e. no outstanding transactions).

Not doing so can result in various SoC malfunctions. If a slave domain is being put to sleep while another domain is sending transactions to it, then the corresponding master (possibly the interconnect) will likely become stuck on its OCP master port. If a slave domain is asleep and some transactions to it are not completed, then the corresponding master will also become stuck due to lack of response. In both cases, there is no easy way to recover from such a situation. Note also that these malfunctions may propagate upstream from the interconnect toward the master initiating the transactions, ultimately resulting in a major failure.

Putting a master domain to sleep: A master domain is a domain having at least one OCP master interface at its domain boundary (e.g. D1, D2, D3). Before putting a master domain to sleep, one must ensure that any OCP interface to another domain, connected from one of the master ports of the domain, is in a state where all OCP transactions are completed (i.e. no outstanding transactions).

Not doing so can again result in various SoC malfunctions. If a master domain is being put to sleep while sending a transaction then the corresponding slave (possibly the interconnect) will likely become stuck or even corrupted. If a master domain is asleep and some transactions are not completed, then the corresponding slave will also likely become stuck. In both cases, as is the case for slave domains, there is no easy way to recover from such a situation. Note also that these malfunctions may propagate downstream from the interconnect toward the slave target of the transactions, again resulting in a major failure.

It might be thought that software could be relied upon to guarantee the necessary condition is true before performing a sleep transition. However, in complex SoCs with multiple masters and a complex interconnect, it would be very difficult for software to monitor transaction completeness. Also it is possible that some masters are totally independent of software. A debug master IP is in this category.

Traffic towards a sleeping slave domain: Once a domain has been properly put to sleep, another concern is that some masters may still be able to send transactions towards this domain. Such transactions will likely induce the same kind of disorder as exposed in the previous section: master or interconnect becoming stuck. For the same reasons as above, software cannot be relied upon to guarantee that no master will send transaction to a sleeping domain.

Bridging: An OCP-to-OCP bridge may exist between a master and a slave. Its purpose could be to adapt different clocking rates or different socket characteristics between a master and a slave. The bridge could be fully synchronous or asynchronous. It could also include internal FIFOs to temporarily store transactions.

From an architectural point of view, such a bridge can be seen as a simple interconnect with one master port and one slave port. However, it will likely not have the same domain partitioning characteristics as a true interconnect IP: It may be part of the same domain as the master or the same domain as the slave, or could well be split over both domains (Figure 2).

Figure 2: SoC architecture example with OCP-to-OCP bridges

The safe conditions to perform a domain sleep transition where a bridge is involved depend on whether the bridge is located in the master domain, the slave domain or split across both. The exact conditions may be difficult to establish, especially in the case where the bridge is split across both domains.

From an architectural point of view, it is convenient to consider the bridge and the two OCP interfaces, master and slave, as a unique OCP socket, and apply similar conditions before performing a domain sleep transition. That is, a domain linked to another one through an OCP-to-OCP bridge can only go to sleep if:

  1. OCP transactions are completed on both OCP interface with master and slave (i.e. no outstanding transactions).

  2. The bridge is empty of transactions (the bridge is also said to be fully drained).

The Connection/Disconnection Concept

The problems described above imply the need for a new concept: connection and disconnection. Connection is a state where both sides are functional and where communication can happen normally. Conversely, disconnection is a state where no communication is possible. Additionally, the disconnection state must only be reached after a clean termination of the communication interface; with all outstanding transactions completed.

With these definitions, the disconnection state becomes a pre-requisite state for all OCP interfaces at a domain boundary before performing a domain sleep transition.

Connection or disconnection has to be negotiated between master and slave. Because by definition one cannot have communication with a module (slave or master) in a sleeping domain, there will be a hierarchy between the connection and disconnection states. The connection state will only be established if both sides agree to be connected. However, both sides can independently request and cause a disconnection.

As a consequence, a disconnection can be the result of three different scenarios:

  • Mutual disconnection request from both sides

  • Disconnection solely requested by a master

  • Disconnection solely requested by a slave.

In the first two cases, it can be assumed that the master does not need to communicate with the slave since the master is requesting disconnection. In the third case however, it may be that the master has new traffic intended for the disconnected slave. A simple case is when the master is actually an interconnect that is routing traffic from several system initiators. It is then necessary to specify the behavior of this master with pending traffic. This behavior will be referred to as the "alternate behavior" of the master port.

The OCP Disconnect Protocol

The OCP disconnect protocol is a new protocol implementing the above connection/disconnection concept. It is primarily targeted at the existing OCP-IP protocol and is specified as an optional add-on in version 3.0 (and above) of the OCP-IP standard. However, it can also be used for other communication interfaces, provided they have similar characteristics (one way, point-to-point interfaces).

Like the existing OCP protocol, the OCP disconnect protocol is a point-to-point protocol between master and slave. It is fully synchronous to the OCP clock, and its signals are registered, in order to ease timing closure at SoC level.

The protocol is based on the following principles:

  • Both master and slave have a vote for entering the connection state.

  • The slave vote is propagated to the master where the connection or disconnection transition is performed.

  • The master generates the actual connection status, which is propagated back to the slave. Transactions can only be issued by the master and only when in the connected state. The slave is also committed to handling transactions normally while in the connected state, independent of its own vote.

  • The slave also has the ability to temporarily stall the connect/disconnect transition being performed on the master side.

The voting mechanism allows implementation of the connection/disconnection concept as defined in the previous section: a connection is established only in the case of mutual agreement. Note that either side can change its vote at any moment without restriction.

It is advantageous to perform the connection or disconnection at the master side, because it allows the OCP-to-OCP bridge emptying/idling operation to be included as part of a disconnection, when such a bridge is present. It is assumed here that the bridge is knowledgeable about the OCP disconnect protocol and uses it for that purpose (see implementation examples). One consequence of having the connection or disconnection performed at the master side is that the master's vote is a piece of information that remains internal to the master. Only the slave's vote is propagated from slave to master.

The master generates the actual connection status and propagates it to the slave. The slave monitors this connection status to determine when it is safe to perform a domain sleep transition. The connection status permits a disconnection state initiated solely by the slave, to be distinguished from a disconnection state initiated by the master. In the case of a disconnection state initiated solely by the slave, the protocol supports an alternate behavior of the master port for new traffic intended for the disconnected slave.

Protocol signaling: Protocol signaling consists of three signals. Two one-bit signals from slave to master, and one two-bit signal from master to slave as illustrated in Figure 3.

Figure 3: OCP disconnect signaling

SConnect constitutes the slave's vote and SWait is a stall request from the slave. MConnect[1:0] is the actual connection status from the master. Table 1 details the semantics of all these signals.

Signal

Value

Description

MConnect[1:0]

(Driven by the master)

'b00

(M_OFF)

This is a disconnect state, requested by the master.

The OCP interface is cleanly stopped.

The alternate behavior is also cleanly stopped.

This is the default reset state.

'b01

(M_WAIT)

This is a transient state.

The OCP interface is cleanly stopped.

The alternate behavior is also cleanly stopped.

'b10

(M_DISC)

This is a disconnect state, requested solely by the slave.

The OCP interface is cleanly stopped.

The master alternate behavior is enabled.

'b11

(M_CON)

This is the only connection state.

The OCP interface is up and running. It can send transactions to the slave.

The alternate behavior is cleanly stopped.

SConnect

(Driven by the slave)

'b0

(S_DISC)

The slave is either requesting a disconnect sequence, or once disconnected, indicating it is unwilling to re-connect.

This is the default reset state.

'b1

(S_CON)

The slave is indicating a readiness to perform a re-connect sequence, or maintaining a connected state.

SWait

(Driven by the slave)

'b0

(S_OK)

Used to indicate to the master that transition to any new state is allowed.

This is the default reset state.

'b1

(S_WAIT)

Used to indicate to the master that it can only transition to the M_WAIT state. That is, the slave temporarily stalls the transition at the master side.

Table 1: OCP disconnect protocol signals

Master state chart: At the master side, a finite state machine is responsible for generating the OCP connection status. First of all, the interfaces between this FSM and the master's other internal components must be detailed.

It must have an interface with a local or distant controller, which can be part of what is commonly called the power manager. This delivers the master's side connection/disconnection vote as well as an internal stall condition equivalent to the SWait signal for the master side.

An interface with the OCP traffic initiator must also be present in order to control its activity. The OCP connection status is intimately tied to the OCP master port activity.

Similarly, an interface with the master port's alternate behavior must also be present in order to control its activity. In the same way, the OCP connection status is intimately tied to the master port's alternate behavior activity.

Table 2 defines the signals used for interfacing the OCP connection status FSM with master's internal components.

Signals

Description

MDiscReq

Master's connection/disconnection vote from local or distant controller

1: vote for OCP disconnection

0: vote for OCP connection

MWaitReq

Internal stall condition from a local or distant controller

1: OCP connection state can only transition to M_WAIT state (stall)

0: OCP connection state can transition to any new state

OCPStopReq

Request to control OCP master port's activity

1: Request OCP master port to be or remain stopped

0: Allows OCP master port to be active and initiate transactions

OCPStopAck

Acknowledge from OCP master port to OCPStopReq request

1: OCP master port is cleanly stopped (no outstanding transactions)

0: outstanding or incomplete transactions may exist

ALTStopReq

Request to control master port's alternate behavior

1: Request alternate behavior to be or remain stopped

0: Allows alternate behavior to be active and handle new traffic intended for the disconnected slave

ALTStopAck

Acknowledge from alternate behavior to ALTStopReq request

1: alternate behavior is cleanly stopped

0: alternate behavior may have on-going activity

Table 2: Interfaces with other components

Figure 4 gives a high-level view of the integration of the connection status FSM within the master module.

Figure 4: Master high-level architecture

The OCP master port is actually made up of three entities: the OCP traffic initiator, the alternate behavior and the connection status FSM. Figure 5 defines how the connection status is generated at the master side, interacting with the controller, the OCP traffic initiator and the alternate behavior.

Figure 5: Connection status FSM

This state chart deserves some explanation. It consists of four states. The green callout attached to each state defines the actions that are performed in each state (signal generation). Arrows and blue text define the transitions between states and their condition. Note that a minimum of two clock cycles are spent in the stable states (M_OFF, M_CON and M_DISC). This is to allow the slave to sample the current state and compute the next SWait value. This is a side effect of the registered output / fully synchronous timing requirement of the OCP disconnect protocol.

The red arrows inside the M_WAIT state are there to show that the M_WAIT state can be entered and exited simultaneously (i.e. transparent – no cycle spend) if an exit transition condition is true when the state is entered. This facilitates a compact representation of the state chart.

The default value is the M_OFF state. Upon a connection vote from the controller, the FSM will transition to the M_WAIT state or directly to the M_CON or M_DISC state according to the slave's connection vote, SConnect, assuming neither slave nor master stalls the transition.

Upon reaching the M_CON state, the OCP initiator's activity is enabled (OCPStopReq is de-asserted). It stays enabled unless either the master or the slave votes for a disconnection (in which case OCPStopReq is asserted). It is interesting to note here that there is no restriction on when either side can change its vote on connection state. Only when the OCP initiator has stopped its activity (OCPStopAck=1), will the M_CON state be exited, assuming there is still a disconnection vote. The FSM will then transition to the M_WAIT state or directly to the M_DISC or M_OFF state according to the master's connection vote, assuming neither slave nor master stalls the transition.

Similarly, upon reaching the M_DISC state, the alternate behavior's activity is enabled (ALTStopReq is de-asserted). It stays enabled unless either the master votes for a disconnection or the slave votes for a reconnection (ALTStopReq is asserted). Only when the alternate behavior has completed its activity (ALTStopAck=1), will the M_DISC state be exited, assuming there is still a master disconnection vote or a slave reconnection vote. The FSM will then transition to the M_WAIT state or directly to the M_CON or M_OFF state according to the master's connection vote, assuming neither slave nor master stalls the transition.

Finally, the M_WAIT state is exited only when both slave and master do not stall the transition (MWaitReq=SWait=0). The FSM will then transition to the M_OFF state if the master votes for a disconnection (MDisReq=1), or to the M_DISC state if the slave votes for a disconnection (SConnect=0), or to the M_CON state if both master and slave vote for a connection.

Examples of sequences: Following are two examples of waveforms showing how the protocol works and how it links with external components.

The first example (Figure 6) shows the slave being first to vote for a connection (A). Some time later, the master also votes for a connection (B) and the connected state is reached. Next the master votes for a disconnection (D), causing the OCP to disconnect, first reaching the M_WAIT state (E) and subsequently the M_OFF state (F) when the slave allows it.

Figure 6: First waveform example

A:  The slave wakes up and votes for a connection: SConnect is asserted.
  
B:  The master wakes up and votes for a connection: MDiscReq is de-asserted.
B+1:  MConnect transitions to the M_CON state per the connection status FSM specification. Simultaneously the OCP initiator starts (OCPStopReq is de-asserted).
B+2:  OCPStopAck is de-asserted, indicating that the OCP initiator is operational from this point.
  
C:  At this point, the slave needs to control OCP disconnection completion and asserts the SWait signal for this purpose.
  
D:  The master controller now votes for a disconnection: MDiscReq is asserted.
D+1:  The OCP initiator is requested to stop OCP traffic toward the slave: OCPStopReq is asserted.
  
E:  OCPStopAck is asserted: the OCP initiator is cleanly stopped.
E+1:  MConnect transitions to the M_WAIT state since SWait=1 at this moment.
  
F:  After some time, the slave allows the master to exit the M_WAIT state and to complete OCP disconnection by de-asserting SWait.
F+1:  MConnect transitions to the M_OFF state per the connection status FSM specification.
  

In the second example (Figure 7), the master is the first to vote for a connection (A) and the M_DISC state is reached. Some time later, the slave also votes for a connection (B) and the connected state is reached (C). Then the slave votes for a disconnection (D), making OCP disconnect (E). Finally the master also votes for a disconnection (F) and the M_OFF state is reached.

Figure 7: Second waveform example

A:  The master wakes up and votes for a connection: MDiscReq is de-asserted.
A+1:  MConnect transitions to the M_DISC state per the connection status FSM specification. Simultaneously the alternate behavior starts: ALTStopReq is de-asserted.
A+2:  ALTStopAck is de-asserted, indicating that the alternate behavior is operational from this point.
  
B:  The slave wakes up and votes for a connection: SConnect is asserted.
B+1:  The alternate behavior is requested to stop: ALTStopReq is asserted.
  
C:  ALTStopAck is asserted: the alternate behavior is cleanly stopped.
C+1:  MConnect transitions to the M_CON state per the connection status FSM specification. Simultaneously the OCP initiator starts: OCPStopReq is de-asserted.
C+2:  OCPStopAck is de-asserted, indicating that the OCP initiator is operational from this point.
  
D:  The slave now votes for a disconnection: SConnect is de-asserted.
D+1:  The OCP initiator is requested to stop OCP traffic toward the slave: OCPStopReq is asserted.
  
E:  OCPStopAck is asserted: the OCP initiator is cleanly stopped.
E+1:  MConnect transitions to the M_DISC state per the connection status FSM specification. Simultaneously the alternate behavior starts: ALTStopReq is de-asserted.
E+2:  ALTStopAck is de-asserted, indicating that the alternate behavior is operational from this point.
  
F:  The master controller now votes for a disconnection: MDiscReq is asserted.
F+1:  The alternate behavior is requested to stop: ALTStopReq is asserted.
  
G:  ALTStopAck is asserted: the alternate behavior is cleanly stopped.
G+1:  MConnect transitions to the M_OFF state per the connection status FSM.

It should be noted that the activities of the OCP initiator and the alternate behavior are exclusive. This is guaranteed by the connection status FSM specification.

Stopping the OCP initiator: The OCP initiator has a hand-shake protocol with the connection status FSM (OCPStopReq/Ack). The OCP disconnect protocol ensures that the OCP initiator has cleanly stopped its traffic with the slave before exiting the M_CON state, by way of the OCPStopAck signal. Stopping the OCP traffic towards the slave involves two steps. The first is called "fencing" and consists of stopping sending OCP commands at a transaction boundary. The second step is called "draining" and consists of waiting to receive the responses of all outstanding transactions. Only when both steps are completed, is the OCP initiator cleanly stopped: there are no more outstanding transactions, and all current transactions have been completed.

The OCP disconnect protocol does not actually specify when the fencing operation must be performed. Therefore, upon a request to stop the OCP initiator, the master has the freedom to decide when to perform fencing. In some cases it may be desirable to fence the OCP traffic at the next transaction boundary. However, in other cases, it may be desirable for the initiator to delay the fencing operation based on architectural choices that are beyond the scope of the OCP disconnect protocol. A master could for example perform fencing at a frame boundary, a frame consisting of several OCP transactions.

Alternate behavior: The alternate behavior is a behavior that is defined for upstream traffic intended for a disconnected slave. This option may or may not be used in a master. The OCP disconnect protocol provides support for this alternate behavior by linking it to the M_DISC connection state. However, the OCP disconnect protocol does not define the alternate behavior. Multiple alternate behaviors can be implemented in the same master and switching between different behaviors is possible according to ad-hoc decisions. Specification of the alternate behavior and its control could be added to the OCP disconnect protocol in the future.

Several alternate behaviors could be imagined. The simplest one would be to do nothing regarding upstream traffic intended for a disconnected slave. This would be equivalent to not implementing an alternate behavior. Another possible behavior would be to reply autonomously to upstream traffic with a default ERROR response. This could be useful for example, when a processor in a SoC tries to access a slave that is asleep, and typically denotes a software problem. The processor would receive an error response that would be treated as an exception. This would be of considerable help in finding the cause of the problem and debugging the software. A third alternate behavior would be to reply autonomously to upstream traffic by a default DVA response. This could be useful in the case where the sleeping slave is a debug IP and it is not desirable for the processor to receive an error when it tries to access this module. A final example of alternate behavior would be the wakeup-on-demand behavior. When there is any pending traffic for a sleeping slave, the slave controller is signaled to wake up and vote again for connection. Consequently, the OCP connection will be restored and any stalled traffic will be sent to the slave.

Linking OCP Disconnect with Power Management

As established in the first part of this paper, the OCP disconnection state is a pre-requisite state for all OCP interfaces at a domain boundary, before performing a domain sleep transition. The OCP disconnect protocol can easily be linked to the power manager module to comply with this requirement. Following are several examples of such an implementation. This is not intended to be a reference implementation, but is simply here to illustrate one possible implementation. Other implementations may be designed.

Slave IP: Consider a power-managed slave IP having a dedicated power-management protocol with the power manager, namely a SleepReq/SleepAck handshake as illustrated in Figure 8.

Figure 8: Power-managed slave IP

Before performing a sleep transition, the power manager sends a sleep request to the slave, and waits for the corresponding acknowledge. Within the slave, a finite state machine performs any necessary actions before sending the acknowledge signal. One such action is to perform the OCP disconnection by de-asserting the SConnect signal and then waiting for a disconnected state (M_DISC or M_OFF). By using this sequence and the OCP disconnect protocol, we can be sure that the OCP socket is cleanly stopped before performing a sleep transition.

Conversely, the power manager will perform a wakeup transition with respect to power/clock/reset before requesting the slave to wake up. In turn, the FSM will ensure that the OCP slave port is functional before voting again for an OCP connection by asserting SConnect signal.

Note that in this particular case, the SWait signal is tied low as there is no need for the slave to stall the transition of the OCP connection status.

Master IP: Now consider a power-managed master IP, having a dedicated power-management protocol with the power manager, namely SleepReq/SleepAck handshake as illustrated in Figure 9.

Figure 9: Power-managed master IP

Before performing a sleep transition, the power manager sends a sleep request to the master, then waits for the corresponding acknowledge before performing the sleep transition. Within the master, a finite state machine performs any necessary actions before sending the acknowledge signal. One such action is to perform the OCP disconnection by asserting the MDiscReq signal and then waiting for the OCP connection status to reach the M_OFF state. Note that it is likely that the initiator was already in a quiet state before the power manager took the decision to put it to sleep (as the power manager knows the master's activity). Consequently, disconnection should be straightforward.

Conversely, the power manager will perform a wakeup transition with respect to power/clock/reset before requesting the master to wake up. The FSM will again vote for an OCP connection by de-asserting MDiscReq and turning on any other necessary components within the master.

Note that in this particular case, the MWaitReq signal is tied low since there is no need for the master to stall the transition of the OCP connection status.

Interconnect IP: Figure 10 shows a power-managed interconnect IP, having a dedicated power-management protocol with the power manager (SleepReq/SleepAck handshake). This is essentially a combination of the above two cases. The interconnect IP consists of N slave ports, M master ports and a core (switch fabric).

Figure 10: Power-managed Interconnect IP

Before performing a sleep transition, the power manager sends a sleep request to the interconnect IP, then waits for the corresponding acknowledge. Within the IP, a finite state machine performs any necessary actions before sending the acknowledge signal. The sequence of actions could be: first perform the OCP disconnection at the N slave ports, by de-asserting the SConnect signal and waiting for a disconnected state (M_DISC or M_OFF). Next, ensure the internal switch fabric is entirely empty of transactions. Finally, perform the OCP disconnection at the M master ports and wait for the OCP connection status to reach the M_OFF state.

Conversely, the power manager will perform a wakeup transition with respect to power/clock/reset before requesting the IP to wakeup. In turn, the FSM will ensure that the switch fabric is functional before voting again for an OCP connection on both its master and its slave ports.

Bridge power-managed through the master and the slave: As stated in the first part of this paper, the goal is to be able to abstract the bridge and the two OCP sockets between the master and the slave as a single OCP socket. This has the following implications:

  • The bridge does not have a dedicated power-management protocol with the power manager.

  • The bridge is power-managed through the OCP disconnect protocol.

In the most generic case (Figure 11), the master and the slave are in two different domains from the power and clock standpoint and the bridge spans the two domains. Each half of the bridge will then be managed together with the connected entity (master side managed together with the master module, slave side managed together with the slave module).

Figure 11: OCP-to-OCP Bridge

By default, the bridge master side requests the master to stall the transition of the master side OCP connection status (SWait_m is asserted). Only at a certain moment will it be released in order to allow the master's side OCP connection status to reach another stable state. This will happen only when the slave side is in a compatible connection status.

The principle is as follows:

  • The slave's connection vote is conveyed through the bridge to the master.

  • At the master's side, the connection votes from master and slave cause the MConnect_m connection status to exit the current state, and the M_WAIT state is entered due to the SWait_m constraint.

  • If at this point the bridge's master side is aware of the slave domain's sleeping state, it will release the SWait_m signal with a slave disconnection vote (SConnect_m='0') until a new stable master side OCP connection status is reached. In this case the following does not apply.

  • If the former master's side OCP connection status was M_CON, the core of the bridge must reach its sleep state, with either slave or master domain sleep transition: the bridge is empty, plus other conditions if applicable.

  • Once the master's side OCP connection status is locked in the M_WAIT state and the bridge core is in the sleep state, the bridge's master side allows the slave side OCP connection status to move to a new stable connection state, which is also locked. At this point only the M_CON or M_DISC connection states can be reached depending on the slave's vote.

  • The value of this new slave side OCP connection status is passed to the bridge's master side, which in turn overrides the slave's connection vote (SConnect_m) and releases the SWait_m signal until a new stable master side OCP connection status is reached.

  • The new master's side OCP connection status can either be the same as the slave side, or it can be M_OFF. In the latter case, the slave's side OCP connection status can subsequently transition to M_OFF.

Two finite state machines are necessary to implement the above mechanisms, one in each half to the OCP-to-OCP bridge. Each state machine is responsible for handling one of the two OCP disconnect protocol mechanisms. In addition, both state machines are communicating together and the master's side state machine controls the bridge core sleep operation.

It is not the purpose of this paper to detail these state machines. They have been designed using an ESL tool suite (Esterel Studio). This tool allows among other things graphical FSM capture and simulation, as well as RTL generation and formal validation. A validation environment has been build in the Esterel language around the two bridge state machines, with models of the bridge core, the slave, the master and the power manager. Assertions have also been added in Esterel language. All the following properties have been formally proven:

  • SConnect_m and SWait_m comply with the OCP disconnect protocol definition.

  • MConnect_s complies with the OCP disconnect protocol definition.

  • The master's domain sleep transition can happen only when OCP traffic between master and slave is properly stopped (master side OCP connection status is M_OFF and bridge core is in sleep state).

  • The slave's domain sleep transition can happen only when OCP traffic between master and slave is properly stopped (slave side OCP connection status is M_OFF or M_DISC and bridge core is in sleep state).

  • Strong coherency properties:

    • (MConnect_m = M_CON) => (MConnect_s = M_CON)

    • (MConnect_m = M_DISC) => (MConnect_s = M_DISC).

  • Liveliness property: it is not possible to reach a deadlock situation.

Figure 12 shows one example of waveform showing how the bridge works.

Figure 12: OCP-to-OCP bridge waveform example

A:  The master wakes up and votes for a connection: MDiscReq is de-asserted. This causes the MConnect_m connection status to move to the M_WAIT state. Since the master side is aware of the slave domain's sleeping state, the bridge releases the SWait_m signal with a slave disconnection vote (SConnect_m='0') and the M_DISC state is reached.
  
B:  The slave wakes up and votes for a connection. The slave's connection vote is propagated to the master. This causes the MConnect_m connection status to move to the M_WAIT state. In turn, the slave's side connection status is allowed to move to a new stable state, M_CON in this example. Finally, the master's side connection status is aligned by releasing the SWait_m signal with a slave connection vote (SConnect_m='1') and the M_CON state is reached.
  
C:  The slave now votes for a disconnection. The slave's vote is propagated to the master. This causes the MConnect_m connection status to move to the M_WAIT state once OCP traffic has been fenced and drained at the master. Next, the bridge performs any necessary actions in order to reach its sleep state. Then, the slave's side connection status is allowed to move to a new stable state, M_DISC in this example. Finally, the master's side connection status is aligned by releasing the SWait_m signal with a slave disconnection vote (SConnect_m='0') and the M_DISC state is reached.
  
D:  The master votes for a disconnection: MDiscReq is asserted. This causes the MConnect_m connection status to move to the M_WAIT state. Since the master side is aware of the slave domain's sleeping state, the bridge releases the SWait_m signal with a slave disconnection vote (SConnect_m='0') and the M_OFF state is reached.

Conclusion

There is a clear trend to use more and more power management techniques within SoCs. Multiple domain partitioning involves new architectural challenges. The OCP disconnect protocol has been primarily introduced to facilitate power management transitions at domain level. Conditioning the domain sleep transition to a prior OCP disconnection state ensures that the system will remain coherent and will not experience any disorder due to the OCP interfaces.

Christophe Vatinel is a System-on-Chip Architect at Texas Instruments (France), working in the OMAP business unit. Christophe graduated from Ecole Polytechnique and Télécom Paris, France. Before joining Texas Instruments Inc, Christophe was a successful ASIC designer for Thomson-CSF, embedded DSP project lead for VLSI Technology Inc, and 2.5G base-band modem design lead for a startup in Wireless.


EECatalog Tech Videos

MAGAZINE

  • Download the latest issue of the Chip Design Magazine
    and subscribe to receive future issues and the email newsletter.

Chip Design Research

Are you up-to-date on important SoC and IP design trends, analysis and market forecasts?

Chip Design now offers customized market research services.

For more information contact Karen Popp at +1 415-305-5557

Upcoming Events

©2014 Extension Media. All Rights Reserved. PRIVACY POLICY | TERMS AND CONDITIONS