>
> appended below is an email from david mcmahon that's
> needed/recommended for instruments that use xaui links to send
> data from one board to another, where these boards are run off the same
> clock,
> sending data synchronously from one board to the other.
>
> most of the large instruments we are developing are globally asynchronous
> (eg: the packetized correlator, where data is time stamped, and data
> links and boards run asynchronously) - these instruments won't have
> this problem,
> and no fix is needed.
I guess I'll speak here and demonstrate my ignorance, but this has been
bugging me...
How do you run the processes asynchronously? The PFB/FFT blocks do not
have an "enable" signal that you can use to make them wait for another
data packet. In other words, the PFB/FFT blocks must have a data point
every clock cycle or lossage happens. Or am I off the track?
I've read Aaron's PAPER paper, but I have not seen how it works in a model.
Could someone show me (conceptually) how to build a simple spectrometer
model that does this:
RF->sampler/iBOB -> bee2/fpga1-> bee2/fpga2 -> 10 GBE-> computer
SAMPLE PFB/FFT ACCUM/STOKES
using the asynchronous method with continuous data to disk without losing
samples due to the packetizing?
We'll look at the problem described below as it applies to our systems.
We (Randy and Jason) have been working for 6 weeks or so on subtle timing
issues involving syncing up ibobs and bees, including using the internal
bee links between FPGA's.
John
>
> however, there are several instruments that will/might benefit from
> the technique that david and oren figured out:
>
> ATA beamformer (oren implemented the fix already)
> seti spectrometer
> SMA beamformer
> ibob/bee2 systems glen jones is developing?
> ibob/bee2 systems at nrao?
>
> dan
>
>
>
> David MacMahon wrote:
>> It's more to do with interfacing with the yellow blocks where the
>> sender and receiver have the same clock. In that case, it is OK to
>> drive rx_get with a '1' (i.e. "give me a sample every cycle"), but in
>> order to avoid running the async fifo on empty, which risks
>> underflowing the fifo, rx_get should be driven with an inverted and
>> delayed version of the "rx_empty" signal. This defers assertion of
>> rx_get until some number of cycles after the fifo gets its first
>> sample, which allows the fifo to run a little above empty, which
>> provides the buffering needed to ensure that the burstiness of the
>> async protocol doesn't lead to fifo underflows.
>>
>> Dave
>>
>> On Jun 5, 2008, at 11:02 , Dan Werthimer wrote:
>>>
>>>
>>> dave,
>>>
>>> what's the "improvement to bee2 xaui links"?
>>> (in matt's email below)
>>> anything we should use?
>>>
>>> thanks,
>>>
>>> dan
>>>
>>>
>>>> Here are a few updates...
>>>>
>>>> BEE2s
>>>> Oren, Dave, ... have made major improvements in the BEE2 XAUI links.
>>>>
>>
>
>
