Generating a constant-rate synchronous data stream: classical control loop?

Hi everybody. I need to implement in FPGA a system that generates an output constant- rate synchronous data stream whose data rate has to be equal to the average data rate of an input data stream. The system works like this. Input is a synchronous 8-bit data stream. This stream is provided with a 12.5 MHz clock and a "data valid" signal. This signal gates the input clock, in other words it says when input data are good. This data stream is fed to a FIFO. FIFO write clock is obtained by ANDing input clock with data valid signal in order to discard data when data valid signal is inactive. Output data stream is read by the FIFO. The read clock is generated by a numeric controlled oscillator (NCO). The frequency of the read clock has to be equal to the average frequency of the FIFO write clock. Writes into the FIFO are distributed in bursts. This means data valid is active typically for 6250 consecutive input clock cycles. Then it is inactive for about 3750 cycles. This pattern is usually repeated 3 times. Then we have a long pause of about 30000 input clock cycles where data valid is inactive. The overall pattern is periodic:

---------------------------------------

6250 valid bytes fed into FIFO 3750 invalid bytes (discarded) 6250 valid bytes fed into FIFO 3750 invalid bytes (discarded) 6250 valid bytes fed into FIFO 3750 invalid bytes (discarded) 30000 invalid bytes (discarded)

---------------------------------------

6250 valid bytes fed into FIFO 3750 invalid bytes (discarded) 6250 valid bytes fed into FIFO 3750 invalid bytes (discarded) 6250 valid bytes fed into FIFO 3750 invalid bytes (discarded) 30000 invalid bytes (discarded)

--------------------------------------- ...

I was thinking about using a classical PID control loop. The setpoint is equal to half of FIFO size. FIFO size is 512kB so setpoint is

262144. The error signal is current number of bytes stored in FIFO minus 262144. This error signal is fed to PID controller. PID controller acts on NCO by increasing or decreasing FIFO read clock. PID controller is supposed to work in order to make the error to go to zero, that is data count in FIFO is near 262144. This is true if the data are retrieved from FIFO at the same rate at which, on average, data are written into FIFO.

One of the concerns I have is about input data steam distribution. Since it is inherently burst-oriented I'm afraid read frequency will oscillates excessively (it will increase significantly during write bursts and will decrease significantly during the periods where input clock is invalidated). So I'm wondering if other approaches are more suitable for this situation (estimators, Kalman filter ...).

Thank a lot in advance for any feedback.

Reply to
jaysbasketball
Loading thread data ...

Unless you can predict the input-rate profile for all time in the future, there's no way to meet that spec. You can approximate a constant rate by making the output variation slower than the input, but in the end, the average rates must match.

...

Jerry

Reply to
Jerry Avins

Actually a coworker of mine told me that input data stream carries the information about its nominal average data rate. To get this information it is necessary to make a parser that interprets the packets forming data stream and extracts this value. However this is quite easy to implement. Is it possible to take advantage from this information?

Reply to
jaysbasketball

Is the nominal average data rate constant? Knowing the average input data rate and the short-term variation profile, you can size the FIFO to work forever. Provided, of course, the rates are specified with infinite precision.

Practical systems send a little fast and fill in with SYN characters when they run out of data.

Jerry

Reply to
Jerry Avins

Yes, it is.

Yes, sure. FIFO must be sized in order to never get full/empty otherwise device that receives my output stream will loose stream synchronization.

Reply to
jaysbasketball

That's the same as saying it can't be done. Suppose the output rate is .00001% too small or large? The only practical approach if the output rate must be fixed is making it a bit fast, and inserting occasional filler codes (SYNs).

Jerry

Reply to
Jerry Avins

That depends. You can make your loop bandwidth significantly lower than the burst rate, and you can augment this with low-pass filters in your controller (which, you will find, wants to be a PI filter with no differential needed). Or you can detect the bursts and only update the controller at the end (or beginning) of a burst and servo on that number. Or both.

A 'true' Kalman filter assumes Gaussian, more or less stationary noise. Your input rate "noise" may be stationary in the largest sense, but the burstiness makes it not very stationary in practical terms. I think by the time you had an estimator that takes the burstiness into account it'd be pretty close to my suggestion to detect the bursts and sample at some cannonical spot within the burst.

Reply to
Tim Wescott

You can certainly take advantage of this. Depending on how reliable it is you may just be able to use it directly, or you may be able to use it as a 'feedforward' term. You'll probably have to have to fondle the output rate a bit to keep your FIFO fill level where you want it, but that can probably be done with a simple low-rate proportional controller.

Reply to
Tim Wescott

Jerry, I suspect you're reading too much into his "constant". Take that as "slowly varying" and I think that everything he wants to do is achievable (assuming, at least, that the output rate can vary more slowly than the change in the average input rate).

Reply to
Tim Wescott

Feed forward to what? If the output rate has to remain constant -- "I need to implement in FPGA a system that generates an output constant- rate synchronous data stream whose data rate has to be equal to the average data rate of an input data stream " -- any proposal to change the output rate once it has been established violates the spec.

Jerry

Reply to
Jerry Avins

I already told him that. He didn't bite. I suspect he's working to one of those "You know what I mean" specs.

Jerry

Reply to
Jerry Avins

Jerry, Tim,

thanks a lot for your suggestions. I think I'll have the hardware available to perform some tests next week. I'm going to adopt the classical control loop based on PI controller. In the meanwhile a couple of coworkers are testing a little bit different approach. As soon as I get their results, I'll provide more details about it.

Regards, llandre

Reply to
jaysbasketball

Jerry, Tim,

thanks a lot for your suggestions. I think I'll have the hardware available to perform some tests next week. I'm going to adopt the classical control loop based on PI controller. In the meanwhile a couple of coworkers are testing a little bit different approach. As soon as I get their results, I'll provide more details about it.

Regards, llandre

Reply to
jaysbasketball

As anticipated, we tested two different configurations. Both configurations: a) uses as error signal the difference between current FIFO level and half level b) increase/decrease FIFO read clock speed by acting on a NCO. They differ with respect to the type of controller that process the error signal and acts on NCO.

= Configuration #1: controller is a IIR filter = This configuration reaches steady-state in few seconds but exhibits a relatively large steady-state error.

= Configuration #2: controller is PI = Transient is very long (90 minutes or so) but steady-state error is very small (1/4 with respect to configuration #1).

The achieved performances of conf. #1 are enough to match system specification, however I think that it is possible to shorten transient of conf. #2 by fine-tuning P and I term constants while keeping small steady-state error.

Regards, llandre

Reply to
jaysbasketball

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.