WO2011018109A1

WO2011018109A1 - Label and piggyback based high-speed bus

Info

Publication number: WO2011018109A1
Application number: PCT/EP2009/060457
Authority: WO
Inventors: Yan Fei Guo
Original assignee: Nokia Siemens Networks Oy
Priority date: 2009-08-12
Filing date: 2009-08-12
Publication date: 2011-02-17

Abstract

A method, device and bus system for conveying a packet via a label and piggyback based high-speed bus system are provided, wherein the packet comprises a label field indicating a destination address, a source address and a sequence number information. In addition, information of a subsequent packed is inserted in the information body of its previous packet using a piggyback approach.

Description

LABEL AND PIGGYBACK BASED HIGH-SPEED BUS

The invention relates to a method and to a device for convey^¬ ing a packet via a bus system.

With a rapid development of transport networks, the required bandwidth in operator transport networks is currently growing by 80% to 200% each year. Third generation networks will further increase such growth leading to a bandwidth requirement in the order of, e.g., 100 Gbps.

Such an increase of bandwidth introduces a significant chal^¬ lenge for network standards as well as packet processing equipment .

To provide high-speed packet processing equipment, a transfer mechanism of an interconnection bus may become a significant bottleneck. In a multi-core system, the interconnection bus is responsible for storing and forwarding packets at a rate of 100 Gbps and provides communication paths for all inter^¬ connected cores, including embedded CPUs, micro packet pars^¬ ers, hardware accelerators, local and external memories, etc. Hence, the success of upcoming equipment meeting the in^¬ creased data rates depends on a bus transfer mechanism.

The problem to be solved is to overcome the disadvantages stated above and in particular to provide an efficient solu^¬ tion for a transfer mechanism of a bus system. This problem is solved according to the features of the inde^¬ pendent claims. Further embodiments result from the depending claims .

In order to overcome this problem, a method for conveying a packet via a bus system is suggested, wherein said packet comprises a label field indicating a destination address, a source address and a sequence number information. The bus system may be a multi-core bus system connecting at least one bus master (also referred to as master) with at le^¬ ast one bus slave (also referred to as slave) . Such connec^¬ tion may be direct or via an intermediate component, e.g., an interconnect switcher.

It is noted that in particular several packets may be con^¬ veyed via the bus system. Packets may be associated with a particular transaction and thus the sequence number informa- tion for such transaction may indicate an order of packets for this transaction. Hence, in case the packets of this transaction arrive in a wrong order at a destination (or an intermediate component) , the packets may be re-sorted accord^¬ ing to their sequence numbers.

It is noted that the sequence number information may be an absolute sequence number of a relative information that al^¬ lows determining the sequence of the packets within a par^¬ ticular context.

The packet may also be referred to as cell. In general, the packet or cell is a unit that is used for communication pur^¬ poses over the bus system. The packets are preferably autonomous and can be processed independently from one another. In particular, packets of va^¬ rious transactions can be conveyed via the bus system. This enables a high degree of parallel processing by the bus sys^¬ tem. In addition, the bus system does not have to wait in an idle state for an acknowledgment of one particular packet; instead, the bus system can convey packets even if the previ^¬ ously sent packet has not yet been acknowledged. This sig^¬ nificantly improves the efficiency of the bus system sug^¬ gested compared to existing solutions.

Advantageously, the pins of the bus system can be flexibly used for conveying such packets. The bus system allows for an optimized performance by utiliz^¬ ing a high degree of parallelism and a high efficiency by re^¬ ducing the amount of bytes carrying no information at all. The packets can be transmitted via different channels in a fully parallel and unaligned manner.

The packets of one transaction can be unaligned and transmit^¬ ted or received out of the order.

It is also an advantage that transactions to different compo^¬ nents (masters or slaves of the bus system) may not affect each other, even if the components provide different data ra^¬ tes .

The packets may be transmitted in an interleaved fashion the^¬ reby avoiding packets from stalling because of a low trans^¬ mission rate. It is a further advantage that the approach provided intro^¬ duces a flexibility of protocol-oriented serial data networks to bus systems. The flexible architecture suggested allows for a high scalability: A width of the bus system can be dif^¬ ferent at various interfaces of a bridge or an interconnect- ing switch. The bus system can be implemented with different bus widths providing the same functional behavior. This al^¬ lows for devices from low-end performance up to high-end per^¬ formance being based on the same basic architecture. It is also an advantage that the receiving side upon detec^¬ tion of an error may request for a re-transmission. This is a significant advantage over existing bus system, wherein a bus error may lead to a system crash. Hence, the solution provided herein allows designing the system much closer to its physical limits, which results in significant cost and per^¬ formance benefits. In an embodiment, the packet is processed towards the desti^¬ nation address.

