Yes, the design is compiled to run at 1000 MHz.

Nimish

On Wed, Nov 16, 2011 at 3:44 AM, Andrew Martens <martens.and...@gmail.com>wrote:

> Hi Nimish
>
> I am copying my reply to the main casper list in the hope that it may
> help someone else in the future.
>
> Have you compiled your design to run higher than 800MHz? It seems
> strange that the design works correctly up to 800MHz but not higher. If
> the design is not compiled to run above 800MHz, then strange things may
> happen.
>
> Regards
> Andrew
>
> On Tue, 2011-11-15 at 11:20 -0500, Nimish Sane wrote:
> > Hi Andrew,
> >
> >
> > Thanks for the reply. Yes, I have a header in each packet that
> > includes a count with which I can verify if we are losing any packet.
> > I have also confirmed that the number of FPGA clock cycles for which
> > we accumulate is correct. So, it seems more of clock related issue.
> >
> >
> > I have done some more experimenting and find that things are working
> > fine for lower ADC clock frequencies (up to 800 MHz). But I am not
> > able to receive packets for clock frequencies greater than that. We
> > are using iADC and want to sample at 1 GHz.
> >
> >
> > I would be glad to know if you have any suggestions to try.
> >
> >
> > Thanks again,
> >
> >
> > Nimish
> >
> > On Tue, Nov 15, 2011 at 2:01 AM, Andrew Martens
> > <martens.and...@gmail.com> wrote:
> >         Hi Nimish
> >
> >         If you are not losing any packets (I assume you have a counter
> >         or
> >         something in every packet to confirm this...?) then it seems
> >         that you
> >         must be accumulating for longer than expected. This could be
> >         because of
> >         a clock that is not running as fast as expected (as suggested
> >         by John),
> >         or because the accumulator is accumulating for more time than
> >         needed.
> >         Have you checked your calculations to determine the number of
> >         spectra
> >         corresponding to the required accumulation time?
> >
> >         Regards
> >         Andrew
> >
> >
> >         On Fri, 2011-11-11 at 14:56 -0500, John Ford wrote:
> >         > > Hi all,
> >         > >
> >         > > I am working on a correlator design (3 antenna, single
> >         polarization)
> >         > > targeted toward a Roach board (250 MHz FPGA clock). It has
> >         3 F engines and
> >         > > an X engine on the same Roach board. We are accumulating
> >         the correlator
> >         > > ouput (and some other calculations), packetizing it (8
> >         packets per
> >         > > accumulation), and then sending it to a PC over a 10 Gbe
> >         link. We expect
> >         > > that time delay between the first packets in each
> >         accumulation to match
> >         > > the
> >         > > accumulation time. However, this is not the case. For an
> >         accumulation time
> >         > > of 20 ms, we receive packets corresponding to a new
> >         accumulation on PC
> >         > > roughly every 32 to 33 ms. The number of packets received
> >         per second is
> >         > > less than the expected value by a factor of around 0.6.
> >         When we change the
> >         > > accumulation time (through a software register), we
> >         observe that the
> >         > > packets are still received at a reduced rate by the same
> >         factor of 0.6.
> >         > >
> >         > > We can confirm that we are not losing any packets. Also, I
> >         do not see
> >         > > anything strange in the simulation. I cannot reproduce
> >         this behavior in
> >         > > the
> >         > > simulation.
> >         > >
> >         > > The design includes just a vector accumulator and
> >         packetizer blocks
> >         > > between
> >         > > the correlator output and 10 gbe yellow block.
> >         > >
> >         > > Has anyone experienced such an issue before? Or am I
> >         missing something
> >         > > obvious here?
> >         >
> >         > Maybe your FPGA clock is not clocking at the speed you
> >         expect?
> >         >
> >         > You could put in a divider and connect it to an I/O pin and
> >         measure the
> >         > pulse with a scope.  That would be one way to be sure.
> >         >
> >         > >
> >         > > Thanks,
> >         > >
> >         > > Nimish
> >         > >
> >         >
> >         >
> >         >
> >
> >
> >
> >
> >
>
>
>

Reply via email to