Without connecting anything else to the VIDOR, the only clock we're given to work with is one
that comes from the SAM microcontroller. Here it is on the VIDOR schematic, output from the SAM
part and going into one of the dedicated clock inputs.
I haven't tried to look at it directly with the 'scope. The processor is in quite a confined
space between the headers, so it would need doing very carefully.
If I take that clock and simply push it back out of an IO pin, I see this on the oscilloscope.
Here we're looking at the rising edge after the one being triggered on, i.e. the end of the
first full cycle. About 1ns of jitter. More than I was expecting.
For comparison, this is the equivalent experiment with my MAX CPLD board with its 50MHz crystal
oscillator, pushing the clock back out of an IO pin.
I wondered if we could use the PLL in the FPGA clock block to clean up the jitter. The Cyclone
10 datasheet has this to say
so whilst not necessarily a particularly good idea, it does look like the PLL could just about manage with
that input as it jitters around.
Way to find out is to try it. This is the output from a PLL set to take the 48MHz clock coming
in and produce a 100MHz clock. (I can literally see the change to 100MHz, because I left the
Johnson counter in there and the LEDs are still sequencing round, only about twice as fast.)
Leaving aside that my 200MHz oscilloscope can only display it as a sinewave, it is much
steadier.
For a lot of simple purposes the jitter on the 48MHz clock wouldn't matter anyway, but there is
the option of cleaning it up with a PLL and, for anything really critical, there's nothing to
stop you adding a xtal oscillator to your own external circuitry for a project. As you can see
from that snippet of the schematic, there's access to several of the dedicated clock lines from
the Mini PCIe connector (the signals that start PEX_).
Top Comments