In another embodiment, several packets are aligned according to their sequence number information and processed towards the destination address.

Hence, a transaction comprising several packets can be proc^¬ essed, e.g., by writing data obtained to a memory area.

In a further embodiment, the bus system is driven by a clock signal and/or the packet is conveyed with a checksum informa^¬ tion . Hence, this approach allows errors to occur on the bus sys^¬ tem. In case of an error, e.g., indicated by the checksum, the packet can be sent again. Such re-sending may be triggered pursuant to an indication that an error occurred. The bus system may be operated by a (common) clock signal.

In a next embodiment, the bus system utilizes at least one of the following channels:

- a control bus,

- a data bus,

- a response bus.

It is also an embodiment that the control bus, the data bus and/or the response bus are virtual channels, logical chan- nels and/or physical channels.

Hence, at least one of the control bus, the data bus, and the response bus may be a logical channel utilized via one physi^¬ cal communication means, e.g., bus or line(s) . It is also an option that said channels are (at least partially) separate physical channels, i.e. portions of said bus system. The control bus is used for conveying control information that could be associated with the packet. The data bus can be used for conveying payload information (in combination with the label field) . The response bus allows for receiving con- firmation and/or acknowledgments regarding a packet and/or a transaction (comprising several packets) .

The combination of the three channels allows utilizing the bus system via said packets in an efficient manner: The con- trol bus conveys control information; the data bus may convey the actual payload (including administrative information and the label field) and the response channels are used for pro^¬ viding acknowledgments. Hence, this separation of functional^¬ ities allows each channel to act independently from each other and in particular to support and/or enable a high degree of parallel processing. In addition, the data channel is utilized in a way to reduce or minimize a waste of resources (piggyback approach, see below) thereby further improving the benefit of this approach.

Pursuant to another embodiment, a data rate of a channel is adjusted via a flow control.

Such flow control can be an out-of-band flow control used to adjust a data transfer rate via a channel. In particular each channel and/or each transaction can be adjusted separately.

According to an embodiment, the packet comprises an informa^¬ tion body.

Said information body may be a field comprising payload data. Such payload data can be encapsulated in the packet (e.g., by means of fault and/or error detection) . According to another embodiment, information of a subsequent packet is inserted in the information body of its previous packet . This piggyback mechanism allows utilizing the information body of an actual packet in an efficient manner. If there is space left in a current packet, information from a subsequent packet may be inserted in order to avoid any unused bytes to be transmitted. This significantly improves the efficiency of the transmission.

In yet another embodiment, header information of the subsequent packet is inserted in the information body of its pre- vious packet.

According to a next embodiment, the bus system is a passive bus system or an active bus system providing a bridging functionality .

The bridging functionality may comprise forwarding packets between several transmitters and receivers in parallel in a non-blocking way. The problem stated above is also solved by a device compris^¬ ing or being associated with a processing unit that is arranged such that the method as described herein is executable thereon . Said processing unit may comprise at least one of the follow^¬ ing: a processor, a microcontroller, a hard-wired circuit, an ASIC, an FPGA, a logic device.

According to an embodiment, the device is a bus device, in particular a bus master, a bus slave or an interconnect swit^¬ cher of the bus system.

The problem stated supra is further solved by a bus system comprising the device as described herein.

Embodiments of the invention are shown and illustrated in the following figures: Fig.l shows a signal diagram visualizing a data transmis^¬ sion based on a handshake mechanism;

Fig.2 shows a signal diagram visualizing a bust data trans- fer mechanism on a byte level;

Fig.3 shows an exemplary format of an information cell;

Fig.4 shows various formats of information cell types;

Fig.5 shows a diagram visualizing a transmission scheme via the label bus comprising three channels;

Fig.6 shows an interconnection architecture of the label bus system comprising an interconnect switcher connecting masters and slaves;

Fig.7 shows a backpressure architecture of the label bus utilizing out-of-band interfaces for signaling per- mission to transmit cells over the associated chan^¬ nel (s) ;

Fig.8 shows an interconnection architecture comprising a master that is connected via an interconnect switcher to two slaves;

Fig.9A and Fig.9B show a signal diagram visualizing two writing transactions in a master interface; Fig.lOA and Fig.1OB show a signal diagram visualizing two writing transactions in a first slave interface;

Fig. HA and Fig. HB show a signal diagram visualizing two writing transactions in a second slave interface;

Fig.12 shows a timing diagram visualizing a back to back

