Patent Application
20090310489
There are two common ways of transmitting data corresponding to each of a plurality of data streams via a data interface. One way uses a parallel address/data bus, with each of the data streams writing to (and reading from) a separate address range. The other way uses a serial bus and a pre-defined interleaving scheme.
One exemplary parallel address/data bus is the cluster bus of the TigerSHARC® processor (offered by Analog Devices, Inc. of Norwood, Mass., USA). A disadvantage of using such a bus is that it consumes a large number input/output (I/O) pins. Furthermore, the same lines are typically used to transmit and received data, making the bus unidirectional at any given point in time (i.e., the bus is half-duplex). The overhead of implementing a large number of I/O paths also tends to encourage sharing of the bus by multiple devices (e.g., a plurality of processors in a “cluster”).
A pre-defined interleaving scheme is advantageous over a parallel address/data bus because it can be implemented using a serial data interface, making it more feasible to implement a bi-directional (i.e., simultaneous transmit/receive) link. However, a disadvantage of a pre-defined interleaving scheme is the fixed relationship between the data transfer rates of each data stream. That is, the pre-defined interleaving of the data streams makes it very difficult (and really not possible) to individually change the data transfer rate of any particular data stream.
Illustrative embodiments of the invention are illustrated in the drawings, in which:
As shown, the serial data link 102 may comprise a first channel 108 for transmitting serial data from the first device 104 to the second device 106, and a second channel 110 for transmitting serial data from the second device 106 to the first device 104. In some cases, only one of the channels 108, 110 may be provided. In these cases, data transmission may be limited to a single direction; or one of the devices 104, 106 may serve as the arbiter for the serial data link 102.
As also shown in
As further shown in
Turning now to
The method 200 comprises a step 202 of staging data for at least some of the logical data streams. By way of example, the staging of data may be accomplished using a plurality of first-in first-out (FIFO) or ping-pong buffers, as will be discussed in greater detail later in this description.
At step 204, a “data readiness” of the data staged for each logical data stream is determined. That is, data readiness is determined on a stream-by-stream basis.
At step 206, a plurality of messages is assembled. Each of the messages is provided with a header, and at least some of the messages carry some of the data that has been staged for the logical data streams. For messages that carry data, the headers of the messages identify the logical data stream(s) to which their data pertains.
It is envisioned that, typically, a message will only carry data pertaining to one particular logical data stream. However, a broadcast message, in which the header of the message indicates that data is to be broadcast to multiple ones of the logical data streams, is also contemplated.
Of note, a message that carries data need only carry some of the data that has been staged for a particular logical data stream (although there may be cases where the quantity of a logical data stream's data is small enough that all of the stream's data may be carried in a single message).
At step 208, both i) the data readiness of the data staged for each logical data stream, and ii) a priority scheme of the logical data streams, is used to periodically designate an active one of the logical data streams. Then, at step 210, messages corresponding to the active one of the plurality of logical data streams are transmitted via a serial data interface, while messages corresponding to other ones of the plurality of logical data streams are not transmitted.
Optionally, flow control information may be received via the serial data interface. The flow control information is indicative of a remote receiver's readiness to receive data and may be used as an additional basis for designating the active one of the logical data streams. In this manner, flow control for a particular logical data stream can be regulated by both the transmitting and receiving ends of a serial data link.
Although the steps of the method 200 are shown to have a particular flow, it is noted that the flow is not important, and that various flows are contemplated. In fact, in most cases, all of the method's steps will be performed in parallel.
Looking at the serial data transmitter 302 in more detail, the serial data transmitter 302 comprises a data staging mechanism 314, a message generation mechanism 316, and an arbitration mechanism 318. In some embodiments, these structures may be implemented individually. In other embodiments, the functionality of these structures may be provided by one or more multi-purpose structures.
The data staging mechanism 314 stages data for at least some of the logical data streams 308, 310, 312 and sets a data readiness indicator for the data staged for each logical data stream 308, 310, 312. The data readiness indicator 322 indicates, for example: when the staging mechanism 314 has staged more than a predetermined quantity of data for a particular logical data stream 308, 310, 312, or when an end-of-frame (EOF) indicator has been received for a particular logical data stream 308, 310, 312.
The message generation mechanism 316 assembles (e.g., packetizes) a plurality of messages 304. Each of the messages 304 is assembled with a header, and at least some of the messages carry some of the data staged by the data staging mechanism 314. For messages that carry data, the headers of the messages identify the logical data stream(s) to which their data pertains.
As also shown in
In some embodiments, the apparatus 300 shown in
In some embodiments, the serial data receiver 324 receives messages (e.g., messages similar in form to those transmitted by the serial data transmitter 302). In these embodiments, headers of the received messages may be processed to extract the flow control information 326.
Each of the TX stream objects 402, 404, 406 contains a FIFO buffer 416 to buffer (or stage) data received from its internal stream interface 408. Buffering or staging of data is needed to keep the serial data interface 306 free to transmit data for other streams.
When assembling a message, each TX stream object 402, 404, 406 prepends message data with a message header. This is done by the header block 418. In some embodiments, the data portion of a message may have a variable width, with the end of the message being determined by a “maximum data size” register 420 or a data word marked with an EOF indicator. The “maximum data size” register 420 may also be used to set a threshold for the FIFO buffer 416. That is, when the amount of data staged in the FIFO buffer 416 exceeds the maximum data size, data staged in the FIFO buffer 416 may be assembled into a message for transmission via the serial data interface 306. Note however, in some cases, data may accumulate in the FIFO buffer 416 fast enough that multiple messages can be formed from the data staged in the FIFO buffer 416. This is especially useful for consistently streaming data such as in-phase/quadrature (I/Q) sample data, where there is no data framing.
Via the logical data stream interface 408, a stream producer 410 may assert an EOF indicator to mark the end of a particular piece of data. In some embodiments, the EOF indicator signifies that a message shall terminate with the EOF indicator (typically early with respect to the maximum data size).
In some cases, the FIFO buffer 416 may contain multiple EOF indicators, each of which marks the end of a different piece of data. In other cases, multiple messages may be assembled and transmitted before the next EOF indicator is reached, or the data contained between EOF indicators may be less than what can be carried by a single message. The use of EOF indicators enables framed data, such as interprocess communication (IPC) or co-processor data, to be transmitted via the serial data interface 306. Periodically inserted EOF indicators may also be used to ‘bump’ (synchronize) streaming data, such as I/Q sample data, to ensure alignment between the serial data transmitter 302 and a remote receiver.
The Data Available (DAV) and Ready for Data (RFD) signals control when data is transferred from a stream producer 410 to a stream object 402. If both DAV and RFD are asserted, data is transferred to a TX stream object 402.
The control interface 412, in combination with the control/status logic 422 and maximum data size register 420, enables the read and configuration (write) of stream object parameters. The readable and configurable stream object parameters may comprise, for example: the maximum data size; a FIFO Empty indicator; a FIFO Full indicator; a FIFO data count; an option to flush/reset the FIFO buffer and message generation processes; a TX stream object enable; and a FIFO Empty indicator mask. A FIFO empty condition occurs when the FIFO data count transitions from non-zero to zero. When asserted, the FIFO Full indicator stalls the transfer of data from a stream producer 410 to a stream object 402. The FIFO data count reflects a count of data entries currently stored in the FIFO buffer 416. The FIFO Empty indicator mask is used to suppress assertion of the FIFO Empty indicator, and can be important when using a logical data stream to send bursted data such as IPC or co-processor data.
In some embodiments, the priority scheme for the logical data streams served by the stream objects 402, 404, 406 may be a “hard” priority scheme. For example, each stream object 402, 404, 406 may be associated with a priority number (e.g., 0, 1, 2 . . . N), with a lower numbered object having priority over a higher numbered object. Alternately, the priority scheme may be statically or dynamically configured via the control interface 412.
In the serial data transmitter 302 (
In some cases, a ping/pong buffer approach 516, 518 may be used to source or sink data. In these cases, each of the buffers 516, 518 may be associated with a linked list of DMA structures. This enables a central processing unit (CPU) to stage data in one buffer while the data staged in the other buffer is transmitted via the serial data interface 306.
The flow control information received by the serial data receiver 702 is captured by a receive (RX) Interface ISR 520 and stored in a TX Stream State register 522. When flow control information is updated, the RX Interface ISR 520 notifies the TX DMA ISR 504, which then reads the TX Stream State register 522.
The TX DMA ISR 504 arbitrates access to the serial data interface 306. In this respect, the TX DMA ISR uses i) data readiness indicators for each of the logical data streams served by the transmitter 302, ii) a priority scheme of the logical data streams, and iii) the flow control information received from the remote receiver, to periodically designate an “active” one of the logical data streams. The TX DMA ISR 504 also assembles message headers and instructs the TX DMA controller 502 to retrieve data, as necessary, from the linked lists of DMA structures 506, 508, 510.
In some embodiments, the TX DMA ISR 504 is called when either 1) the current TX DMA transfer is completed, 2) flow control information is received, or 3) a data readiness indicator for one of the logical data streams has been updated. Because of these different circumstances for calling the TX DMA ISR 504, the TX DMA ISR 504 cannot assume that the TX DMA controller 502 is free (and must check before instructing the TX DMA controller 502 to take new actions).
The TX DMA ISR 504 may also provide stream semaphores. For example, upon the completion of a TX DMA transfer, and if the ‘sem’ field of the DMA descriptor is non-zero, a stream semaphore may be given to notify a stream owner task that data has been sent.
Having described an exemplary method 200 (
At step 602 of the method 600, messages are received via a serial data interface. At step 604, a plurality of data buffers are used to buffer data received for a plurality of logical data streams. At step 606, headers of the received messages are processed to i) identify ones of the plurality of logical data streams to which the messages pertain, if any, and ii) route data contained in the messages to ones of the data buffers corresponding to the identified ones of the plurality of logical data streams. Optionally, at step 612, the headers of the received messages may also be processed to extract flow control information, which flow control information may be used by a corresponding data transmission method (e.g., method 200,
At step 608 of the method 600, each of the data buffers is monitored, and flow control information is generated. The flow control information indicates the readiness of ones of the data buffers to receive additional data for the logical data streams. At step 610, the flow control information is transmitted to a remote receiver. In some embodiments, the flow control information is transmitted to the remote receiver in one or more message headers, which headers may be similar to (or the same as) the headers processed in step 606 of the method 600.
Although the steps of the method 600 are shown to have a particular flow, it is noted that the flow is not important, and that various flows are contemplated. In fact, in most cases, all of the method's steps will be performed in parallel. The method's steps may also be performed in parallel with the method steps shown in
The plurality of data buffers 706 buffer data received for a plurality of logical data streams 712, 714, 716. The message router 708 i) processes headers of the messages received via the serial data interface to identify ones of a plurality of logical data streams 712, 714, 716 to which the messages pertain, and ii) routes data contained in the messages to ones of the data buffers 706 corresponding to the identified ones of the logical data streams 712, 714, 716. The mechanism 710 for monitoring each of the data buffers 706 not only monitors the data buffers 706, but also generates flow control information 718 indicating the readiness of the serial data receiver 702 to receive additional data. Preferably, the flow control information 718 indicates the readiness to receive additional data for each logical data streams 712, 714, 716.
In some embodiments, the apparatus 700 shown in
As messages are received, the serial data interface 306 reads and discards each message header before routing the data contained in a message to the logical data stream (or RX receive object 802, 804, 806) to which it pertains. The serial data interface 306 may also extract flow control information from some or all of the message headers, which flow control information may be forwarded to the arbitration mechanism 318 (
Each of the RX stream objects 802, 804, 806 contains a FIFO buffer 816 to buffer the data it receives from the serial data interface 306. Buffering of data is needed to keep the serial data interface 306 free to receive data for other streams.
The Data Available (DAV) and Ready for Data (RFD) signals control when data is transferred from a stream object 802 to a stream consumer 810. If both DAV and RFD are asserted, data is transferred from a RX stream object 802. A stream object 802 may also support Start of Frame (SOF) and End of Frame (EOF) signals, which signals may be generated in response to received messages being marked with SOF and EOF indicators.
The control interface 812, in combination with the control/status logic 818 and FIFO watermark register 820, enables the read and configuration (write) of stream object parameters. The readable and configurable stream object parameters may comprise, for example: a FIFO Watermark level; a FIFO Empty indicator; a FIFO Overflow indicator; a FIFO data count; an option to flush/reset the FIFO buffer; a RX stream object enable; and a FIFO Empty indicator mask. A FIFO empty condition occurs when the FIFO data count transitions from non-zero to zero. The FIFO Overflow condition occurs when a write to the FIFO buffer is attempted while the FIFO is full. The FIFO data count reflects a count of data entries currently stored in the FIFO buffer. The FIFO Empty indicator mask is used to suppress the FIFO Empty indicator, and can be important when using a logical data stream to receive non-contiguous or sparse data, such as IPC or co-processor data.
Flow control information for a stream object 802 may be generated by comparing a stream object's FIFO data count to the stream object's FIFO Watermark level. If the FIFO data count exceeds the FIFO Watermark level (i.e., a FIFO buffer 816 holds data in excess of its watermark level), the readiness status of the stream object may be changed from “ready” to “not ready”. If the serial data receiver 702 is coupled to a serial data transmitter, the serial data transmitter may transmit the serial data receiver's flow control information to a remote receiver, thereby causing a remote transmitter to stop or slow the transmission of data corresponding to one or more logical data streams. In some embodiments, a serial data receiver's flow control information is only transmitted (or published) to a remote receiver upon the occurrence of predetermined events, such as: 1) when the FIFO data count transitioning from above to below the FIFO Watermark level; 2) when the last piece of data in a message is written to a RX stream object and the object's FIFO data count remains below the watermark level; 3) when a FIFO Overflow condition occurs; or 4) when a FIFO Empty condition occurs and the FIFO Empty indicator mask is not set. In other embodiments, flow control information can be sent upon the occurrence of other events, or on a periodic basis. Preferably, the flow control information is incorporated into the headers of transmitted messages; and when possible, the flow control information is incorporated into the headers of messages carrying data for logical data streams. However, when no logical data stream has data to send, the flow control information may, in some embodiments, be incorporated into a header-only message, as previously discussed.
In the serial data receiver 702 (
In some cases, a ping/pong buffer approach 538, 540 may be used to source or sink data. In these cases, each of the buffers 538, 540 may be associated with a linked list of DMA structures. This enables a central processing unit (CPU) to read data from one buffer while data received via the serial data interface is written to the other buffer.
The RX Interface ISR 520 strips the header from each incoming message, and determines where to DMA the data content of the message based on the RX DMA descriptors for the linked lists of DMA structures 528, 530, 532. Preferably, message headers themselves are not written into the DMA structures 534, thereby enabling the storage of contiguous data records. Upon completing the write of a message's data content, a semaphore may be provided by the RX DMA ISR 526. For example, upon the completion of a RX DMA transfer, and if the ‘sem’ field of the DMA descriptor is non-zero, a stream semaphore may be given to notify a stream owner task that a data record has been completely captured.
As previously mentioned, the system 100 (
The serial data link shown in
Of note, the message structure of the Link-Port protocol anticipates quad-words of 128 bits. However, the transmitters and receivers disclosed herein may be configured to pack data of different widths (e.g., 32-bit, 64-bit or 128-bit widths) into each Link-Port quad word. Furthermore, and in the event that the end of a raw data block does not fall on a quad word boundary, the last transmitted quad word may be padded with a predetermined fill pattern.
In a Link-Port environment, the first device shown in
The header identifier is a unique string of bits that identifies the start of a header to a receiver. However, in a Link-Port environment, the HEAD_ID portion of the header may also be used by an FPGA to report an error condition, or used by a TigerSHARC® to clear an error condition.
The current message identifier identifies the logical data stream to which a message pertains. In one embodiment, a bit may be provided for each of a plurality of logical data streams, and one of the bits may be set to identify the logical data stream to which a message pertains. Alternately, multiple ones of the bits could be set, to “multicast” a message to more than one of the logical data streams. If a message consists of nothing more than a header, all bits may be cleared.
In a Link-Port environment, the transmit stream status portion of the header may indicate 1) serial data transmitter errors per logical data stream (in FPGA→TigerSHARC transmissions), or 2) whether stream errors should be cleared per logical data stream (in TigerSHARC→FPGA transmissions).
Also in a Link-Port environment, the receive stream status portion of the header may indicate the readiness of a serial data receiver to receive data corresponding to each logical data stream. In addition, the receive stream status portion of the header may indicate 1) serial data receiver errors per logical data stream (in FPGA→TigerSHARC transmissions), or 2) whether stream errors should be cleared per logical data stream (in TigerSHARC→FPGA transmissions).
