Listening to Clock Jitter

I have tried to listen to clock jitter before but never succeeded in that, well until now!

Test setup: 12MHz clock derived either from external MEMS oscillator or from Lattice XO2 FPGA on-chip PLL generating 12MHz output from 12MHz reference input. The clock is feeding 8 bit shift register that is repeatedly sending out 8 bit pattern. Shift register output is driving FPGA IO pins, and those are connected via audio transformer to 600 ohm differential input of Focusrite USB Audio.

There is a push-button that selects between 12MHz from MEMS and from internal PLL.

Idle pattern 0x69 (..01101001..) low noise level is MEMS oscillator, switching to PLL clock add significant noise, that can take 2 discrete levels. This can only be if the "clock jitter" noise is also repeating with 8 (or some power of 2) clocks.

Idle patterns 0x55 (..01010101..) and 0x33 (..00110011..) did not show any noise difference between MEMS and PLL clock sources.

Interesting uh? Different silence pattern do exhibit so different output: 0x69 is sensitive to clock, while 0x55 and 0x33 are not. What about 0x0F ?

Pattern 0x0F creates much higher level tone than 0x69, and the discrete levels are now more similar to each other compared to the levels of 0x69 pattern.

This tone comes from 0x0F the frequency is about 3500 Hz.

So basically we have a signal chain like this

12MHz MEMS clock -> PLL -> 12MHz -> divide by 8 -> 3.5Khz tone! If we remove the PLL from the chain the tone is gone.

If the PLL makes such a clear tone out of 00001111 pattern, it should also have some impact on DSD audio as well?

Let's try, I start DSD audio data streaming from the PC to the same hardware setup (8 bit shift register..) and yes, the switch between MEMS clock and PLL clock clearly adds white noise when PLL clock is selected.

So confirmed - clock jitter does have impact on DSD audio quality. OK, yes the XO2 PLL clock must be indeed really bad in terms of "audio quality" but this experiment clearly shows that better clock gives better results.

I can now use this or similar setup to compare clock jitter from different sources.

Fast-Serial, Part II

Taking the FPGA code for the fast-serial "echo" to Vivado did take, well no time!

The "RTL" block includes exactly the same code I used previously on Gowin and Lattice boards. I even left the "LED counter" port there with connection to VIO (Virtual I/O).

This is how the setup looks like XO2000 + TE0723

First attempt did return garbage and not correct echo, this is possible due to timing issues, I used now maximum serial interface clock of 50MHz. In the test with Gowin/Lattice I had clock of only 12MHz and did tweak the interface to work by using negative edge flip-flop. Now the path from FTDI to the "processing" FPGA (Zynq on TE0723) has additional not constrained delay introduced by the XO2 FPGA on XO2000 board. So for the functional test I am reducing the clock to around 12MHz - and now I have correct echo, same as it was with the same code on Gowin and Lattice boards.

Time to write the actual IP Core now!

First I add AXI-Stream ports to the "top" VHDL file I used previously as design top and then I add this as module to newly created Vivado BD and it looks then like this:

This is nice, I did not expect that Vivado would auto detect the AXI-Stream Interface, but it did and correctly too! As next step I create VHDL wrapper to be my Testbench toplevel file and add 7 lines of VHDL there. Testbench is ready!
Now the real work begins, after about 22 lines of VHDL code I am ready with "receive only" IP Core, time to simulate, does it work as expected? Yes it does, back to real life. I add ILA (Integrated Logic Analyzer) to the BD I used before, so it looks now like this:

Now a real test, sending "Hello World!" Core works and indeed it does.

This is ILA snapshot from "12345678901234567890" sent with putty. There is a thing that FT2232 datasheet does not tell you, it seems there is always 3 extra bits of IDLE between bytes received.

Next step? Adding transmit portion, testing it and then wrapping it into Vivado Catalog IP Core...

FTDI Fast-Serial Mode with FPGA

FTDI USB devices FT2232H (& Co) have one interesting but rather seldom used interface type called "high-speed opto-isolated interface". While the name implies it was initially designed for opto-isolation there is no need to use the isolator, the interface can be used without it equally well. The benefits of the interface is that we only need 4 I/O Pins total for bidirectional data transfer (max clock rate 50MHz!).

I have been playing with the idea to use this interface in some projects for some while already. The first successful test was done within a few hours after I got an small nice and nifty board with FT2232H and small FPGA from China Gowin Semiconductor.

LittleBee board from Trenz Electronic

Needless to say the board is designed by me too. Well to test the interface as quick as possible I tried the "uart echo" approach, I connected the FSDO data from FT2232 back to FSDI input of FT2232 (with some clocks delay implemented as shift register) and provided some free running clock on FT2232H clock pin FSCLK. I hoped this would work as "echo" and indeed after programming the FT2232 Channel B to "fast serial" mode using FT_PROG utility from FTDI it really worked, I got echo using putty as UART terminal program.

This is of course no actual real use yet, but it shows that the simple way of using standard COM port drivers to send high speed data really works. If we want to talk to the "application" in the FPGA we use standard serial port drivers be it on Linux or Windows host (Virtual COM port drivers are provided by FTDI).

Next Step - some real use ? For this I need to write some more complex FPGA code than the serial loop-back I used for initial testing. I could continue using the LittleBee board. But I would prefer to use my favorite environment Vivado for the IP Core development. I have FPGA boards that include Xilinx FPGA and have FTDI Channel B connected to the FPGA I/O Pins (as example TE0723 Arduino-Zynq board) but well there could be problems when trying to connect to channel B fast-serial and at the same time use channel B as Vivado JTAG (actually I tried it once and really did face such problems). Also this usage would need FT_PROG to be used on TE0723 an action that would destroy the Xilinx JTAG License ID in the FT2232 User EEPROM.

Solution? Let's use TE0723 for FPGA development and debug but with FT2232H connected externally to the PMOD on TE0723. This can be easily done, there is not even need for flying wires for this, I can create a FT2232 "custom breakout" from say a Lattice FPGA board XO2000

XO2000 board from Trenz Electronic

I do have several REV 1 PCB's that are "not for resale" - utilizing one them as FTDI fast-serial to PMOD adapter would be good use. In order to "mate" properly I solder 2 row male pin-header from the bottom of the PCB. Hmmm - I should probably cut the VCC pins in order to not short-circuit the 3.3V supplies of the two boards? Yes it would have been easier to solder 2x5 header instead of 2x6 header in the first place.

Porting the code from Gowin to Lattice Diamond was done in less 30 minutes and "echo" test performed within an hour or so. So far so good.

Taking out the "echo" code and replacing it with "wiring only" code that directly connects signals from FTDI Channel B to PMOD pins takes another 30 minutes.

Done, now I can proceed with development with Vivado, the fast-serial interface comes from second FT2232 with no Xilinx JTAG license, so Vivado would not see it at all.

I guess the first step would be taking the echo loop-back code that is tested and working and implement it in Xilinx FPGA to verify the setup and pin-mapping is correct. Then it would be time to proceed with real IP Core development for the fast-serial mode.

(to be continued)