transfer of short packets in a traditional bus sys^¬ tem; Fig.13 shows a timing diagram, wherein adjacent packets are transferred in a piggyback manner; Fig.14 shows redefined cells (for the cell types CIC, DIC and RIC) for supporting the piggyback mechanism;

Fig.15 shows a timing diagram visualizing a piggyback transmission of short packets;

Fig.16 shows a schematic block diagram of a master interface architecture;

Fig.17 shows a schematic block diagram of a slave interface architecture;

Fig.18 shows a schematic block diagram of an interconnect switcher architecture. In this solution, in particular a bus mechanism is introduced, also referred to as "label and piggyback based high^¬ speed bus (LPB)", in particular for multi-core interconnec^¬ tion and high-speed data transmitting purposes. Compared with existing bus systems, this proposed LPB can provide a 100 Gbps line-rate for packets transmitted in a multi-core system. At the same time, the LPB can be utilized for 200 Gbps or higher by increasing the bus width or the bus frequency. Furthermore, the proposed bus mechanism copes with existing and available hardware and software technologies.

A data transmission based on a handshake mechanism is shown in Fig.l. This approach is used in existing bus standards, e.g., Wishbone of Silicore, AMBA of ARM, and CoreConnect of IBM.

Fig.l shows a signal diagram comprising a clock (elk) signal, a grant signal, an address and control signal, a read/write (rw) signal, a data write (wdata) , a data read (rdata) and a response (ack) signal.

A bus master (also referred to as master) may communicate with at least one bus slave (also referred to as slave) . The master and the slave (s) may be devices with a bus interface for conveying data via said bus.

Based on a type of data transaction, e.g., a write transac- tion or a read transaction, the master requires an acknowledgment (ack) signal as feedback from the slave in order to make sure that the transmission has been successful and that the master can continue with the next transaction. It is noted that the ack signal may represent all necessary response signals transmitted by the slave.

According to the example of Fig.l, the master is in charge of the bus transmission and the slave responds to such a bus transmission. During the waiting period, including both the write waiting period and the read waiting period as shown in Fig.l, the master merely keeps the asserted address and con^¬ trol signals unchanged, even though other queued data may be ready for transmission. When slaves with a slow performance are involved, the amount of bus cycles wasted due to such waiting of the master becomes inacceptable . Hence, the hand^¬ shake mechanism severely limits the parallel transfer capa^¬ bility and significantly reduces the bus bandwidth and its efficiency .

Fig.2 shows a signal diagram depicting a burst data transfer mechanism on a byte level.

Fig.2 shows a clock (elk) signal, a grant signal, an address and control signal, a combined data write and data read (rda^¬ ta) signal (rdata/wdata) and a response (ack) signal. If a packet length cannot be aligned to the bus size (bus width) , a significant number of byte slots on the bus are un^¬ occupied during the period of data transfer. This situation further deteriorates when continuously back to back transmis- sion of the short and unaligned packets occurs as indicated in Fig .2.

In such a scenario, a huge number of data transfer slots are wasted. For example, if the bus size amounts to 512 bits (64 bytes) and the packet length amounts to 65 bytes, slots amounting to 64 bytes are lost every two transfers as shown right hand in Fig.2. This may result in a poor efficiency utilizing the bus mechanism. Hence, existing handshake and bytes burst mechanisms of mul^¬ ti-core bus systems are main bottlenecks, which prevent the core net equipment from achieving the required high-speed performance . Hereinafter, a bus mechanism for high-performance multi-core equipments is introduced that allows for a fast and efficient communication .

In order to provide a high performance bus, it may be focused on a level of packet transmission or on a byte level.

In particular, a label-based full parallel mechanism and a piggyback-based transfer mechanism are introduced. The con^¬ cept provided allows for a high degree of parallelism, a high efficiency and a high throughput of the bus.

Label-based full parallel bus transfer mechanism

In order to eliminate (or at least reduce) the waiting period and to improve the parallelism of data transmission, a label- based parallel bus mechanism is suggested (also referred to as "label bus" hereinafter) . With regard to a transfer method of packets in an MPLS (Mul^¬ tiprotocol Label Switching) network, the label bus may sepa^¬ rate the original bundle of bus signals into three different transfer channels and it may in particular independently transmit dedicated information cells via these channels with^¬ out any need for a handshake mechanism to be provided.

It is noted that cell refers to a portion of data or to a pa^¬ cket, wherein the cell may comprise payload (user) informa- tion and overhead (administrative or signaling) information. Several cells may be combined to a transaction; in other words, a transaction could be split into several cells.

