Hi, John,
On Jul 16, 2013, at 7:41 AM, John Ford wrote:
>> FWIW, when the PAPER correlator used FPGA-based X engines, the X engines
>> ran asynchronously from the F engines at 5% faster than the F engines (210
>> MHz vs 200 MHz). I don't really understand why they ran asynchronously.
>> IMHO, it would have made things far simpler if the F engines fed a clock
>> to the X engines so that they could run synchronously.
>>
>
> Hi Dave. I think it was due to the philosophy of making everything on
> separate boards a separate asynchronous system.
I think your right, but in the case of the (now obsolete) PAPER FPGA-based X
engine, blind adherence to that philosophy made the system more complicated
than it needed to be. I think there also might have been a proof-of-concept
aspect to the design decision that overrode the KISS principle ("let's show
that it can be made to work even though it will make things more complicated").
Unfortunately, I think this approach has somehow worked its way into the
CASPER dogma.
Whenever possible, I prefer to keep everything in the same clock domain.
High-speed serial or packetized links generally require leaving the application
clock domain, but things are much easier on the receive side if things are
returned to the same application clock domain as soon as possible. Clock
forwarding is a great way to achieve this. It might mean a few more cables,
but it can simplify the logic tremendously.
> We broke the rule with
> GUPPI (it does exactly as you suggest; the ibob feeds the clock of the
> bee2) and in spite or the heresy, it worked out well for us...
Exhibit A! I have also had success with "globally synchronous, interconnect
asynchronous, locally synchronous" (GSIALS?) CASPER designs.
Thanks for the feedback!
Dave
