Patent Application
20170373881
The technology of the disclosure relates generally to handling arbitrary data streams on a data bus.
Computing devices have become ubiquitous in contemporaneous living. The popularity of computing devices has exploded in part because of the ever increasing functionality available on the computing devices. Concurrent with the increase in functionality has been an increase in the numbers and types of supplemental devices that may be associated with the computing devices. In some cases the supplemental devices may be integrated into the computing devices, such as the integration of a camera into a smart phone. In other cases, the supplemental devices may be peripherals, such as audio headsets that are coupled to a computing device through some form of external interface. In both cases various protocols have arisen to allow applications running on the computing device to interact with the supplemental devices as needed.
One popular protocol is the Universal Serial Bus (USB) protocol. USB exists in various flavors including full speed (FS), high speed (HS), and super speed (SS). Additionally, USB allows for various clock synchronization schemes between a host and a peripheral device. In particular, USB contemplates synchronizing to a clock from the peripheral device (referred to as asynchronous), synchronizing to a clock from the host (referred to as synchronous), and sharing clock synchronization responsibilities between the host and the peripheral device (referred to as adaptive). While the various flavors and clock synchronization schemes allow for design flexibility to increase the number of devices using the USB protocol, the myriad options make some design decisions more difficult.
Such design decisions are further complicated when audio and/or video streams are being transmitted through a USB interface. Because of the universal nature of the USB form factor, a USB host is expected to be able to accommodate both audio/video capture from and audio/video playback to a peripheral. In particular, the USB host is expected to be able to accommodate different speeds, different clock synchronization schemes, different sampling rates, and variably-sized data. Conventional systems place the burden on such accommodation at the application layer, which requires substantial buffering and complicated algorithms on the part of applications in the application layer. Additionally, there are current proposals to increase service intervals, which may impose additional burdens on the application processor that handles the application layer. Accordingly, there is a need for a way to provide a USB compatible system that allows for greater flexibility in handling variable data streams both those currently implemented and that has the flexibility to handle differing input parameters.
Aspects disclosed in the detailed description include systems and methods for controlling isochronous data streams. Particular aspects of the present disclosure are designed to be used with almost any isochronous data stream, but are well-suited for use with the Universal Serial Bus (USB) protocol. Further, aspects of the present disclosure are flexible to accommodate existing configuration possibilities within the USB protocol as well as accommodate proposed future changes in the USB protocol. The flexibility of the systems and methods is provided by calculating: (1) drift between a USB host system time and the application and (2) drift between the USB host system and a USB device clock. Based on these two drift calculations, a time stamp may be synthesized to program a next delivery schedule. Using this time stamp, jitter correction can take place and uniformly-sized packets may be assembled to pass to an application processor. The use of such uniformly-sized packets may eliminate the need for buffers in an application layer, which may improve user experience when a data stream is an audio data stream.
In this regard in one aspect, a method for controlling communication in a USB system is disclosed. The method includes receiving variably-sized packets at a first processor having a USB driver. The method also includes assembling uniformly-sized packets at the first processor. The method also includes passing the uniformly-sized packets to a second processor for use by applications at an application layer in a protocol stack.
In another aspect, a host is disclosed. The host includes an application processor. The host also includes USB hardware. The host also includes an audio digital signal processor (ADSP). The ADSP is configured to receive variably-sized packets at the ADSP through the USB hardware. The ADSP is also configured to assemble uniformly-sized packets at the ADSP. The ADSP is also configured to pass the uniformly-sized packets to the application processor for use by applications at an application layer in a protocol stack.
In another aspect, a host is disclosed. The host includes an application layer. The host also includes USB hardware. The host also includes a system on a chip (SoC) including a plurality of processors. The plurality of processors is configured to receive variably-sized packets at a first processor. The plurality of processors is also configured to assemble uniformly-sized packets at the first processor. The plurality of processors is also configured to pass the uniformly-sized packets to a second processor for use by applications at an application layer in a protocol stack.
In another aspect, a method for detecting drift in a USB system is disclosed. The method includes determining that a fractional sampling rate is used on a USB bus between an audio peripheral and a host. The method also includes determining a first fractional remainder associated with the fractional sampling rate over a service interval. Based on the first fractional remainder, the method also includes calculating a whole number corresponding to a number of intervals required to have no fractional remainder. The method also includes checking drift each whole number of intervals.
In another aspect, a processor is disclosed. The processor includes an input. The processor also includes a control system. The control system is configured to determine that a fractional sampling rate is used on a USB bus between an audio peripheral and a host. The control system is also configured to determine a first fractional remainder associated with the fractional sampling rate over a service interval. Based on the first fractional remainder, the control system is also configured to calculate a whole number corresponding to a number of intervals required to have no fractional remainder. The control system is also configured to check drift each whole number of intervals.
In another aspect, a method to synthesize a time stamp is disclosed. The method includes receiving a run command from a data delivery handler. The method also includes summing an output from a high resolution timer and a computed absolute time stamp.
In another aspect, a processor is disclosed. The processor includes an audio data buffer. The processor also includes a USB audio client (UAC). The UAC is configured to receive variably-sized packets. The UAC is also configured to assemble uniformly-sized packets. The UAC is also configured to pass the uniformly-sized packets to a second processor for use by applications at an application layer in a protocol stack.
With reference now to the drawing figures, several exemplary aspects of the present disclosure are described. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects.
Aspects disclosed in the detailed description include systems and methods for controlling isochronous data streams. Particular aspects of the present disclosure are designed to be used with almost any isochronous data stream, but are well-suited for use with the Universal Serial Bus (USB) protocol. Further, aspects of the present disclosure are flexible to accommodate existing configuration possibilities within the USB protocol as well as accommodate proposed future changes in the USB protocol. The flexibility of the systems and methods is provided by calculating: (1) drift between a USB host system time and the application and (2) drift between the USB host system and a USB device clock. Based on these two drift calculations, a time stamp may be synthesized to program a next delivery schedule. Using this time stamp, jitter correction can take place and uniformly-sized packets may be assembled to pass to an application processor. The use of such uniformly-sized packets may eliminate the need for buffers in an application layer, which may improve user experience when a data stream is an audio data stream.
Before addressing particular aspects of the present disclosure, a brief overview of an exemplary system which may implement the systems and methods for controlling isochronous data streams is disclosed. As noted above, while applicable to various isochronous data streams, exemplary aspects are particularly applicable to USB audio streams. Thus, the exemplary system is a USB digital audio system.
In this regard,
While exemplary aspects of the present disclosure are well suited for audio environments such as the digital audio headset 108 of
Exemplary aspects of the present disclosure provide error free drift detection from which jitter correction may be applied and from which a synthesized time stamp may be calculated. Using this synthesized time stamp, a next delivery schedule may be calculated which is used to drain the buffers. Further, by repositioning the calculation outside the application processor, uniform data frame sizes may be provided to the application processor, which in turn may improve audio quality and potentially provide power savings opportunities. One of the benefits of the present disclosure is the flexibility of the disclosure to accommodate any form of clock synchronization approach (asynchronous, synchronous, or adaptive) between the host and the device as well as various data speeds, different sampling rates, variably-sized data, different USB speeds (HS, FS, SS), and differing service intervals. While the present disclosure may be implemented strictly in hardware, the flexibility of the present disclosure is improved through the use of software, where the variables are more readily adjusted to accommodate any configuration. Before exploring the particulars of the system of the present disclosure and the various signaling that may be used to implement aspects of the present disclosure, an overview of the equations used to create the flexibility are presented.
The following section is math intensive and preserved for the interested reader, but may not be critical to understand exemplary aspects of the present disclosure. For the readers who prefer not to let math clutter their understanding of the disclosure, the discussion of exemplary aspects begins again below with reference to
The basic drift compensated rate matched audio buffer delivery model that is used by the host may be expressed as:
ticksnext=ticksreference+ticksoffset+D1+D2 . . . +DM (Eq. 1)
In Eq. 1, ticksnext (also referred to as “Tnext”) is the synthesized time stamp that is effectively used to program the next delivery schedule. ticksreference (also referred to as “Tref”) is the timestamp of the first synthesized timestamp. Ticksoffset (also referred to as “Toffset”) is the delta from the ticksreference used for the delivery of buffers and also serves as timing of the picking up of buffers for playback and capture. In Eq. 1, each Di represents the total drift between a device clock and a USB time reference. In most situations, there are only three clocks to consider, the USB host clock, the audio application clock, and the USB device clock. The USB host clock serves as the system time reference for both of the other two clocks, and thus, Eq. 1 will typically simplify to:
ticksnext=ticksreference ticksoffset Dapp-usb−Ddevice-usb (Eq. 2)
Eq. 2 works for both audio capture and audio playback paths. Dapp-usb is the time difference between the audio application clock and the USB host clock. Ddevice-usb is how fast the USB device clock is going with reference to the USB host clock. Together these values give the net system drift (i.e., is the audio sample moving faster or slower). For the audio capture path, when Ddevice-usb is positive, the device is delivering audio samples faster than the USB host is clearing them. When Dapp-usb is positive the audio application is retrieving audio samples faster than the USB host is delivering them. On the audio playback path, when Dapp-usb is positive, the audio application is delivering audio samples faster than the USB host is clearing them. When Ddevice-usb is positive, the device is retrieving audio samples faster than the USB host is delivering them. This value is passed to an asynchronous sample rate converter (ASRC) to synthesize and/or interpolate audio allowing the ASRC to know how much to correct.
The drift Ddevice-usb for the capture and playback paths may be determined explicitly or implicitly. The drift is obtained based the direction of the data flow (i.e., device-to-host (usually capture) or host-to-device (usually playback)). The source of the drift information is dependent on what the USB advertises and which isochronous synchronization mode is selected for a USB endpoint pair by the high level operating system (HLOS). In fact, there are twenty combinations of isochronous synchronization modes between the capture and playback paths.
The source of drift information is summarized in Table 1 below. Ddevice-usb is abbreviated Ddevice in Table 1.
Table 1 assumes that the audio application clock is in phase with the USB host clock (Dapp-usb=0). This assumption causes all synchronous and adaptive playback (Out) paths to have Out: Ddevice=0.
Exemplary aspects of the present disclosure provide techniques to detect drift for essentially any variation of sampling frequency, sampling interval, sample size, bus speed, clock synchronization mode, or the like. This flexibility is achieved through generic equations that accommodate these variable inputs and allow for the appropriate drift detection.
It should be appreciated that the quality, environment, and manufacturing precision all affect one asynchronous clock's ability to keep time compared to another asynchronous clock in the system. There are systems where there are multiple clocks along the capture path and multiple clocks on the playback path. The net drift for a path is the sum of the time differentials between each subsystem clock along the path. The present disclosure illustrates that by measuring drift at the appropriate frequency, error free drift detection is enabled and needless measurements are avoided, which may allow power savings.
Audio streaming in a USB system adds difficulty in that such audio streaming is expected to use the isochronous transfer mode. It is a real-time dedicated bandwidth mode with no error checking or retries. Audio samples are bundled in the form of an audio packet and an audio packet may be sent once every (micro)frame. Each such frame is either 125 μs or 1 ms depending on whether a HS or FS USB transfer mode is selected by the physical layer. The USB protocol supports sending such frames in bursts for power savings and for handling large network latencies. The number of frames per service interval is described by 2binterval-1 where binterval is currently a value between one and 16. Discussions have been made amongst the governing body for the USB protocol for expanding this number. The number of frames per service interval is fixed, but the number of audio samples sent per burst can be variable.
A factor that has been considered as pertinent to evaluating drift includes keeping the accumulated drift using the source unit of measurement. Conversions from one unit to another unit generally involve a division operation which may introduce rounding or truncation errors. Accumulation of such truncation errors may lead to a divergence in the interpretation of time between the host and the device. By keeping the accumulation in the source unit of measurement, any truncation error is temporary and should be seen by the system as insignificant jitter.
A further factor is the maximum tolerable system jitter. A reasonable tolerable system jitter is less than one audio sample of accuracy to avoid being interpreted as real drift by the audio system. Thus, the tolerable system jitter may be a function of the audio sampling frequency. If the tolerable jitter is sufficiently small, hardware assistance may be necessary as a pure software implementation may not be able to react fast enough to service an interrupt to timestamp an event.
Given these considerations, Eq. 6 may be derived when considering a USB audio device's instantaneous frequency feedbacks as a clock source. In such instance, Ff is the average number of audio samples per frame that the USB device reports to the USB host. An instantaneous frequency Ff is reported to the host in the FS USB transfer mode on every:
PeriodFS=210-bRefresh frames (Eq. 3)
Or in the HS USB transfer mode on every:
PeriodHS=2(binterval-1 microframes (Eq. 4)
The instantaneous drift is thus
Δdrift=Ffk−Ffk-1 (Eq. 5)
and is computed when the host receives a feedback
Ticksconv(D)=(D*1000)/fs*19.2 MHz (Eq. 6)
Where fs is the sampling frequency. Note that 19.2 MHz is the speed of one exemplary high resolution system timer. If the high resolution system timer has a different speed, a different value should be substituted herein, which turns Eq. 6 into the following generic equation.
Ticksconv(D)=(D*1000)/fs*ftimer (Eq. 6A)
There are challenges in recovering a clock from a USB 2.0 signal resulting from the definitional equivalence of the virtual packet being one virtual frame. Accordingly, a solution to recover a clock from a non-linear data stream is required. Such solution follows, with the assumption that each clock crystal has at least 500 ppm of accuracy. The number of samples per virtual frame is defined as
numSamplesPerVirtualFrame=fs/ft*2(binterval-1) (Eq. 7)
Where fs is the sampling frequency, ft is the service interval frequency, and binterval is as defined above. For ease of notation, the numSamplesPerVirtualFrame may be abbreviated as NSPVF
Additionally, an alignment multiplier is needed, and defined as follows:
where 1000000 is arbitrarily chosen as a very large base 10 value to increase fractional precision. From Eq. 7 and 8, an expected number of samples may be calculated as follows:
expectedNumSamples=NSPVF*alignmentMultiplier (Eq. 9)
The alignmentMultiplier represents the least number of virtual frames needed by the host before a stable drift determination is possible. The expectedNumSamples is the number of samples expected to be received. The NSPVF is an intermediate variable for visual clarity and not a floating point. For each alignmentMultiplier number of virtual frames received, the Adrift is computed by:
Δdrift=numSamplesReceived−expectedNumSamples (Eq. 10)
Thus, the net drift from the beginning of the audio session is computed by:
D=D
net drift+Δdrift (Eq. 11)
The conversion of D audio samples to system timer (sometimes referred to as Qtimer) ticks is:
Ticksconv(D)=Dnet drift/fs*19.2 MHz (Eq. 12)
Again, note that 19.2 MHz is the speed of the high resolution system timer. If the high resolution system timer has a different value, then such different value should be substituted herein, resulting in:
Ticksconv(D)=D/fs*ftimer (Eq. 12A)
With the drift information and the clock detection information outlined above, rate matching may be done. With rate matching, uniform sample sizes may be created and sent to the application processor as outlined below. However, before addressing the uniform sample sizes, more math is presented to explain the rate matching. In particular, this helps define how to calculate ticksoffset.
Remember, absent drift
ticksext=ticksreference+ticksoffset (Eq. 13)
Where ticksoffset is defined as
Where fd is the delivery frequency and i increments on every ticknext and wraps around when i=fs to avoid i from overflowing. At the wrap around point, ticksreferenee=ticksext and then i=0.
Armed with the math set forth above, exemplary aspects of the present disclosure are now set forth. In this regard,
The mobile communication device 300 includes an application processor 302 and an ADSP 304. In an exemplary aspect, the application processor 302 and the ADSP 304 may be in a single SoC 306. Likewise, while described as conceptually distinct processors, these processors may be part of a single host processor. Still further, while ascribed specific functions such as “application processor” or “ADSP,” it should be appreciated that other processors that are traditionally not referred to by such appellations may still implement comparable functionality without departing from the scope of the present disclosure. The application processor 302 may communicate with a USB hardware controller 308, which communicates with a USB peripheral 310, such as a headset, through a USB interface 312, which may include USB receptacles, USB connectors, and a USB cable.
As with the USB peripheral 202 of
The ADSP 304 may include a UAC driver 314. The UAC driver 314 may use a host controller interface (HCI) (not illustrated) to communicate with the USB hardware controller 308. In conventional systems, there is no HCI in the UAC driver 314, because the ADSP 304 does not communicate with the USB hardware controller 308. However, exemplary aspects of the present disclosure allow for communication between the USB hardware controller 308 and the ADSP 304. Accordingly, an HCI may be provided to effectuate such communication. The UAC driver 314 receives unstable and variably-sized data frames from the USB hardware controller 308.
Exemplary aspects of the present disclosure add one or more buffers 316 to the UAC driver 314 as well as couple a high resolution system timer 318 to the UAC driver 314, which allows the UAC driver 314 to pass stable, precise, and fixed data frame sizes to data processing circuitry 320 in the application processor 302 (or other processor that handles applications). Still further, the UAC driver 314 may provide net playback and capture delays to the data processing circuitry 320 through a signal 322. By providing uniform data frames to the data processing circuitry 320, application layer algorithms 324 do not have to buffer the data as heavily or perform the corrections associated with the data processing circuitry 218 of
While
In this regard,
In
With continued reference to
The buffer 316 outputs a data signal 532 (labeled “read data”) to a data delivery handler 534, which also receives an output 536 of the high resolution system timer 318. The data delivery handler 534 may also receive a set output buffer size command (perhaps from the ASRC 326) indicating what size buffers the ASRC expects to process. The signal 530 is provided to a summer 538 which adds Tref thereto and generates an intermediate signal 540, to which is added Toffset, to generate a signal 542, which is passed to a summer 544 (which essentially performs either Eq. 6 or Eq 12 as appropriate). The summer 544 adds the signal 542, the signal 522, and the output 536 to generate a synthesized time stamp 546 (essentially Eq. 2). The data delivery handler 534 outputs a run command for the summer 544 and provides a fixed number of samples to the ASRC 326. The ASRC 326 also receives the synthesized time stamp 546 and outputs resampled data 548. While not specifically illustrated, a set sampling frequency command may also be received to assist in calculations as noted above.
In an exemplary aspect, this data regulator is implemented as software. In another exemplary aspect, this data regulator may be implemented in hardware.
With continued reference to
At some point, the USB hardware controller 308 may send an asynchronous clock feedback event (signal 630) to the data regulator, which causes the data regulator to update Ddevice-usb (see generally block 632).
At some other time, the high resolution system timer 318 may send a timer expired event signal 634 to the data regulator. Responsive to this signal 634, the data regulator may increment i by one, and if i equals the sampling frequency, set Tref to Tnext and i=0; compute the next Toffset; and compute Eq. 2 (see generally block 636). The data regulator may send a data available signal 638 to the application processor 302, and program Tnext (signal 640), and program the next free buffer space to write (signal 642). The application processor 302 reads the net drift or time stamp from the data regulator (signal 644) and reads data from the buffer(s) 316 in the UAC driver 314 (signal 646) and/or the USB hardware controller 308 (signal 646A).
The application processor 302 computes the number of samples to correct from the new net drift and the previous net drift (block 648), and writes data into its file system, such as by using a write command with data, data length, samples to correct, and duration to correct variables. Note that the data may be voice packets. If necessary, the drift correction may be stretched out over a configurable period to reduce perceivable glitches. However, even with the stretched-out period, it is expected that such correction takes place on the order of 25 ms instead of 10 seconds as is sometimes used in conventional systems. The process then deactivates (block 660).
Note further that additional aspects of the present disclosure provide techniques to provide error free drift detection and support future planned power saving initiatives. In this regard, it should be appreciated that fractional sampling rates, such as the relatively common 44.1 kHz, lend themselves to false detections of drift because of the phase mismatch between accumulators at the peripheral device and accumulators at the host. In contrast to signaling protocols that include time stamps to assist in drift detection, the USB protocol does not include time stamps from the peripheral device to the host. Rather, the host only receives packetized USB data. Inside each USB packet, the amount of data is variable. The problem with the fractional sampling rate and unknown packet size has been well documented in the industry. The usual solution is to time average the samples over a long period, such as ten minutes, and then perform correction of the drift. The long delay in assembling the time average of samples results in latency before correction is applied. Until the correction is applied, the user may experience a degraded audio experience. Likewise, the granularity of the correction may not be appropriate for instantaneous or random drift events.
Exemplary aspects of the present disclosure allow for error free drift detection. This is best explained through the use of an example. Assuming that the sampling frequency (Fs) is 44.1 kHz and that the USB bus transfer speed is 1000 Hz (i.e., 1 sample per millisecond), and a binterval (samples per packet) of 11, the host would expect to receive 45158.4 samples per interval. The fractional sample cannot be sent under USB rules. The peripheral device accumulator begins when the samples are transmitted to the host, but the host accumulator is delayed until after reception, so the accumulators are out of phase. At the second interval the peripheral accumulator is 90316.8. Again, it is the fractional sample which shows up as drift relative to the host accumulator. Over time, without external drift, this drift will toggle between 1 and 0, but may on occasion cause a correction to be made that is not needed.
Instead of time averaging the drift as in previous solutions, exemplary aspects of the present disclosure evaluate the fractional remainder and find the number of intervals required to arrive at a whole number. In the present example, if the fractional remainder is 0.4, then the number of intervals required to arrive at a whole number is 5. (0.4=2/5, the denominator is 5, so five intervals). The UAC driver 314 may check the accumulator at a boundary determined by the number of intervals so calculated. Thus, in this example, the UAC driver 314 checks the drift every five intervals. The phantom drift caused by the fractional sampling rate is not present, so if drift is detected, that is real drift for which a correction must be made (i.e., interpolation or decimation or the like). Further, by ignoring drift in the intermediate samples, calculations may be forgone, which may result in power savings.
The USB protocol contemplates two forms of drift reporting. The first is an implicit drift detection where in-bound signals are examined and compared to known values to determine a drift. The second is an explicit out-of-band signaling of drift sent by the peripheral device to the host, where the peripheral device compares samples received to an expected number of samples and reports back any drift between these two values. The USB protocol is silent as to how implicit drift detection is performed, and the USB protocol is also silent on how the host may correct for any drift detected (either implicitly or explicitly). The present disclosure has set forth several equations above and a process for handling drift detection and correction thereof.
Similarly,
In contrast,
Similarly,
As noted above, exemplary aspects also allow for future contemplated power savings. This possibility is enabled by the generic (sometimes referred to as agnostic) algorithms used to handle the variable data and sampling rates. That is, in the equations above, the equations start with the agnostic fs, as the sampling rate and ft as the bus transfer speed (which already contemplates FS, SS, and HS). By using these agnostic values in the application layer algorithms 324, other new sampling rates or other non-standard sampling rates are accommodated. The agnostic approach allows proper estimation of a DLL. It should be appreciated that an increase in binterval (the number of samples per packet) increases the size of the packet and also increases the time that it takes to fill the buffer(s) 316. Since the application processor 302 is idle while the buffer(s) 316 is being filled, the application processor 302 may be put into a low-power mode or sleep mode. The longer it takes to fill the buffer(s) 316 (i.e., a larger number of samples per packet), the longer the application processor 302 may be in the sleep mode. The longer the application processor 302 is in the sleep mode, the more power is saved. Thus, there is pressure in the industry to increase the number of samples per packet. By having a generic binterval in the application layer algorithms 324, exemplary aspects of the present disclosure may accept larger binterval values in the audio device descriptor and thus accommodate any future changes in the number of samples per packet and thus allow for future power savings.
The systems and methods for controlling isochronous data streams according to aspects disclosed herein may be provided in or integrated into any processor-based device. Examples, without limitation, include a set top box, an entertainment unit, a navigation device, a communications device, a fixed location data unit, a mobile location data unit, a global positioning system (GPS) device, a mobile phone, a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a tablet, a phablet, a server, a computer, a portable computer, a mobile computing device, a wearable computing device (e.g., a smart watch, a health or fitness tracker, eyewear, etc.), a desktop computer, a personal digital assistant (PDA), a monitor, a computer monitor, a television, a tuner, a radio, a satellite radio, a music player, a digital music player, a portable music player, a digital video player, a video player, a digital video disc (DVD) player, a portable digital video player, an automobile, a vehicle component, avionics systems, a drone, and a multicopter.
In this regard,
Other master and slave devices can be connected to the system bus 1108. As illustrated in
The CPU(s) 1102 may also be configured to access the display controller(s) 1120 over the system bus 1108 to control information sent to one or more displays 1126. The display controller(s) 1120 sends information to the display(s) 1126 to be displayed via one or more video processors 1128, which process the information to be displayed into a format suitable for the display(s) 1126. The display(s) 1126 can include any type of display, including, but not limited to, a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, a light emitting diode (LED) display, etc.
Those of skill in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithms described in connection with the aspects disclosed herein may be implemented as electronic hardware, instructions stored in memory or in another computer readable medium and executed by a processor or other processing device, or combinations of both. The devices described herein may be employed in any circuit, hardware component, integrated circuit (IC), or IC chip, as examples. Memory disclosed herein may be any type and size of memory and may be configured to store any type of information desired. To clearly illustrate this interchangeability, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. How such functionality is implemented depends upon the particular application, design choices, and/or design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.
The various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).
The aspects disclosed herein may be embodied in hardware and in instructions that are stored in hardware, and may reside, for example, in Random Access Memory (RAM), flash memory, Read Only Memory (ROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, a hard disk, a removable disk, a CD-ROM, or any other form of computer readable medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a remote station. In the alternative, the processor and the storage medium may reside as discrete components in a remote station, base station, or server.
It is also noted that the operational steps described in any of the exemplary aspects herein are described to provide examples and discussion. The operations described may be performed in numerous different sequences other than the illustrated sequences. Furthermore, operations described in a single operational step may actually be performed in a number of different steps. Additionally, one or more operational steps discussed in the exemplary aspects may be combined. It is to be understood that the operational steps illustrated in the flowchart diagrams may be subject to numerous different modifications as will be readily apparent to one of skill in the art. Those of skill in the art will also understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
The present application claims priority to U.S. Patent Provisional Application Ser. No. 62/355,166 filed on Jun. 27, 2016 and entitled “PROGRAMMABLE RATE-MATCHED DATA RATE OUTPUT REGULATOR FOR ISOCHRONOUS DATA STREAMS,” the contents of which is incorporated herein by reference in its entirety. The present application also claims priority to U.S. Patent Provisional Application Ser. No. 62/517,247 filed on Jun. 9, 2017 and entitled “ISOCHRONOUS DATA STREAM CONTROL SYSTEMS AND METHODS,” the contents of which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62355166 | Jun 2016 | US | |
| 62517247 | Jun 2017 | US |