The channels mentioned may utilize at least one virtual or physical line or channel. The channels may be realized as virtual channels and/or could be combined on a single physi^¬ cal channel. In particular, each such channel could be real^¬ ized as a physical channel. The cells could be distributed among said three channels and may be provided with a label that can be used to identify each cell and in particular such label can be used to determine the transaction the cell is associated with. Based on this label attached, local devices (comprising, e.g., the master, the slave and an arbiter of the bus system) can identify these cells and then align and process them as a single data transaction. The cells can be automatically transmitted over the channels without any assistance or in- formation from any other channel. Hence, the label bus does no longer require a handshake mechanism.

Information Cell Formats A format of the information cell is shown in Fig.3. The in^¬ formation cell comprises a label field and an information bo^¬ dy field. The label field further comprises a destination identification (ID) and a source ID, indicating the destination and the source devices of the cell.

In the label bus system, every device (in particular, every interface deployed with a master or a slave of the bus) may have a unique global identification (ID) . A content is con^¬ veyed via the information body field.

According to different contents, the following types of cells could be determined:

(1) Control Information Cell (CIC) : This type of cell com^¬ prises control and address information of the current data transaction in its information body field.

(2) Data Information Cell (DIC) : This type of cell comprises data to be transferred by the current data transaction in its information body field. (3) Response Information Cell (RIC) : This type of cell com^¬ prises response results for the current data transaction in its information body field.

Further details regarding the types of cells are shown in

Fig.4. An exemplary description regarding these types of cells is listed in the tables below.

Cell-type = CIC; Direction: From master to slave

Cell-type = DIC

The direction is either from master to slave for writing purposes or from slave to master for reading purposes.

Cell-type = RIC; Direction: From slave to master

Transfer Channels

Traffic channels can be used to transmit the above defined information cells:

[I) Control & Address Transfer Channel (CATC) : This channel can be used for a transmission of control and address information for a current data transaction by using the control cells. On this channel, control cells are trans^¬ mitted from the master (interface) to the slave (inter^¬ face) with the master ID as the source ID and the slave ID as the destination ID.

(2) Data Transfer Channel (DTC) : This channel can be used for a data transmission of the current data transaction by using the data cells. In general, two data transfer channels can be configured separately for the read transaction and for the write transaction between the master interface and the slave interface. In case of the write DTC, data cells are transmitted from the master interface to the slave interface with the master ID as the source ID and the slave ID as the destination ID. In case of the read DTC, data cells are transmitted from the slave interface to the master interface with the slave ID as the source ID and the master ID as the des^¬ tination ID.

(3) Response Transfer Channel (RTC) : This channel can be

used for a transmission of response results providing feedback from the slave interface by using the response cell. On this channel, the source ID and the destination ID of transmitted cells can be assigned to the slave ID and the master ID separately.

The cells of one transaction can be assigned an "equivalent label" irrespective of the channel over which each cell of such transaction is transmitted.

If the source IDs and destination IDs indicate the same pair of master and slave, the corresponding labels may be consid^¬ ered as "equivalent label", i.e. the corresponding cells may belong to the same transaction.

A data transaction may comprise a data communication (trans^¬ mission of packets) between the same master and slave and it may comprise several data transfers distributed among the channels as mentioned.

The transmission architecture of the label bus based on the channels is shown in Fig.5. According to Fig.5, various mas^¬ ters 550 are connected to various slaves 551 via a bus. The bus is capable of conveying cells via channels, wherein in Fig.5 a CATC 501, a DTC 502 and a RTC 503 are shown. Via the CATC 501, three cells 504 to 506 for a first transac^¬ tion and three sells 507 to 509 for a second transaction are transmitted from the masters 550 to the slaves 551.

Via the DTC 502, for a write transaction, three cells 510 to 512 of a first transaction and three cells 513 to 515 of a second transaction are conveyed from the masters 550 to the slaves 551. For a read transaction, three cells 516 to 518 of a first transaction and three cells 519 to 521 of a second transaction are conveyed from the slaves 551 to the masters 550. It is noted that the cells 518 and 519 are conveyed in the wrong order.

Via the RTC 503, for a write transaction, three cells 522 to 524 of a first transaction and three cells 525 to 527 of a second transaction are conveyed from the slaves 551 to the masters 550. For a read transaction, three cells 528 to 530 of a first transaction and three cells 531 to 533 of a second transaction are conveyed from the slaves 551 to the masters 550. It is noted that the cells 530 and 531 are conveyed in the wrong order.

Transmission rules may be as follows:

(a) The label bus suggested herein classifies and encapsu- lates the information that belongs to the same data transaction into different cells and then transmits these cells via the corresponding transfer channels. (b) The cell transmissions over the channels are independent from one another. In particular, no handshake signals and no fixed timing relationship are required. Hence, this flexible concept allows for the following:

