Right now on revC, CLKIF is connected to GBIN4 and CLKREF is connected to GBIN5. CLKIF can be either an (FPGA) input or an output; CLKREF is always an (FPGA) input.

On iCE40, a PLL is connected in such a way that it is always in an input path of an SB_IO tile. Moreover, it always uses a global buffer. So, the PLL placed at SB_IO of GBIN4 uses a) the G4 network for its PLLOUTGLOBAL output and b) the input path of the SB_IO pin.

Currently, we have two possible cases:

• No PLLs are used. CLKIF can be an input or an output, CLKREF can be used.
• One PLL is used. The PLL is placed in the CLKREF input path, and CLKREF cannot be used. Since there is nothing to generate the clock from, CLKIF can only be an input.
• Two PLLs are used. Impossible.

I have a proposal that allows two PLLs to be used. This would happen by:

• Making CLKIF an output, which is compatible with a co-located PLL.
• Connecting CLKREF to a different ball, apart from its normal L5. K4 (currently ~ALERT) seems well suitable, and nothing is currently using FPGA alert anyway, none of that path is implemented.
• Connecting ~ALERT to a different ball, instead of its normal K4. B10 would likely work, and result in no disruption.

Then this case becomes possible:

• Two PLLs are used. Both CLKIF and CLKREF input buffers are used for PLLs. Clock is routed from CLKREF_AUX to a SB_GB global buffer. A DDR output pin at CLKIF outputs the clock.

This would allow us a significant increase in flexibility at the cost of insignificant ball assignment change and having to route ~ALERT via an even more meandering path, which doesn't really make it much worse anyway.

@daveshah1 Can you please confirm my understanding of interaction of PLLs and input buffers here?
@marcan Can you take a look at routing and ballout, in case I'm missing something?