WO1995020190A1 - Method and system for pipelining bus requests - Google Patents

Method and system for pipelining bus requests Download PDF

Info

Publication number
WO1995020190A1
WO1995020190A1 PCT/US1995/000647 US9500647W WO9520190A1 WO 1995020190 A1 WO1995020190 A1 WO 1995020190A1 US 9500647 W US9500647 W US 9500647W WO 9520190 A1 WO9520190 A1 WO 9520190A1
Authority
WO
WIPO (PCT)
Prior art keywords
bus
node
request signal
signal
coordinator
Prior art date
Application number
PCT/US1995/000647
Other languages
French (fr)
Inventor
William Todd Krein
Charles M. Flaig
James D. Kelly
Original Assignee
Apple Computer, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Apple Computer, Inc. filed Critical Apple Computer, Inc.
Priority to AU16820/95A priority Critical patent/AU1682095A/en
Publication of WO1995020190A1 publication Critical patent/WO1995020190A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/36Handling requests for interconnection or transfer for access to common bus or bus system
    • G06F13/362Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
    • G06F13/364Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control using independent requests or grants, e.g. using separated request and grant lines

Definitions

  • This invention relates generally to computer systems and more specifically to a method and system for pipelining bus requests which increases bus utilization and improves system performance.
  • a typical computer system comprises a motherboard, a system bus, and a plurality of "nodes" or devices coupled to the system bus.
  • the system bus is used by the nodes to send information signals to the motherboard and to each other. Because a plurality of different nodes are coupled to the same bus, some bus coordination mechanism is needed in order to coordinate access to the bus by the nodes to prevent bus contention.
  • This bus coordination function is usually performed by a bus arbiter.
  • a bus arbiter controls access to the system bus by first receiving bus access requests from the various nodes, and then determining (usually by performing some arbitration algorithm) which node should gain control of the system bus. Thereafter, the arbiter sends a bus grant control signal to the selected node to grant control of the bus to that node.
  • the selected node Once the selected node has control of the bus, it is free to use the bus to send information signals.
  • the node notifies the arbiter that it no longer needs the bus and, at that point, the arbiter deasserts the bus grant signal to take control of the bus away from the node.
  • the bus arbiter alternatingly grants the system bus to a number of different nodes. There are times, however, when only one node actively and repeatedly requests the bus. During these times, it would be desirable for the requesting node to "pipeline" its requests.
  • Pipelining is a process by which a node chains together consecutive bus requests such that the bus grant signal from the arbiter to the requesting node does not change logic levels between the different bus requests. Pipelining is desirable because it eliminates dead-time on the bus between consecutive information transfers, which in turn, increases bus utilization and improves system performance.
  • pipelining is implemented by having the requesting node generate and manage two separate signals.
  • a first signal is used to request the bus, and a second signal is used to indicate to the arbiter that the node is finished with the bus.
  • a pipelining scheme while functional, is cumbersome because it requires that the node and arbiter manage and process two separate signals.
  • pipelining should be implemented using only one signal from the node, with this one signal being used to both request the bus and to retain ownership of the bus.
  • the system of the present invention preferably comprises a bus, at least one node coupled to the bus, and a bus coordinator coupled to the node for coordinating access to the bus by the node.
  • the node sends an asserted bus request signal to the coordinator.
  • This bus request signal is used by the node to both request control of the bus and to retain ownership of the bus.
  • the coordinator sends an asserted bus grant signal to the node to grant control of the bus to the node.
  • This bus grant signal preferably remains asserted as long as the bus request from the node is asserted.
  • the node Once the node is granted control of the bus, it transmits information signals onto the bus. After sending the asserted bus grant signal to the node, the coordinator monitors the status of the bus request signal to determine whether the node wishes to retain ownership of the bus. If the bus request signal is deasserted by the node, then it is determined that the node no longer needs the bus, thus, the bus grant signal can be deasserted to take control of the bus away from the node.
  • pipelining is provided for by maintaining the bus grant signal in an asserted state for at least one clock cycle after deassertion of the bus request signal is detected.
  • the coordinator detects that the bus request signal has been deasserted, it does not immediately deassert the bus grant signal but instead maintains the bus grant signal in an asserted state for at least one extra clock cycle. In effect, the coordinator is granting control of the bus to the node for an extra clock cycle. This extra cycle gives the node sufficient time to deassert and to reassert the bus request signal before the bus grant signal changes states. Where the bus grant signal is reasserted by the node before the extra clock cycle elapses, the coordinator does not deassert the bus grant signal but instead maintains the bus grant signal in the asserted state to allow the node to send another set of information signals onto the bus. Because the bus grant signal does not change states between the deassertion and reassertion of the bus request signal, there is no "dead time" between the two bus requests. Thus, the two requests are pipelined.
  • the present invention prevents the extra bus grant cycle from being wasted by having the node deassert the bus request signal one clock cycle before transmitting its last set of information signals. Since the bus is granted to the node for one extra clock cycle, the node may use this extra clock cycle to transmit the last of its information signals. By so doing, the extra bus grant cycle is not wasted when pipelining is not performed.
  • Fig. 1 is a general block diagram of the system of the present invention.
  • Fig. 2 is a timing diagram of a bus coordination system which does not implement pipelining.
  • Fig. 3 is a timing diagram of the bus coordination system of the present invention illustrating the process of pipelining consecutive bus requests.
  • Fig. 4 is a flow diagram for the source interface state machine associated with each node.
  • Fig. 5 is a flow diagram for the node interface state machine of the bus access coordinator.
  • Fig. 6 is a flow diagram of the pipelining process as implemented by the system of the present invention.
  • a general block diagram of the system 10 of the present invention wherein the system 10 preferably comprises a system bus 12, a plurality of nodes 14 ⁇ -14 n coupled to and sharing the bus 12, and a bus access coordinator 16 coupled to the nodes 14 * [ -14 n .
  • Each of the nodes 14 may represent a device which generates and sends information signals, or a port through which information signals may be sent. Because a plurality of nodes 14 are coupled to the same bus 12, a mechanism is needed for coordinating access to the bus by the nodes 14 in order to prevent bus contention. Coordinator 16 serves this purpose.
  • a node 14 To gain access to the bus 12, a node 14 first sends an asserted bus request signal to coordinator 16 to request permission to control the bus 12. If multiple bus request signals are simultaneously received by coordinator 16, as will often be the case, the coordinator 16 carries out an arbitration scheme to determine which node should be granted control of the bus 12. The arbitration scheme may be a round-robin type of fairness scheme or some other type of scheme. After it is determined which node 14 should get control of the bus 12, coordinator 16 sends an asserted bus grant signal to the selected node (nodel 14 j , for example) to grant control of the bus 12 to that node. After gaining control of the bus 12, the selected node 14] may send information signals onto the bus.
  • the coordinator 16 After granting control of the bus 12 to a selected node 14] , the coordinator 16 monitors the bus request signal from that node 14] to determine whether the signal is still asserted. If the bus request signal remains asserted, then it means that the node ⁇ 4 ⁇ is still using the bus; thus, coordinator 16 maintains the bus grant signal in the asserted state. However, if the bus request signal becomes deasserted, then coordinator can conclude that node 14 * ⁇ no longer needs the bus; thus, coordinator 16 can deassert the bus grant signal to take control of the bus 12 away from the selected node 14 ⁇ . Because the bus grant signal tracks the bus request signal, the bus request signal is used by a node 14 not only to request access to the bus 12 but also to retain ownership of the bus 12. Using the same signal for both purposes simplifies the design of system 10.
  • the bus access coordinator 16 probably receives and processes a multiplicity of bus requests at a time so that it alternatingly grants the system bus 12 to a
  • coordinator 16 A number of different nodes. There are times, however, when coordinator 16 repeatedly grants control of the bus 12 to the same node. This may be due to the fact that only one node is actively and repeatedly requesting the bus, or it may be due to priority considerations, time slice considerations, or priority/time slice considerations. Whatever the reason, it would be desirable during such times for coordinator 16 to pipeline the bus requests from the node to minimize "dead time" on the bus 10, thereby maximizing bus utilization.
  • pipelining is provided for by having coordinator 16 maintain the bus grant signal in the asserted state for at least one extra clock cycle after deassertion of the bus request signal is detected.
  • the bus grant signal tracks the bus request signal. As long as the bus request signal remains asserted, the bus grant signal also remains asserted. But as soon as deassertion of the bus request signal is detected, the coordinator is free to deassert the bus grant signal to wrest control of the bus 12 away from the node.
  • the coordinator 16 instead of deasserting the bus grant signal as soon as deassertion of the bus request signal is detected, the coordinator 16 preferably maintains the bus grant signal in the asserted state for an extra clock cycle after deassertion of the bus request signal is detected.
  • This extra clock cycle gives the node time to reassert the bus request signal (thus, making another bus request) before the bus grant signal changes states. If the bus request signal is reasserted before the extra clock cycle expires (and if the bus is once again granted to the node), then the node gains another tenure on the bus 12 without having the bus grant signal change states. Thus, ownership of the bus is continuous, which means that "dead time" on the bus is eliminated. Consecutive bus requests are thus pipelined.
  • Fig. 2 wherein a timing diagram is provided of a bus coordination system which does not pipeline.
  • the requesting node asserts its bus request signal at the beginning of clock cycle 1 to request access to the bus.
  • the bus grant signal is asserted as soon as the asserted bus request signal is detected, namely, at the beginning of cycle 2.
  • the node has control of the bus; thus, during this time period, the node sends data onto the bus.
  • the node deasserts its request signal to indicate that it is now finished using the bus.
  • the coordinator detects the deassertion of the request signal at the beginning of cycle 7 and, in response, it deasserts the grant signal during cycle 7.
  • the node decides that it needs another tenure on the bus. To request another bus tenure, the node reasserts the request signal at the beginning of cycle 7. This reassertion of the request signal, however, is not detected by the coordinator in cycle 7 but in cycle 8. This means that the coordinator will deassert the grant signal in cycle 7 and then reassert the grant signal in cycle 8 so that the grant signal changes states.
  • the consequence of having the grant signal change states is that "dead time" is imposed on the bus as shown in Fig. 2. During this "dead time", no node has control of the bus and no information transfer is conducted on the bus. Thus, valuable bus time is wasted.
  • a requesting node (nodel 14j, for example) asserts its bus request signal at the beginning of clock cycle 1 to request control of the bus.
  • This request signal is detected by coordinator 16 in cycle 2 and, assuming that the bus 12 is granted to nodel, the bus grant signal is asserted in cycle 2.
  • nodel has control of the bus 12; thus, during this time period, data may be transmitted from nodel onto bus 12.
  • nodel deasserts the request signal to indicate that it no longer needs the bus.
  • the deassertion of the request signal is detected by coordinator 16 at the beginning of cycle 7 and, typically, the grant signal would be deasserted in cycle 7. However, the coordinator 16 of the present invention maintains the grant signal in the asserted state for one extra clock cycle. Thus, the grant signal, if deasserted at all, will not be deasserted until cycle 8.
  • nodel After deasserting the request signal in cycle 6, nodel decides that it needs another bus tenure. To request another tenure on the bus 12, nodel reasserts the request signal in cycle 7. This reassertion of the request signal is detected by coordinator 16 at the beginning of cycle 8. Recall that because the request signal was deasserted in cycle 6, the bus grant signal was due to be deasserted in cycle 8. However, by the beginning of cycle 8, the request signal has already been reasserted, which indicates to coordinator 16 that another bus tenure is desired.
  • the coordinator 16 When the coordinator 16 detects in cycle 8 that the request signal has been reasserted, the coordinator 16 does not deassert and reassert the grant signal, but instead simply maintains the grant signal in the asserted state to grant nodel another bus tenure. Hence, between the first and second bus requests, the bus grant signal does not change states. Since the bus grant signal does not change states, no "dead time" is imposed on the bus 12. Consecutive bus requests from a single node are thus pipelined.
  • each requesting node in the system of the present invention preferably sends information signals onto the bus during the extra grant cycle.
  • the request signal is deasserted at the beginning of cycle 6 but that data is sent onto the bus 12 through cycle 7.
  • the request signal is deasserted at the beginning of cycle 11 but data is transmitted onto bus 12 through cycle 12.
  • a node sends its last clock cycle of information as it is deasserting its request signal.
  • the node preferably deasserts its request signal and then one clock cycle later, transmit its last clock cycle of information as shown in Fig. 3.
  • the requesting node can do this because it knows that the bus grant signal will remain asserted for an extra cycle after deassertion of the request signal is detected.
  • the request signal By deasserting the request signal one clock cycle before it sends its last set of information, and by continuing to send information signals onto the bus 12 during the following cycle, the requesting node ensures that the extra grant cycle is not wasted.
  • the system of the present invention provides the best of both worlds. It allows for pipelining by providing for an extra bus grant cycle while, at the same time, ensuring that the extra grant cycle is used productively.
  • each node 14 preferably comprises a source interface for deasserting the bus request signal one clock cycle early
  • the bus coordinator 16 preferably comprises at least one node interface for maintaining the bus grant signal to a node in the asserted state for one extra clock cycle.
  • coordinator 16 preferably comprises a plurality of node interfaces, each node interface corresponding to one of the nodes 14.
  • these interfaces take the form of state machines, but it should be noted that these interfaces may also be implemented by other equivalent means such as software and the like.
  • a flow diagram for the source interface state machine of each node is provided in Fig. 4
  • a flow diagram for the node interface state machine of the coordinator 16 is provided in Fig. 5.
  • the source interface state machine begins operation by determining 20 whether the node has any information signals to send. If not, the source interface continuously cycles until the node has information signals to send. When the node has information signals to send onto the bus 12, the source interface asserts 22 the bus request signal and sends this signal to the coordinator 16 to request control of the bus 12. Thereafter, the source interface waits 24, 26 for a bus grant signal from coordinator 16. When the bus grant signal is received, the interface knows that it has control of the bus and that it can begin transmitting information signals onto the bus 12. The source interface begins the transmitting process by determining 28 how many clock cycles will be needed in order to transmit all of the information signals.
  • the source interface derives 30 the number (n) of clock cycles that the request signal should remain asserted after the bus grant signal is received.
  • the number n is equal to the number of cycles needed to transmit the information minus two so that the request signal is deasserted two clock cycles before transmission of the information is complete.
  • the node preferably deasserts the request signal one clock cycle before it sends the last portion of its information signals.
  • the source interface determines 32 whether an n number of clock cycles has elapsed. If not, the interface sends 38 the next clock cycle of information onto the bus 12 and loops back to step 32.
  • the source interface deasserts 34 the request signal and, thereafter, sends 36 the last two clock cycles of information onto the bus 12.
  • the interface then loops back to step 20 for another set of information.
  • the source interface causes information signals to be sent onto the bus 12 during the extra bus grant cycle. By so doing, the interface ensures that the extra grant cycle provided by the coordinator 16 will be used productively.
  • the node interface begins operation by receiving 40 a bus request signal from the node to which it corresponds (nodel, for example). This bus request signal (along with the other bus request signals received from the other nodes by other node interfaces) is passed on to the coordinator 16. The coordinator 16 performs an arbitration procedure on the various request signals received and determines which node should receive control of the bus 12 next. If coordinator 16 determines that nodel should be the next node to own the bus, then the node interface sends 44 an asserted bus grant signal to nodel to grant control of the bus 12 to nodel .
  • the node interface monitors 46 the status of the request signal from nodel. If the request signal continues to be asserted, then the node interface maintains 48 the bus grant signal at the asserted state. But, if the node interface detects that the request signal has been deasserted, then it will maintain 50 the bus grant signal in the asserted state for one extra clock cycle. Thereafter, the node interface checks 52 again the status of the request signal to determine whether the request signal has been reasserted (and hence, nodel is attempting to pipeline). If the request signal has not been reasserted, then the node interface deasserts 56 the bus grant signal to take control of the bus away from nodel.
  • the node interface maintains 54 the bus grant signal at the asserted level so that between the first and second bus requests, the bus grant signal does not change states. By maintaining the bus grant signal at the asserted state, the node interface allows the node (nodel) to pipeline consecutive requests.
  • nodel is the node which wishes to pipeline consecutive bus requests.
  • the pipelining process begins with the node interface corresponding to nodel receiving 60 an asserted bus request signal from nodel .
  • the node interface sends 62 an asserted bus grant signal to nodel to grant nodel control of the bus 12.
  • nodel begins sending 64 a first set of information signals onto the bus 12.
  • nodel deasserts 66 the bus request signal but continues 68 to send two more clock cycles of information signals.
  • the deassertion of the bus request signal is detected 70 by the node interface and, in response, the node interface maintains 72 the bus grant signal in the asserted state for one extra clock cycle after deassertion of the request signal is detected. While the bus grant signal is maintained by the node interface, nodel reasserts 74 the bus request signal to request another tenure on the bus 12. If the request signal is reasserted before the extra bus grant cycle elapses, then the node interface maintains 76 the bus grant signal in the asserted state to grant nodel another tenure on the bus 12. The bus grant signal does not experience a state change between the two bus tenures. The two bus requests from nodel are thus pipelined.
  • nodel After being granted the second bus tenure, nodel proceeds to transmit 78 another set of information signals onto the bus 12.
  • the process described above may be repeated to pipeline any number of consecutive bus requests.
  • the node interface of the coordinator 16 maintains the bus grant signal in the asserted state for one extra clock cycle and the source interface deasserts the bus request signal one clock cycle early.
  • the present invention may be implemented by having the node interface maintain the bus grant signal for two extra clock cycles and by having the source interface deassert the request signal two clock cycles early. In fact, the invention may be implemented using any desired number of clock cycles. This and other modifications are within the scope of the present invention.

