While you're at it, check what clock source you have in xsg core config. Also, adjust your source clock and see if the result from est-brd-clk changes On Jul 8, 2013 7:20 PM, "Dan Werthimer" <[email protected]> wrote:
> > > it might be difficult in simulink to connect clock to sync_out, > but you could use a divide by 16 counter, enabled all the time, > and then connect the divider output to the sync output > and measure with a frequency counter. > > dan > > > On Mon, Jul 8, 2013 at 1:33 PM, Matt Dexter <[email protected]> wrote: > >> how about make a design that delivers a copy of the >> FPGA clock to the Roach2's SYNC_OUT pin J11 ? >> then you could connect that signal into a frequency >> counter, oscilloscope or ... >> This won't be super low jitter but otherwise it will >> be a fair representation. >> >> >> On Mon, 8 Jul 2013, Haoxuan Zheng wrote: >> >> Date: Mon, 8 Jul 2013 20:20:50 +0000 >>> From: Haoxuan Zheng <[email protected]> >>> To: "[email protected]" <[email protected]> >>> Subject: [casper] (no subject) >>> >>> Hi Casper, >>> Is there any way to find out the FPGA clock rate precisely? We are >>> suspecting that our ROACH2s are not running at the frequency (202MHz) as >>> we >>> specified in the design. We tried the python function in katcp, but it >>> does >>> not look reliable enough. We hacked that function and increased the time >>> between counter reads to 30 seconds (instead of 2 seconds), and the >>> reading >>> is still not that reliable. They all read roughly around 200.2MHz, and if >>> that's the case, then we must be doing something wrong regarding the >>> clocks >>> and our 202MHz did not go into the design. We are using internal FPGA >>> clocks >>> with no ADC or anything. >>> >>> Background: >>> We are testing 4 ROACH1 F-engine to 4 ROACH2 X-engine 10GBE set up, 16 >>> connections in between. Each F-engine is sending to all 4 X-engines, and >>> each X-engine is receiving from all 4 F-engines. We have a very simple >>> sending and receiving FIFO buffer logic. The thing we see is that one >>> particular X-engine always has all 4 buffers filled up in a fixed amount >>> of >>> time (32K buffer fills up in ~270 seconds). We swapped a lot of thing >>> around >>> to test which part is wrong in the system, and we nailed it down to >>> something physical in that X-engine, and the fact that it fills up >>> indicate >>> that X-engine clock is running slower than we set it to, because we set >>> X-engine clock to be 202MHz vs 200MHz on F-engine. Therefore we would >>> like >>> an definitive measurement of the actual X-engine clock that is running. >>> >>> Plot explanation: >>> It's plotting one of the four FIFO buffer filling up over 270 seconds. >>> The >>> vertical axis is the literal number of numbers currently stored in the >>> FIFO. >>> This FIFO should on average get 1 number every 8 clocks from the F-engine >>> (200MHz) receiver, and should get 1 number pumped out every 8 clocks on >>> X-engine (202MHz), so this long term build up definitely suggest that the >>> clocks are not what we think. >>> >>> >>> Thanks a lot and sorry for the long email! >>> >>> Jeff >>> >>> >>> >> >
