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 <mdex...@berkeley.edu> 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 <jef...@mit.edu> >> To: "casper@lists.berkeley.edu" <casper@lists.berkeley.edu> >> 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 >> >> >> >