(bl) The cells can be transmitted over different chan^¬ nels in a fully parallel and unaligned manner. As shown in Fig.5, the CATC 501 can send the control cells 504 to 509 continuously without having to wait for corresponding cells on any other channel.

(b2) Each channel may optimize its internal pipeline

stages by inserting or by utilizing registers in order to achieve a maximum frequency of operation.

(b3) The label bus supports an out-of-order completion of different transactions, referred to as "inter^¬ leaving transmission". As shown in Fig.5, the first cell 519 of the second read transaction is conveyed prior to the third cell 518 of the first read transaction .

This feature of labeling significantly increases the efficiency and performance of the label bus es- pecially with regard to the following scenarios: i) A master initiates multi data transactions to different destinations (i.e. to different slaves), wherein the destinations may have differences regarding their processing rate. ii) Multiple masters may initiate different rate transactions to one particular slave. The in^¬ terleaving feature may avoid a bottleneck situation caused by the slow transaction to this slave as the slow and the fast transac- tions may be interleaved and the whole

throughput of the label bus can thus be in^¬ creased. (c) The only tie that logically connects the cells distrib^¬ uted over different channels is the combination of the attached equivalent label and the order number of each cell. Based on such information, the local device (mas- ter or slave) is able to identify, buffer and realign all the received cells and then process the cells in a correct order for each data transfer by extracting the control & address information, data information and re^¬ sponse information from these aligned cells.

For example, for the write transaction, a slave may buffer the received control cells and data cells into different queues in order, then align them one by one in order to extract the control & address information for every corresponding data cell and then write each of the data segments to the correct memory areas.

(d) The cell transmission of the same data transaction

should be completed in the required order. However, with regard to cells that belong to different transactions, there may be no ordering restriction.

Interface and Interconnection architecture The typical label system may comprise several master and sla^¬ ve devices connected together via an interconnection compo^¬ nent referred as "interconnect switcher".

Fig.6 shows an interconnection architecture of the label bus system comprising an interconnect switcher 601 connecting masters 602 to 604 and slaves 605 to 608.

The label system provided comprises interfaces that may be deployed between

- a master and the interconnect switcher;

- a slave and the interconnect switcher; and/or

- a master and a slave. The interconnect switch may provide symmetrical master and slave ports to which the master and slave devices can be con^¬ nected. Hence, the interconnect switcher provides a transpar^¬ ent bridge for the connections of real master and slave pairs by toggling paths between its inner master-slave pairs and forwarding the cells between the real master and slave. The slave ports of the interconnect switcher may be connected to the master devices and the slave devices may be connected with the master ports of the interconnect switcher.

Flow Control Mechanism

According to the transfer mechanism of the label bus, the local devices may buffer the received cells from the channels before aligning and processing them.

In case the arrival rate of cells is higher than the process^¬ ing rate of the local device, the local buffer will eventu^¬ ally overflow and further cells will be discarded. In order to avoid such loss of cells, the label bus may be able to provide a signal that indicates such an overflow.

In order to provide such a function, an out-of-band control flow interface can be provided, e.g., for each channel. The out-of-band interface may use an on-off mechanism to signal permission to transmit the cells over the associated channel. A backpressure architecture of the label bus comprising such out-of-band interfaces is shown in Fig.7. Fig.7 shows a master interface 701 and a slave interface 702, both comprising symmetrical flow control interfaces with a flow control informer and receiver.

With regard to the CATC, the flow control informer of the slave interface 702 may convey a control channel flow control signal (CCFCS) to the flow control receiver at the master in^¬ terface 701. With regard to the DTC in the writing scenario, the flow con^¬ trol informer of the slave interface 702 may convey a data channel flow control signal (DCFCS) to the flow control re^¬ ceiver at the master interface 701. In case of the reading scenario, the flow control informer of the master interface 701 may convey a DCFCS to the flow control receiver at the slave interface 702.

With regard to the RTC, the flow control informer of the mas- ter interface 701 may convey a response channel flow control signal (RCFCS) to the flow control receiver at the slave in^¬ terface 702.

The symmetrical flow control interfaces comprising said flow control informer and receiver were added to support a flow backpressure for each channel. Each informer-receiver pair may convey the on-off flow control status with a single bit. For example, a logical value of "1" can be chosen to identify a "FL_ON" state indicating a permission for the cells to be sent on that channel and a logical value of "0" may identify a "FL_OFF" state indicating that sending cells should be cea^¬ sed as soon as possible on that channel.

Once the channel indicates FL_ON, the transmitter of that channel may send as much cells as possible until the flow control status is changed to FL_OFF .

