12-04-2017 10:22 AM
I'm currently working on a design on a VC7215 board, which involves using an external reference clock generated by an ADC to provide two reference clocks by mean of the SUPERCLOCK-2 Module to 24 GTH trasceiver lines (6 quads).
For now, I was able to program the SUPERCLOCK-2 module by mean of a VIO made available in a Xilinx IBERT example design, through a tcl script which sets the si570 chip of the module to provide a clock reference with a certain frequency. Then, it's easy to load a custom bitstream which takes in input the generated reference clock while the module is still running.
What I'm trying to do is to employ an external clock, generated from the ADC, as an input to the SUPERCLOCK-2 module through EXT_CLK input, to provide two reference clocks through CLK_OUT1 and CLOCK_OUT2 output pins of the module, with the same frequency of the input one.
What I understood is that I have to find a way to program correctly the si5368 chip through the VIO signals, but I couldn't find a way to know what does these signals stands for.
I tried to look at:
But I couldn't manage to find a correlation between the VIO signals and the pinout of the Si5368 Module.
If anyone has ever faced a similar problem, any help would be very appreciated.
Thanks a lot
12-06-2017 01:55 AM
Apparently until now nobody has ever faced this problem or found a solution to it. Waiting for someone to share any consideration, I'll keep this post updated.
So, I took a look at some design files of the Superclock-2 module provided by Xilinx through an SD card, containing a folder called scm2_merge:
From these I extrapolated the folllowing information, which apparently map the VIO pins with their function
si570_idcode, ===> SI570 I2C Addr
si570_addr, ===> SI570 ROM Addr 0-127
si570_usren, ===> SI570 User Enable
si570_usrdin, ===> SI570 User Data In
si570_recall, ===> SI570 Device Recall NVM settings
si570_start, ===> SI570 Command Start
si570_done, ===> SI570 Command Done
si570_freq, ===> SI570 ROM Freq * 0.001 MHz
si5368_addr, ===> SI5368 ROM Addr 0-127
si5368_dsbl, ===> SI5368 Output Disable
si5368_reset, ===> SI5368 Device Reset
si5368_usren, ===> SI5368 User Enable
si5368_usrdin, ===> SI5368 User Data In
si5368_start, ===> SI5368 Command Start
si5368_done, ===> SI5368 Command Done
si5368_freq, ===> SI5368 ROM Freq * 0.001 MHz
si5368_clkin, ===> SI5368 CLKIN Select
si5368_clkwr, ===> SI5368 CLKIN Select Update
pca0_ctrl, ===> PCA0 Bus Expander Control
pca1_ctrl, ===> PCA1 Bus Expander Control
i2c_sda_out, ===> I2C SDA I/O Pin
i2c_sda_in, ===> I2C SDA I/O Pin
i2c_scl_out, ===> I2C SCL I/O Pin
i2c_scl_in, ===> I2C SCL I/O Pin
i2c_dev_addr, ===> I2C Device Address
i2c_reg_addr, ===> I2C Register Address
i2c_noreg, ===> I2C No Register Address Required
i2c_wr_data, ===> I2C Write Data
i2c_rd_data, ===> I2C Read Data
i2c_start, ===> I2C Command Start
i2c_ack, ===> I2C Command Acknowledged
i2c_done ===> I2C Command Done
What I think is that it's possible to correctly program the si5368 chip by properly driving si5368* signals. I thought that by setting these signal following the poor info above would have been enough, but apparently it's not, I tried several configuration of their values but still I wasn't able to buffer the input clock and provide two lowered-jitter output replication of it.
I thought it would have be much simpler to bufferize a clock, considering time and effort spent for the rest of the design, I'm very surprised.
I'll Keep working on solving the issue.
12-14-2017 03:10 AM
I tried driving directly the i2c signals of the si5368 chip setting properly the device registers but I didn't obtain any effect.
At this point the only workaround I found is to driving the quads with the original differential reference clock REFCLK(P/N) coming from the ADC.
In such a way, I provided the reference clock to the two groups of 3 quads each in the following way:
Quad 0, 1 ,2 : REFCLKP
Quad 3, 4, 5 : REFCLKN
I know it's a very bad solution but it's the only one I found for now, and I managed however to lock the clocks and obtain a proper reset sequence to the transceivers.
I didn't test still if this solution works for the RX of the signals coming from the ADC. I this workaround is effective I will post an update