Abstract

A system for pipelining bus requests includes a bus, at least one node coupled to the bus, and a bus coordinator coupled to the node. The node uses a single bus request signal to both request control of the bus from the bus coordinator, and to retain control of the bus. In response to an asserted bus request signal from the node, the coordinator sends an asserted bus grant signal to the node to grant the node control of the bus. This bus grant signal tracks the bus request signal so that as long as the bus request signal remains asserted, the bus grant signal also is asserted. To allow for pipelining, the bus coordinator maintains the bus grant signal in an asserted state for at least one clock cycle after the bus request is deasserted. By holding the bus grant signal in the asserted state for one extra cycle, the coordinator gives the node time to deassert and then to reassert the bus request signal before the bus grant signal changes state. If the bus request is reasserted within the extra cycle, the coordinator continues to maintain the bus grant signal in the asserted state so that no state change is experienced by the bus grant signal between the deassertion and the reassertion of the bus request signal. In this manner, consecutive bus requests are pipelined. To further increase the efficiency of the system, the node deasserts the bus request signal at least one clock cycle before it sends its last set of information, and continues to send information signals in the following clock cycle. By so doing, the node ensures that the extra clock cycle of the bus grant is not wasted.

Description

METHOD AND SYSTEM FOR PIPELINING BUS REQUESTS
Field of the Invention
This invention relates generally to computer systems and more specifically to a method and system for pipelining bus requests which increases bus utilization and improves system performance.
Description of the Background Art
A typical computer system comprises a motherboard, a system bus, and a plurality of "nodes" or devices coupled to the system bus. The system bus is used by the nodes to send information signals to the motherboard and to each other. Because a plurality of different nodes are coupled to the same bus, some bus coordination mechanism is needed in order to coordinate access to the bus by the nodes to prevent bus contention. This bus coordination function is usually performed by a bus arbiter. A bus arbiter controls access to the system bus by first receiving bus access requests from the various nodes, and then determining (usually by performing some arbitration algorithm) which node should gain control of the system bus. Thereafter, the arbiter sends a bus grant control signal to the selected node to grant control of the bus to that node. Once the selected node has control of the bus, it is free to use the bus to send information signals. When information transmission is complete, the node notifies the arbiter that it no longer needs the bus and, at that point, the arbiter deasserts the bus grant signal to take control of the bus away from the node.
In typical operation, the bus arbiter alternatingly grants the system bus to a number of different nodes. There are times, however, when only one node actively and repeatedly requests the bus. During these times, it would be desirable for the requesting node to "pipeline" its requests. Pipelining is a process by which a node chains together consecutive bus requests such that the bus grant signal from the arbiter to the requesting node does not change logic levels between the different bus requests. Pipelining is desirable because it eliminates dead-time on the bus between consecutive information transfers, which in turn, increases bus utilization and improves system performance. Currently, pipelining is implemented by having the requesting node generate and manage two separate signals. A first signal is used to request the bus, and a second signal is used to indicate to the arbiter that the node is finished with the bus. Such a pipelining scheme, while functional, is cumbersome because it requires that the node and arbiter manage and process two separate signals. Ideally, pipelining should be implemented using only one signal from the node, with this one signal being used to both request the bus and to retain ownership of the bus. Currently, however, there is no bus system believed to be available which has the ability to pipeline bus requests using only one signal from the requesting node.
Summary of the Invention
In accordance with the present invention, there is provided a system wherein pipelining is implemented using only one bus request signal from the requesting node. The system of the present invention preferably comprises a bus, at least one node coupled to the bus, and a bus coordinator coupled to the node for coordinating access to the bus by the node. To access the bus, the node sends an asserted bus request signal to the coordinator. This bus request signal is used by the node to both request control of the bus and to retain ownership of the bus. In response, the coordinator sends an asserted bus grant signal to the node to grant control of the bus to the node. This bus grant signal preferably remains asserted as long as the bus request from the node is asserted. Once the node is granted control of the bus, it transmits information signals onto the bus. After sending the asserted bus grant signal to the node, the coordinator monitors the status of the bus request signal to determine whether the node wishes to retain ownership of the bus. If the bus request signal is deasserted by the node, then it is determined that the node no longer needs the bus, thus, the bus grant signal can be deasserted to take control of the bus away from the node. In the present invention, pipelining is provided for by maintaining the bus grant signal in an asserted state for at least one clock cycle after deassertion of the bus request signal is detected. That is, whenever, the coordinator detects that the bus request signal has been deasserted, it does not immediately deassert the bus grant signal but instead maintains the bus grant signal in an asserted state for at least one extra clock cycle. In effect, the coordinator is granting control of the bus to the node for an extra clock cycle. This extra cycle gives the node sufficient time to deassert and to reassert the bus request signal before the bus grant signal changes states. Where the bus grant signal is reasserted by the node before the extra clock cycle elapses, the coordinator does not deassert the bus grant signal but instead maintains the bus grant signal in the asserted state to allow the node to send another set of information signals onto the bus. Because the bus grant signal does not change states between the deassertion and reassertion of the bus request signal, there is no "dead time" between the two bus requests. Thus, the two requests are pipelined.
To further improve system efficiency, the present invention prevents the extra bus grant cycle from being wasted by having the node deassert the bus request signal one clock cycle before transmitting its last set of information signals. Since the bus is granted to the node for one extra clock cycle, the node may use this extra clock cycle to transmit the last of its information signals. By so doing, the extra bus grant cycle is not wasted when pipelining is not performed.
Brief Description of the Drawings
Fig. 1 is a general block diagram of the system of the present invention.
Fig. 2 is a timing diagram of a bus coordination system which does not implement pipelining. Fig. 3 is a timing diagram of the bus coordination system of the present invention illustrating the process of pipelining consecutive bus requests.
Fig. 4 is a flow diagram for the source interface state machine associated with each node.
Fig. 5 is a flow diagram for the node interface state machine of the bus access coordinator.
Fig. 6 is a flow diagram of the pipelining process as implemented by the system of the present invention.
Detailed Description of the Preferred Embodiments With reference to Fig. 1, there is shown a general block diagram of the system 10 of the present invention, wherein the system 10 preferably comprises a system bus 12, a plurality of nodes 14ι-14n coupled to and sharing the bus 12, and a bus access coordinator 16 coupled to the nodes 14* [-14n. Each of the nodes 14 may represent a device which generates and sends information signals, or a port through which information signals may be sent. Because a plurality of nodes 14 are coupled to the same bus 12, a mechanism is needed for coordinating access to the bus by the nodes 14 in order to prevent bus contention. Coordinator 16 serves this purpose.
To gain access to the bus 12, a node 14 first sends an asserted bus request signal to coordinator 16 to request permission to control the bus 12. If multiple bus request signals are simultaneously received by coordinator 16, as will often be the case, the coordinator 16 carries out an arbitration scheme to determine which node should be granted control of the bus 12. The arbitration scheme may be a round-robin type of fairness scheme or some other type of scheme. After it is determined which node 14 should get control of the bus 12, coordinator 16 sends an asserted bus grant signal to the selected node (nodel 14 j , for example) to grant control of the bus 12 to that node. After gaining control of the bus 12, the selected node 14] may send information signals onto the bus.
After granting control of the bus 12 to a selected node 14] , the coordinator 16 monitors the bus request signal from that node 14] to determine whether the signal is still asserted. If the bus request signal remains asserted, then it means that the node \4\ is still using the bus; thus, coordinator 16 maintains the bus grant signal in the asserted state. However, if the bus request signal becomes deasserted, then coordinator can conclude that node 14*ι no longer needs the bus; thus, coordinator 16 can deassert the bus grant signal to take control of the bus 12 away from the selected node 14ι . Because the bus grant signal tracks the bus request signal, the bus request signal is used by a node 14 not only to request access to the bus 12 but also to retain ownership of the bus 12. Using the same signal for both purposes simplifies the design of system 10.
In regular operation, the bus access coordinator 16 probably receives and processes a multiplicity of bus requests at a time so that it alternatingly grants the system bus 12 to a
A number of different nodes. There are times, however, when coordinator 16 repeatedly grants control of the bus 12 to the same node. This may be due to the fact that only one node is actively and repeatedly requesting the bus, or it may be due to priority considerations, time slice considerations, or priority/time slice considerations. Whatever the reason, it would be desirable during such times for coordinator 16 to pipeline the bus requests from the node to minimize "dead time" on the bus 10, thereby maximizing bus utilization.
In the system of the present invention, pipelining is provided for by having coordinator 16 maintain the bus grant signal in the asserted state for at least one extra clock cycle after deassertion of the bus request signal is detected. As discussed above, the bus grant signal tracks the bus request signal. As long as the bus request signal remains asserted, the bus grant signal also remains asserted. But as soon as deassertion of the bus request signal is detected, the coordinator is free to deassert the bus grant signal to wrest control of the bus 12 away from the node. In the present invention, instead of deasserting the bus grant signal as soon as deassertion of the bus request signal is detected, the coordinator 16 preferably maintains the bus grant signal in the asserted state for an extra clock cycle after deassertion of the bus request signal is detected. This extra clock cycle gives the node time to reassert the bus request signal (thus, making another bus request) before the bus grant signal changes states. If the bus request signal is reasserted before the extra clock cycle expires (and if the bus is once again granted to the node), then the node gains another tenure on the bus 12 without having the bus grant signal change states. Thus, ownership of the bus is continuous, which means that "dead time" on the bus is eliminated. Consecutive bus requests are thus pipelined.
To elaborate upon the concept of pipelining, reference is made to Fig. 2, wherein a timing diagram is provided of a bus coordination system which does not pipeline. In the system of Fig. 2, the requesting node asserts its bus request signal at the beginning of clock cycle 1 to request access to the bus. Assuming that the requesting node is granted the bus, the bus grant signal is asserted as soon as the asserted bus request signal is detected, namely, at the beginning of cycle 2. In cycles 3-6, the node has control of the bus; thus, during this time period, the node sends data onto the bus. As the last clock cycle of data is sent, the node deasserts its request signal to indicate that it is now finished using the bus. The coordinator detects the deassertion of the request signal at the beginning of cycle 7 and, in response, it deasserts the grant signal during cycle 7.
Suppose now that after deasserting the request signal in cycle 6, the node decides that it needs another tenure on the bus. To request another bus tenure, the node reasserts the request signal at the beginning of cycle 7. This reassertion of the request signal, however, is not detected by the coordinator in cycle 7 but in cycle 8. This means that the coordinator will deassert the grant signal in cycle 7 and then reassert the grant signal in cycle 8 so that the grant signal changes states. The consequence of having the grant signal change states is that "dead time" is imposed on the bus as shown in Fig. 2. During this "dead time", no node has control of the bus and no information transfer is conducted on the bus. Thus, valuable bus time is wasted.
Pipelining consecutive bus requests eliminates the dead time between bus requests. To elaborate upon this point, reference is made to Fig. 3, wherein a timing diagram for the system of the present invention is provided. In accordance with the present invention, a requesting node (nodel 14j, for example) asserts its bus request signal at the beginning of clock cycle 1 to request control of the bus. This request signal is detected by coordinator 16 in cycle 2 and, assuming that the bus 12 is granted to nodel, the bus grant signal is asserted in cycle 2. During cycles 3-6, nodel has control of the bus 12; thus, during this time period, data may be transmitted from nodel onto bus 12. At the beginning of cycle 6, nodel deasserts the request signal to indicate that it no longer needs the bus. The deassertion of the request signal is detected by coordinator 16 at the beginning of cycle 7 and, typically, the grant signal would be deasserted in cycle 7. However, the coordinator 16 of the present invention maintains the grant signal in the asserted state for one extra clock cycle. Thus, the grant signal, if deasserted at all, will not be deasserted until cycle 8.
Suppose now that after deasserting the request signal in cycle 6, nodel decides that it needs another bus tenure. To request another tenure on the bus 12, nodel reasserts the request signal in cycle 7. This reassertion of the request signal is detected by coordinator 16 at the beginning of cycle 8. Recall that because the request signal was deasserted in cycle 6, the bus grant signal was due to be deasserted in cycle 8. However, by the beginning of cycle 8, the request signal has already been reasserted, which indicates to coordinator 16 that another bus tenure is desired. When the coordinator 16 detects in cycle 8 that the request signal has been reasserted, the coordinator 16 does not deassert and reassert the grant signal, but instead simply maintains the grant signal in the asserted state to grant nodel another bus tenure. Hence, between the first and second bus requests, the bus grant signal does not change states. Since the bus grant signal does not change states, no "dead time" is imposed on the bus 12. Consecutive bus requests from a single node are thus pipelined.
While pipelining consecutive bus requests improves bus utilization efficiency, adding an extra bus grant cycle to every bus grant may offset any gain in efficiency unless that extra cycle is used productively. To put the extra grant cycle to good use, each requesting node in the system of the present invention preferably sends information signals onto the bus during the extra grant cycle. To clarify this point, notice that in Fig. 3, the request signal is deasserted at the beginning of cycle 6 but that data is sent onto the bus 12 through cycle 7. Likewise, the request signal is deasserted at the beginning of cycle 11 but data is transmitted onto bus 12 through cycle 12. Usually, a node sends its last clock cycle of information as it is deasserting its request signal. In the present invention, however, the node preferably deasserts its request signal and then one clock cycle later, transmit its last clock cycle of information as shown in Fig. 3. The requesting node can do this because it knows that the bus grant signal will remain asserted for an extra cycle after deassertion of the request signal is detected. By deasserting the request signal one clock cycle before it sends its last set of information, and by continuing to send information signals onto the bus 12 during the following cycle, the requesting node ensures that the extra grant cycle is not wasted. Thus, the system of the present invention provides the best of both worlds. It allows for pipelining by providing for an extra bus grant cycle while, at the same time, ensuring that the extra grant cycle is used productively.
In order to implement the method of the present invention, each node 14 preferably comprises a source interface for deasserting the bus request signal one clock cycle early, and the bus coordinator 16 preferably comprises at least one node interface for maintaining the bus grant signal to a node in the asserted state for one extra clock cycle. In the preferred embodiment, coordinator 16 preferably comprises a plurality of node interfaces, each node interface corresponding to one of the nodes 14. Preferably, these interfaces take the form of state machines, but it should be noted that these interfaces may also be implemented by other equivalent means such as software and the like. To aid in further describing these interfaces, a flow diagram for the source interface state machine of each node is provided in Fig. 4, and a flow diagram for the node interface state machine of the coordinator 16 is provided in Fig. 5.
With reference to Fig. 4, the source interface state machine begins operation by determining 20 whether the node has any information signals to send. If not, the source interface continuously cycles until the node has information signals to send. When the node has information signals to send onto the bus 12, the source interface asserts 22 the bus request signal and sends this signal to the coordinator 16 to request control of the bus 12. Thereafter, the source interface waits 24, 26 for a bus grant signal from coordinator 16. When the bus grant signal is received, the interface knows that it has control of the bus and that it can begin transmitting information signals onto the bus 12. The source interface begins the transmitting process by determining 28 how many clock cycles will be needed in order to transmit all of the information signals. Using the number derived in step 28, the source interface derives 30 the number (n) of clock cycles that the request signal should remain asserted after the bus grant signal is received. Preferably, the number n is equal to the number of cycles needed to transmit the information minus two so that the request signal is deasserted two clock cycles before transmission of the information is complete. To put it another way, the node preferably deasserts the request signal one clock cycle before it sends the last portion of its information signals. After deriving n, the source interface determines 32 whether an n number of clock cycles has elapsed. If not, the interface sends 38 the next clock cycle of information onto the bus 12 and loops back to step 32. If an n number of clock cycles has elapsed, then the source interface deasserts 34 the request signal and, thereafter, sends 36 the last two clock cycles of information onto the bus 12. The interface then loops back to step 20 for another set of information. By operating in the manner described above, the source interface causes information signals to be sent onto the bus 12 during the extra bus grant cycle. By so doing, the interface ensures that the extra grant cycle provided by the coordinator 16 will be used productively.
With reference to Fig. 5, the node interface state machine of the coordinator 16 will now be described. The node interface begins operation by receiving 40 a bus request signal from the node to which it corresponds (nodel, for example). This bus request signal (along with the other bus request signals received from the other nodes by other node interfaces) is passed on to the coordinator 16. The coordinator 16 performs an arbitration procedure on the various request signals received and determines which node should receive control of the bus 12 next. If coordinator 16 determines that nodel should be the next node to own the bus, then the node interface sends 44 an asserted bus grant signal to nodel to grant control of the bus 12 to nodel . Once the bus grant signal is sent, the node interface monitors 46 the status of the request signal from nodel. If the request signal continues to be asserted, then the node interface maintains 48 the bus grant signal at the asserted state. But, if the node interface detects that the request signal has been deasserted, then it will maintain 50 the bus grant signal in the asserted state for one extra clock cycle. Thereafter, the node interface checks 52 again the status of the request signal to determine whether the request signal has been reasserted (and hence, nodel is attempting to pipeline). If the request signal has not been reasserted, then the node interface deasserts 56 the bus grant signal to take control of the bus away from nodel. However, if the request signal has been reasserted and if coordinator 16 has again granted control of the bus to nodel, then the node interface maintains 54 the bus grant signal at the asserted level so that between the first and second bus requests, the bus grant signal does not change states. By maintaining the bus grant signal at the asserted state, the node interface allows the node (nodel) to pipeline consecutive requests.
With reference to the flow diagram provided in Fig. 6, the process of pipelining using the system of the present invention will now be described. For the purpose of illustration, it will be assumed that nodel is the node which wishes to pipeline consecutive bus requests. The pipelining process begins with the node interface corresponding to nodel receiving 60 an asserted bus request signal from nodel . In response, the node interface sends 62 an asserted bus grant signal to nodel to grant nodel control of the bus 12. Once it has ownership of the bus 12, nodel begins sending 64 a first set of information signals onto the bus 12. One clock cycle before nodel sends the last portion of its information signals, nodel deasserts 66 the bus request signal but continues 68 to send two more clock cycles of information signals. The deassertion of the bus request signal is detected 70 by the node interface and, in response, the node interface maintains 72 the bus grant signal in the asserted state for one extra clock cycle after deassertion of the request signal is detected. While the bus grant signal is maintained by the node interface, nodel reasserts 74 the bus request signal to request another tenure on the bus 12. If the request signal is reasserted before the extra bus grant cycle elapses, then the node interface maintains 76 the bus grant signal in the asserted state to grant nodel another tenure on the bus 12. The bus grant signal does not experience a state change between the two bus tenures. The two bus requests from nodel are thus pipelined. After being granted the second bus tenure, nodel proceeds to transmit 78 another set of information signals onto the bus 12. The process described above may be repeated to pipeline any number of consecutive bus requests. As the invention has thus far been described, the node interface of the coordinator 16 maintains the bus grant signal in the asserted state for one extra clock cycle and the source interface deasserts the bus request signal one clock cycle early. It should be noted, however, that the present invention may be implemented by having the node interface maintain the bus grant signal for two extra clock cycles and by having the source interface deassert the request signal two clock cycles early. In fact, the invention may be implemented using any desired number of clock cycles. This and other modifications are within the scope of the present invention.