The receiver may toggle between the states FL_ON and FL_OFF dependent on a threshold value that may be implemented as a programmable option. Hence, user requirements may set this threshold value. Also, a size of the receive buffer and/or a flow control latency of a particular application can be used to set this threshold value. Transmission Example

As an example, a packet transmission between one master and two slaves is described. Fig.8 shows an interconnection architecture comprising a mas^¬ ter 801 that is connected via an interconnect switcher 802 to a slave 803 and to a slave 804.

The example is based on the following conditions:

1) The master 801 initiates writing transactions 805, 806 to the slave 803 and to the slave 804.

2) In the transaction 805, a packet with a length of 196 bytes is transmitted from the master 801 to the slave 803. In the transaction 806, a packet with a length of 136 bytes is sent to the slave 804. The two packets transmitted with transactions 805 and 806 can be re^¬ ferred to as "Pkt_l" and "Pkt_2". In addition, a term Pkt_l [k] represents a k-th byte of the Pkt_l; the same definition applies to the Pkt_2 accordingly. 3) IDs assigned to the master 801, to the slave 803 and to the slave 804 are: "1", "2" and "3".

4) All data channels of the three interfaces have an iden^¬ tical configuration; the data cells used for conveying information may have a maximum size "Wdata" amounting to 512 bit.

5) Both transactions 805 and 806 have the same priority. 6) There is no lock transmission included in both transac^¬ tions 805, 806.

With regard to the writing transactions 805, 806, the process of sending information cells via the interface of the master 801 is shown in Fig.9A and Fig.9B. The corresponding process at the interface of the slave 803 is shown in Fig.1OA and

Fig.1OB and the corresponding process at the interface of the slave 804 is shown in Fig.llA and Fig.llB. Hence, for transaction 805, the label {Destination ID, Source ID} attached to the cells, which are transmitted over the CATC and the DTC is {2, 1}; conversely the label attached to cells transmitted on the RTC is {1, 2}. Similarly, for trans^¬ action 806, the corresponding assignment for labels is {3, 1} and {1, 3} .

In this example, the master 801 first conveys the transaction 805 and subsequently the transaction 806. The transmitting sequence of the cells with regard to the respective channels is shown in Fig.9A and Fig.9B.

Advantageously, there is no need for a fixed timing relation- ship for the cells transmitted via the various channels. In^¬ stead, the cells transmitted over these channels are inde^¬ pendent and autonomous. This allows for an insertion of reg^¬ ister slices to any channel thereby adjusting a trade-off be^¬ tween cycles of latency and a maximum frequency of operation.

For example, the cells sent over the DTC can be aligned or unaligned with the corresponding cells sent on the CATC.

In addition, as the cells are processed in an autonomous way, such transmission can utilize a high degree of parallel proc^¬ essing. As depicted in Fig.9A, 9B, no handshake mechanism is required. Hence, the cells can be pipelined freely for each channel and the flow of cells is not interrupted by any wait^¬ ing for handshake signals from other channels. For example, the second cells transmitted as the transaction 805 on both the CATC channel and the DTC channel do not have to wait for the completion of the first data transfer, which is identi^¬ fied by receiving the first response cell with an "OKEY" sta^¬ te. Thus, the feature completely eliminates the waste of bus cycles caused by the handshake mechanism resulting in the waiting period as shown in Fig.l. As shown in Fig.9A, 9B, after having finished the transaction 805 via the CATC in the fifth transfer cycle, the master 801 may immediately initiate another control cell transmitted over the CATC in the subsequent sixth cycle for the transac- tion 806. The master 801 does not have to wait for the trans^¬ fer or the transaction 805 to be completely finished (which is indicated by receiving the "OKEY" state in the response cell during the seventh cycle) . Hence, the transfer between different transactions can be processed in a seamless manner without the need for extra cycles consumed for waiting pur^¬ poses .

In addition, the cells may be completed in the correct order even if they arrive out of sequence in the wrong order. This out of sequence feature can be triggered in at least one of the following cases:

(1) For the master interface, it can do the out-of-order

transmission among multi parallel transactions, such as: (a) the lower priority transaction can be interrupted by the higher one;

(b) the transmitting transaction can be ceased by the flow control signal. (2) If there are multiple transactions with different rates coming from multiple masters, the out-of-order service can be adopted by the slave interface.

In general, the cells can be transmitted in an interleaving manner via the label bus system in particular comprising several multi-cores that are connected together. As shown in Fig.10 and Fig.11, the cycles in which cells are marked

"other potential transfer with other masters" indicate that other communication may occur during these cycles.

The label and the sequence number are attached in the header of each transmitted cell. Based on such information, masters and slaves can identify the cells belonging to the same tran- saction and then align and process them just as they would have been transmitted over a single path and arrived at the same time. Features of the label bus, overview

