Octo clock distribution

[staticfloat]

We need to switch the XTRX over to using the external reference clock provided by the Octo board. This configuration change should be relatively minor, but we also need to re-verify our CGEN/VCO tunings with the new reference clock frequency.

Switching the XTRX to use the XYNC-provided reference clock seems as simple as writing to the vctcxo.sel CSR, tuning the reference clock (X-ref https://github.com/JuliaComputing/xtrx_julia/issues/79), update our soapy driver's cached reference clock frequency, and possibly re-tune CGEN.

[enjoy-digital]

Control of the Octo peripherals seems to be done over SPI, with the following code:

• https://github.com/xtrx-sdr/fpga-source/blob/master/lib/xtrx/xtrx_peripherals.v#L978-L1013

We can get GPIO SPI mapping from https://github.com/xtrx-sdr/fpga-source/blob/master/lib/xtrx/xtrx_peripherals.v#L1024-L1029:

wire [GPIO_WIDTH-1:0] alt0_se_gpio_out = {
  1'b0, gpio12_alt1_stat,
  alt1_gpio2_pps_iso_o, gpio_spi_sck, gpio_spi_sen, gpio_spi_mosi,
  1'b0, gpio7_alt1_trouble, gpio6_alt1_pci_rstn, gpio5_alt1_usr_rstn,
  1'b0, 1'b0, alt1_gpio2_pps_iso_o, 1'b0
}; 

and https://github.com/xtrx-sdr/fpga-source/blob/master/top/xtrxr5/xtrxr5_ucf.xdc#L223-L266:

##########################################################
# GPIO (BANK35)
##########################################################
# gpio1  - 1pps_i (sync in)
# gpio2  - 1pps_o (sync out)
# gpio3  - TDD_P
# gpio4  - TDD_N
# gpio5  - LED_WWAN
# gpio6  - LED_WLAN
# gpio7  - LED_WPAN
# gpio8  - general (smb_data)
# gpio9  - G9_P
# gpio10 - G9_N
# gpio11 - G11_P
# gpio12 - G11_N

set_property IOSTANDARD LVCMOS33 [get_ports gpio[0]]
set_property IOSTANDARD LVCMOS33 [get_ports gpio[1]]
set_property IOSTANDARD LVCMOS33 [get_ports gpio[2]]
set_property IOSTANDARD LVCMOS33 [get_ports gpio[3]]
set_property IOSTANDARD LVCMOS33 [get_ports gpio[4]]
set_property IOSTANDARD LVCMOS33 [get_ports gpio[5]]
set_property IOSTANDARD LVCMOS33 [get_ports gpio[6]]
set_property IOSTANDARD LVCMOS33 [get_ports gpio[7]]
set_property IOSTANDARD LVCMOS33 [get_ports gpio[8]]
set_property IOSTANDARD LVCMOS33 [get_ports gpio[9]]
set_property IOSTANDARD LVCMOS33 [get_ports gpio[10]]
set_property IOSTANDARD LVCMOS33 [get_ports gpio[11]]

set_property PACKAGE_PIN M3 [get_ports gpio[0]]
set_property PACKAGE_PIN L3 [get_ports gpio[1]]
set_property PACKAGE_PIN H2 [get_ports gpio[2]]
set_property PACKAGE_PIN J2 [get_ports gpio[3]]
set_property PACKAGE_PIN G3 [get_ports gpio[4]]
set_property PACKAGE_PIN M2 [get_ports gpio[5]]
set_property PACKAGE_PIN G2 [get_ports gpio[6]]
set_property PACKAGE_PIN N3 [get_ports gpio[7]]
set_property PACKAGE_PIN H1 [get_ports gpio[8]]
set_property PACKAGE_PIN J1 [get_ports gpio[9]]
set_property PACKAGE_PIN K2 [get_ports gpio[10]]
set_property PACKAGE_PIN L2 [get_ports gpio[11]]

once mapped, this could be added to the gateware and SPI support added to the firmware.

[sjkelly]

The mappings should have been added in: https://github.com/JuliaComputing/xtrx_julia/pull/17

I did take the liberty to recategorize LEDs and PPS. Maybe I want to correct this for simplicity.

[enjoy-digital]

Ah sorry @sjkelly, I should have looked at the gateware changes, good then. With the changes you did I assume you are going to bitbang the SPI?

[staticfloat]

That's certainly one option, but I'm a little worried that bitbanging it may complicate other implementation details. For instance, we want to perform DAC tuning as a remote procedure call (e.g. when we switch clock sources from the 26MHz XTRX reference clock to the 19MHz XYNC reference clock, we will want to engage a DAC tuning procedure run on the RISC-V core. We've been thinking that it may be useful to develop a simple RPC framework for the RISC-V core, something like we can write a value to a CSR to tell the RISC-V core to go execute a predefined program (such as "DAC tune to the frequency stored in some other CSR", or other useful tasks). To do this, I imagine we would need to have the RISC-V core triggering off of an interrupt from the write pulse signal coming off of that CSR, and if we have the RISC-V core performing timing-critical functions (such as bit-banging the SPI) I'm worried that we will give ourselves hard-to-debug errors when interrupts arrive while the RISC-V core is bit-banging.

Do you think it's better for us to actually instantiate a SPI core that can handle the communication here, or is it fine to just bitbang?

[enjoy-digital]

@staticfloat: This can indeed make sense to keep direct peripherals control by the RISC-V and add a simple RPC between the Host and RISC-V to just high level commands.

For the Octo clock control, we could then:

• Rename the GPIOs to SPI pins names (since we are only going to use these GPIO for SPI, it will provide better readability).
• Add the LiteX's SPIMaster core to the design.
• Add a simple SPI dump function to the RISC-V core just to verify the hardware for now and Octo SPI peripherals.
• Add a proper configuration of the Octo SPI Peripherals.

We could then add the RPC between the Host and RISC-V.

[sjkelly]

Closed in #107