Claims

What is claimed is:
1. A method for coordinating access to a bus, comprising the steps of: receiving an asserted request signal from a node; sending an asserted bus grant signal to said node to grant control of said bus to said node; monitoring said request signal to detect any deassertion of said request signal; and in response to a deassertion of said request signal, maintaining said bus grant signal in an asserted state for at least one clock cycle after deassertion of said request signal is detected.
2. The method of claim 1 , further comprising the steps of: determining whether said request signal has been reasserted; and in response to a determination that said request signal has been reasserted, maintaining said bus grant signal in the asserted state after said clock cycle has elapsed.
3. The method of claim 1 , further comprising the steps of: determining whether said request signal has been reasserted; and in response to a determination that said request signal has not been reasserted, deasserting said bus grant signal.
4. A method for transmitting information signals onto a bus, comprising the steps of: receiving an asserted bus request signal from a node; sending an asserted bus grant signal to said node to grant control of the bus to said node; transmitting information signals from said node onto said bus; deasserting said bus request signal before transmitting a last portion of said information signals; continuing to transmit said information signals after said bus request signal is deasserted; detecting the deassertion of said bus request signal; and maintaining said bus grant signal in an asserted state for at least one clock cycle after deassertion of said bus request signal is detected.
5. The method of claim 4, further comprising the steps of: determining whether said bus request signal has been reasserted; and in response to a determination that said bus request signal has been reasserted, maintaining said bus grant signal in the asserted state after said clock cycle has elapsed.
6. The method of claim 4, further comprising the steps of: determining whether said bus request signal has been reasserted; and in response to a determination that said bus request signal has not been reasserted, deasserting said bus grant signal.
7. The method of claim 4, further comprising the steps of: reasserting said bus request signal while said bus grant signal is maintained at the asserted state; continuing to maintain said bus grant signal at the asserted state after said clock cycle elapses so that said bus grant signal experiences no change in state between the deassertion and reassertion of said bus request signal; and transmitting a second set of information signals from said node onto said bus.
8. A bus system, comprising: a bus; a node coupled to said bus; and a bus coordinator coupled to said node for coordinating access to said bus by said node, said coordinator receiving an asserted request signal from said node and, in response, said coordinator sending an asserted bus grant signal to said node to grant control of said bus to said node, said coordinator further monitoring said request signal to detect any deassertion of said request signal, and in response to a deassertion of said request signal, said bus coordinator maintaining said bus grant signal in an asserted state for at least one clock cycle after deassertion of said request signal is detected.
9. The system of claim 8, wherein said coordinator further determines whether said request signal has been reasserted, and in response to a determination that said request signal has been reasserted, said coordinator maintaining said bus grant signal in the asserted state after said clock cycle has elapsed.
10. The system of claim 8, wherein said coordinator further determines whether said request signal has been reasserted, and in response to a determination that said request signal has not been reasserted, said coordinator deasserting said bus grant signal.
11. The system of claim 8, wherein said node, after receiving said asserted bus grant signal from said coordinator, transmits information signals onto said bus, said node deasserting said request signal before transmitting a last portion of said information signals and continuing to transmit said information signals even after said bus request signal has been deasserted.
12. A bus system, comprising: a bus; a node coupled to said bus; and a bus coordinator coupled to said node for coordinating access to said bus by said node; wherein said coordinator receives an asserted bus request signal from said node, and in response, sends an asserted bus grant signal to said node to grant control of said bus to said node, said node then transmitting information signals onto said bus, deasserting said bus request signal before transmitting a last portion of said information signals, and continuing to transmit said information signals after said bus request signal is deasserted, said coordinator thereafter detecting the deassertion of said bus request signal, and in response maintaining said bus grant signal in an asserted state for at least one clock cycle after deassertion of said bus request signal is detected, said node reasserting said bus request signal while said bus grant signal is maintained at the asserted state and, in response, said coordinator continuing to maintain said bus grant signal at the asserted state after said clock cycle elapses so that said bus grant signal experiences no change in state between the deassertion and reassertion of said bus request signal, and thereafter, said node transmitting a second set of information signals onto said bus.
PCT/US1995/000647 1994-01-25 1995-01-20 Method and system for pipelining bus requests WO1995020190A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU16820/95A AU1682095A (en) 1994-01-25 1995-01-20 Method and system for pipelining bus requests

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/186,381 1994-01-25
US08/186,381 US5473762A (en) 1994-01-25 1994-01-25 Method and system for pipelining bus requests