The label bus can provide the parallel transformation not on^¬ ly with regard to a single transaction, but also with regard to multiple transactions. Hence, the label bus provides ser- vices of a fully parallel bus.

Overall, the label bus provides in particular the following features : (1) Using three kinds of label-based independent channels and information cells, the label bus can transmit pack^¬ ets in a fully parallel manner.

(2) The label bus does not require a handshake mechanism and thus avoids wasting bus cycles.

(3) Each channel can independently utilize its own logic for achieving a maximum frequency of operations. Hence, the label bus supports a high degree of parallelism at a high performance.

A piggyback mechanism for packet transmission

The label bus mechanism suggested can be supplemented by a piggyback mechanism, which solves the problem of wasting transfer slots which stem from the fact that the length of packets is not aligned with the bus size.

The concept of piggyback is explained hereinafter. Fig.12 shows a timing diagram visualizing a back to back transfer of short packets in a traditional bus system. Fig.12 comprises a clock signal (elk), a control signal, an address signal, a data write signal (wdata) , an acknowledge^¬ ment (ack) signal and a response signal. According to this example, the size of each packet amounts to 65 bytes and the bus size amounts to 512 bit (equals

64 bytes) . Hence, each packet exceeds the bus size by only one byte. Therefore, two transfers are needed to complete the transmission of the packet of 65 bytes size, wherein the sec- ond transfer contains only one valid byte. In this example, the bus efficiency is very low and is reduced to almost 50%. However, practice shows that the back to back short packets transmission as described is a ubiquitous scenario of the network .

To increase the efficiency of the bus system, a piggyback me^¬ chanism is suggested, which utilizes the remaining space of the previous packet to transmit bytes of the next packet, in particular the header bytes of the next packet. In other words, unoccupied byte slots in a previous packet can be fil^¬ led with the header bytes of the next packet.

Based on such piggyback mechanism, the expected pattern of transferring back to back short packets is shown in Fig.13. Fig.13 is based on Fig.12 and comprises the same signal types as explained above.

Fig.13 shows that adjacent packets are transferred in a pig^¬ gyback manner. For example, the header of packet_2 is piggy- backed in the tail of packet_l, and the header of packet_3 is piggybacked in the tail of packet_2.

Based on the piggyback mechanism shown in Fig.13, the waste of bandwidth is significantly reduced compared to the example shown in Fig.12.

Hence, the label bus mechanism can be enhanced to support the piggyback mechanism. For example, some special information may be added to the data information cell and to the response information cell. Such special information may indicate:

- an identification of the piggyback transfer feature;

- a piggybacked data length;

- whether the previous piggyback transfer has been successfully completed (or not) .

Fig.14 shows redefined cells (for the cell types CIC, DIC and RIC as defined above) for supporting the piggyback mechanism. An exemplary description regarding these types of cells is listed in the tables below.

Cell-type = CIC; Direction: From master to slave

Cell-type = RIC; Direction: From slave to master

Compared to the cells shown in Fig.4, two sub-fields have been changed in the redefined control information cell of Fig.14. The field "LB_Lock" has been replaced by the field "LB_Type" and a field "PG_Len" has been added to the control cell. Besides, in the response cell the meaning of the field "RSP" has been redefined.

A Piggyback Transmission Example

An example is provided based on the label bus example de^¬ scribed above. In addition to the previous example, the pig^¬ gyback mechanism for back to back transmission of short packets is utilized. Differences to the example provided above are in particular as follows:

The master communicates with only one slave.

2) The master writes continuous 64 bytes short packets to the slave. 3) "Pkt_i" refers to the i-th packet. The packet is written to a continuous space, whose first address equals to i*128. For this example, cell sequences transmitted via the three channels between the master and the slave are shown in

Fig.15.

By using the piggyback approach, each data transfer portion is efficiently utilized. For example, the second transfer of data via the DTC contains the first 60 bytes of Pkt_2

("Pkt_2 [0] -Pkt_2 [59] ") and the last one byte of Pkt_l

("Pkt_l [64] ") ; the third transfer of data via the DTC contains the last four bytes of Pkt_2 and the first 60 bytes of Pkt_3, etc.

In case of the piggyback transfer, the control cell is pro^¬ vided with a destination address to which the piggybacked data of the next packet will be transmitted. However, the ad- dress to which the tail bytes of the current packet will be transmitted can be computed by the local devices based on the address included in the last transfer. For example, as shown in Fig.15, the first address, to which the first 60 bytes of the Pkt_2 will be continuously written to, is represented by the value "0x00_00_00_80" filled in the sub-field

