Forum Discussion
Hi Deshi,
The whitepaper gave me hope. I was able to insert the CLKUSR successfully (I believe). I see the PLL and clock divider in the post-fit netlist. I left the GPIO oe and dout ports open, since the whitepaper seems to indicate this.
However, this has no effect on the calibration. There isn't any way to confirm that the NIOS receives the clock which it expects, so it's possible Quartus has not made the connection. (I'm using Quartus prime standard, 18.1.) Is there any way to confirm this?
I only have a single-channel transceiver (running a custom protocol unfortunately), and separate fPLLs, using the same transceiver reference clock. The PCS does have a reconfig interface enabled on it, but I'm not using it for anything. Is there any requirement to run the reconfig_clock off of the transceiver clock? I have been assuming it is only a fabric clock.
Do you have any reference designs which implement this workaround?
Here is how the logic is connected for your information:
-- Backend method of inserting clkusr using GPIO and IOPLL.
-- Generate 200M from xcvr refclk
u_clkusr_pll : component clkusr_iopll
port map (
rst => por_pll_rst ,
refclk => clk_312p5_i ,
locked => clkusr_locked_w ,
outclk_0 => clkusr_200_w
);
-- Divider
process (clkusr_200_w) begin
if rising_edge (clkusr_200_w) then
clkusr_w <= clkusr_locked_w and not clkusr_w;
end if;
end process;
u_clkusr_gpio : component gpio
port map (
din(0) => clkusr_w , -- din.export
dout => open , -- dout.export
oe => open , -- oe.export
pad_io(0) => clkusr_io -- pad_io.export
);