Publications (1)

Publication Number Publication Date
WO1995020190A1 true WO1995020190A1 (en) 1995-07-27

Family

ID=22684727

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1995/000647 WO1995020190A1 (en) 1994-01-25 1995-01-20 Method and system for pipelining bus requests

Country Status (3)

Country Link
US (1) US5473762A (en)
AU (1) AU1682095A (en)
WO (1) WO1995020190A1 (en)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06337843A (en) * 1993-05-28 1994-12-06 Fujitsu Ltd Data transfer control method
US5574867A (en) * 1994-07-08 1996-11-12 Intel Corporation Fast first-come first served arbitration method
US6029217A (en) * 1994-10-03 2000-02-22 International Business Machines Corporation Queued arbitration mechanism for data processing system
EP0718772A1 (en) * 1994-12-14 1996-06-26 International Business Machines Corporation Method to improve bus latency and to allow burst transfers of unknown length
US5815676A (en) * 1995-04-28 1998-09-29 Apple Computer, Inc. Address bus arbiter for pipelined transactions on a split bus
US5901295A (en) * 1995-04-28 1999-05-04 Apple Computer, Inc. Address and data bus arbiter for pipelined transactions on a split bus
US5592631A (en) * 1995-05-02 1997-01-07 Apple Computer, Inc. Bus transaction reordering using side-band information signals
USRE38428E1 (en) 1995-05-02 2004-02-10 Apple Computer, Inc. Bus transaction reordering in a computer system having unordered slaves
US5933612A (en) * 1995-05-02 1999-08-03 Apple Computer, Inc. Deadlock avoidance in a split-bus computer system
US5996036A (en) * 1997-01-07 1999-11-30 Apple Computers, Inc. Bus transaction reordering in a computer system having unordered slaves
US5634013A (en) * 1995-05-03 1997-05-27 Apple Computer, Inc. Bus bridge address translator
US5671369A (en) * 1995-12-22 1997-09-23 Unisys Corporation Bus grant overlap circuit
US5793994A (en) * 1996-01-31 1998-08-11 3Com Corporation Synchronous event posting by a high throughput bus
US5815674A (en) * 1996-07-15 1998-09-29 Micron Electronics, Inc. Method and system for interfacing a plurality of bus requesters with a computer bus
US5930485A (en) * 1997-01-07 1999-07-27 Apple Computer, Inc. Deadlock avoidance in a computer system having unordered slaves
US6473816B1 (en) * 1997-12-04 2002-10-29 Canon Kabushiki Kaisha Apparatus and method for determining bus use right
US6374319B1 (en) * 1999-06-22 2002-04-16 Philips Electronics North America Corporation Flag-controlled arbitration of requesting agents
US6810455B2 (en) * 2001-09-28 2004-10-26 Cradle Technologies, Inc. Bus arbitration system and method for carrying out a centralized arbitration with independent bus request and grant lines
US7302508B2 (en) * 2003-06-10 2007-11-27 Via Technologies, Inc. Apparatus and method for high speed data transfer
US8185680B2 (en) * 2006-02-06 2012-05-22 Standard Microsystems Corporation Method for changing ownership of a bus between master/slave devices
GB2447690B (en) * 2007-03-22 2011-06-08 Advanced Risc Mach Ltd A Data processing apparatus and method for performing multi-cycle arbitration

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0450233A2 (en) * 1990-03-07 1991-10-09 Dell Usa L.P. Bus access for digital computer system

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5289583A (en) * 1990-10-19 1994-02-22 International Business Machines Corporation Bus master with antilockup and no idle bus cycles
US5255376A (en) * 1992-01-14 1993-10-19 Sun Microsystems, Inc. Method and apparatus for supporting a dual bit length protocol for data transfers
US5280623A (en) * 1992-03-04 1994-01-18 Sun Microsystems, Inc. Versatile peripheral bus

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0450233A2 (en) * 1990-03-07 1991-10-09 Dell Usa L.P. Bus access for digital computer system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Processor bus arbitration with dead cycles", IBM TECHNICAL DISCLOSURE BULLETIN, vol. 32, no. 8A, January 1990 (1990-01-01), NEW YORK, US, pages 451 *
BERGEY AND COALE: "Method for decreasing arbitration overhead", IBM TECHNICAL DISCLOSURE BULLETIN, vol. 26, no. 7A, December 1983 (1983-12-01), NEW YORK, US, pages 3370 - 3371 *
BLUM: "Look-ahead access request circuit for computer systems", IBM TECHNICAL DISCLOSURE BULLETIN, vol. 22, no. 3, August 1979 (1979-08-01), NEW YORK, US, pages 1059 - 1060 *