"Addr_Offset " of the second control cell. For the last byte of the Pkt_l, the destination address should be

"0x00_00_00_40 " , which can be determined by adding the values filled in the "Addr_Offset " ( "0x00_00_00_00" ) and the

"LB_Size" ("0x40") sub-fields of the first control cell.

Based on the piggyback mechanism, data can be transmitted in a continuous pattern as long as enough queued packets are ready for transmission. Thus, transmission utilization can be significantly increased and may even reach 100%. Further Advantages

The bus approach proposed herein mainly comprises the label- based full parallel transmitting technology and the piggyback transmitting technology. Therefore, the proposed approach is also referred to as "label and piggyback based high-speed bus (LPB) ".

Advantageously, the LPB meets high-speed requirements of mul- ti-core systems applied in the packet processing equipments of next generation core networks. For example, with a "Wda- ta/Rdata" bus width of 512 bit and running at a frequency of about 195 MHz, the LPB may achieve a throughput for packet transmission amounting to 100 Gbps. This concept is open to scalability; hence, increasing the bus width to 1024 bit, the LPB may process 200 Gbps throughput while keeping the fre^¬ quency unchanged.

Also, the LPB concept suggested is compatible with existing technologies as it may utilize existing bus systems as trans^¬ port layers for the label mechanism.

Fig.16 shows an architecture for an exemplary implementation of the master interface, Fig.17 shows an architecture for an exemplary implementation of the slave interface and Fig.18 shows an architecture for an exemplary implementation of the interconnect switcher. Modules of each of the components shown in Fig.16 to Fig.18 are explained hereinafter: Master Interface:

Channel trans^¬ Responsible for transmitting and/or remitters/ re^¬ ceiving the cells to or from the associ^¬ ceivers ated channels bridging between the master interface and the destination slave in^¬ terface .

Channel flow Responsible for asserting or receiving control inter- the flow control states to or from the

Slave Interface:

Channel trans- Responsible for transmitting and/or remitters/ re- ceiving the cells to or from the associ^¬ ceivers ated channels bridging between the slave interface and the destination master interface .

Channel flow Responsible for asserting or receiving control inter- the flow control states to or from the faces flow control interfaces of the associated master interface.

Channel buff- Buffers information cells for each chaners nel .

Channel align- Aligns the associated control cell and ment data cell based on their attached label and "LB_ORDER_NUM" in order to allow the local device to process them as a single transfer event.

Local side in^¬ Translates the information contained in terface cells to information that can be identi^¬ fied by the local device; helps the de^¬ vice to provide the required services.

Central sched- Similar to the one implemented in the uler master interface. Interconnect Switcher:

List of Abbreviations :

CATC control & address transfer channel

CCFCS control channel flow control signal

CIC control information cell

CPU central processing unit

DCFCS data channel flow control signal

DIC data information cell

DTC data transfer channel

ID identification

LPB label and piggyback based high-speed bus

RCFCS response channel flow control signal

RIC response information cell

RTC response transfer channel

Claims

Claims :

1. A method for conveying a packet via a bus system,

- wherein said packet comprises a label field indicat^¬ ing a destination address, a source address and a se- quence number information.

2. The method according to claim 1, wherein the packet is processed towards the destination address.

3. The method according to claim 1,

- wherein several packets are aligned according to the their sequence number information and

- wherein several packets are processed towards the

destination address.

4. The method according to any of the preceding claims, wherein the bus system is driven by a clock signal and/or wherein the packet is conveyed with a checksum information .

5. The method according to any of the preceding claims, wherein the bus system utilizes at least one of the fol^¬ lowing channels:

- a control bus,

- a data bus,

- a response bus.

6. The method according to claim 5, wherein the control bus, the data bus and/or the response bus are virtual channels, logical channels and/or physical channels.

7. The method according to any of claims 5 or 6, wherein a data rate of a channel is adjusted via a flow control.

8. The method according to any of the preceding claims, wherein the packet comprises an information body.

9. The method according to claim 8, wherein information of a subsequent packet is inserted in the information body of its previous packet.

10. The method according to claim 9, wherein header information of the subsequent packet is inserted in the infor^¬ mation body of its previous packet.

11. The method according to any of the preceding claims, wherein the bus system is a passive bus system or an ac^¬ tive bus system providing a bridging functionality.

12. A device comprising or being associated with a process^¬ ing unit that is arranged such that the method according to any of the preceding claims is executable thereon.

13. The device of claim 12, wherein the device is a bus de^¬ vice, in particular a bus master, a bus slave or an interconnect switcher.

14. A bus system comprising the device according to any of claims 12 or 13.