Hi,

I am having trouble building a DRTIO Satellite on a KC705. When building 125 MHz variants, I got a system up and running in which a Kasli functions as master while the KC705 board I have is the satellite.

When building the 100 MHz variant of the KC705, the serial interface (while configured for 115200 Baud) seems to be running at ~ 125/100*115200 Baud. I've build my gate/firmware like this:

python kc705.py --variant NIST_QC2_Satellite --drtio100mhz

I see this problem with the variant as included in Artiq. Can you confirm that the satellite variants for KC705 work fine in your hands / for other users?

Is this a symptom if bank 12 does run at a VCCIO of 2.5V instead of 3.3V? The board I have has not been reprogrammed to run at 3.3V, but in Standalone builds I could run in different clock configurations using the Si5324 without any problems. At the end of the day I do need bank 12 to run at 2.5V for LVDS support.

When looking at the source code, my impression is that a 125 MHz reference clock is expected and that the MiSoC _RtioSysCRG for KC705 is currently setup to provide a 125 MHz sys_clk. Is there something I am missing regarding how a 100 MHz sys_clk is supposed to be generated if drtio100mhz is set? As far as I know there are 100 MHz KC705 variants out there, do you know for which versions of Artiq that is true?

Thank you for the help!
Felix

Seems like this was an oversight on my part. Looking into it currently.

Is there something I am missing regarding how a 100 MHz sys_clk is supposed to be generated if drtio100mhz is set?

Initially, the sys clock is 125MHz ("bootstrap clock"). That allows setting up Si5324 (or Si549), to which the whole system would run. That would be set to 100MHz, and the system would switch to it and reboot.

Setting the bootstrap clock to be also at 100MHz causes kc705 not to boot (possible SDRAM issue). I will look into another way of getting proper UART output.

Still, does UART not work at all then, or does it stabilize after initial reboot - when Si5324 should be enabled and generating 100MHz clock?

As far as I know there are 100 MHz KC705 variants out there, do you know for which versions of Artiq that is true?

Since these changes that would affect the UART happened around RTIO/SYS clock merge, I would wager they're running ARTIQ-7.

I do not see a switch happen, if it does the frequency is still at 125 MHz. Here's the generated MMCM from top.v:

MMCME2_ADV #(
.CLKFBOUT_MULT_F(4'd8),
.CLKIN1_PERIOD(8.0),
.CLKIN2_PERIOD(8.0),
.CLKOUT0_DIVIDE_F(4'd8),
.CLKOUT0_PHASE(0.0),
.CLKOUT1_DIVIDE(2'd2),
.CLKOUT1_PHASE(0.0),
.DIVCLK_DIVIDE(1'd1)
) MMCME2_ADV_1 (
.CLKFBIN(mmcm_fb_in),
.CLKIN1(txout_buf),
.CLKIN2(bootstrap_clk),
.CLKINSEL(crg_o_clk_sw),
.RST(crg_o_reset),
.CLKFBOUT(mmcm_fb_out),
.CLKOUT0(mmcm_sys),
.CLKOUT1(mmcm_sys4x),
.LOCKED(mmcm_locked)
);

Based on this I'd think we run at 125 MHz instead of 100.

I'll be happy to get in there and fix this, submitting a patch when I'm done. But since I'm new to Artiq I wanted to check in and make sure I'm not missing something.

Actually, I have to admit I am confused about the details of what the problem here is.

If the memory controller does not work at 100 MHz, how would this have worked out in previous releases? Or have there been changes to the memory controller recently that make it not function at 100 MHz?

Do you mind guiding me through how to most efficiently address this issue?

Thank you for your help!

Based on this I'd think we run at 125 MHz instead of 100.

The clock period is given to Vivado to calculate timing, but of course it cannot be controlled exactly if it comes from outside. Clock is switched and 100MHz should be provided, based on MMCM multipliers (multiplier and divider are the same), as long as VCO is still within spec (and it should be).

If the memory controller does not work at 100 MHz, how would this have worked out in previous releases?

Previously there were two separate clocks: one for 'sys' (CPU) and the other for RTIO. System clock (where memory lies) would be at 125MHz, but RTIO could be adjusted more freely.

Do you mind guiding me through how to most efficiently address this issue?

I opened an issue for this and currently I am at a bit of a loss - I cannot even tell for sure if memory is the real culprit, or just a symptom of something in the (rather complex) gateware assuming 125MHz and not working as intended at 100MHz. Will check on a Kasli, as it uses different memory modules and would suffer from the same issue. I'll keep you updated on my findings.

Thank you for looking into this!

I'll also poke around on my end, but please let me know what you find.