Also Published As

Publication number Publication date
US5473762A (en) 1995-12-05
AU1682095A (en) 1995-08-08

Similar Documents

Publication Publication Date Title
US5473762A (en) Method and system for pipelining bus requests
US4969120A (en) Data processing system for time shared access to a time slotted bus
US4363094A (en) Communications processor
EP0737925B1 (en) Pipelined distributed bus arbitration system
US5764927A (en) Backplane data transfer technique for industrial automation controllers
US5745708A (en) Method for and apparatus for operating a local communications module in arbitrating for mastership of a data transfer across a back plane bus in industrial automation controller
US7437495B2 (en) Method and apparatus for assigning bus grant requests
EP1197870A2 (en) Method and apparatus for unique address assignment, node self-identification and topology mapping for a direct acyclic graph
JPH0664563B2 (en) Method for allocating access to data processing resources and arbitrator therefor
US5805837A (en) Method for optimizing reissue commands in master-slave processing systems
US5548733A (en) Method and apparatus for dynamically controlling the current maximum depth of a pipe lined computer bus system
US6434638B1 (en) Arbitration protocol for peer-to-peer communication in synchronous systems
CA1275328C (en) Apparatus and method for responding to an aborted signal exchange between subsystems in a data processing system
US5881247A (en) System having a plurality of frame bytes capable of identifying addressed recipients and assert a busy signal onto the backplane bus to forthrightly abort the message transfer
US5680554A (en) Method and apparatus for arbitrating among processors for access to a common bus
US5905878A (en) Method for controlling access to a computer bus
US6826644B1 (en) Peripheral component interconnect arbiter implementation with dynamic priority scheme
WO1995020191A1 (en) System and method for coordinating access to a bus
US6571306B1 (en) Bus request mechanism for bus master which is parked on a shared bus
US6009477A (en) Bus agent providing dynamic pipeline depth control
US5241629A (en) Method and apparatus for a high performance round robin distributed bus priority network
US5557755A (en) Method and system for improving bus utilization efficiency
JP2000134282A (en) Device and method for arbitration system on limited basis
JPS61848A (en) Bus selection system for decentralized control system
JPS59231952A (en) Communication control system between multiprocessors

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AM AT AU BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU JP KE KG KP KR KZ LK LR LT LU LV MD MG MN MW MX NL NO NZ PL PT RO RU SD SE SI SK TJ TT UA UZ VN

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE MW SD SZ AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase

Ref country code: CA

122 Ep: pct application non-entry in european phase