<daveshah>
Routed clocks via fabric many times, never seen any issues
<marcan>
cool
<marcan>
we threw another doubled up pin to make the remaining PLL flexible (can use the PLL with routed input, in that case we can get the refclk from an auxiliary pin into fabric)
<marcan>
ice40 PLLs are such a pain
<marcan>
I think with that Glasgow revC1 is basically done
<marcan>
(so if anyone wants to review the design, hint hint!)
<azonenberg>
daveshah, marcan: the main thing you might see is duty cycle distortion
<azonenberg>
(i'd be interested to see numbers re that)
<marcan>
I think it's supposed to be the main FPGA core logic clock, in which case I think it doesn't matter much since the flops should trigger off one edge only?
<marcan>
whitequark: thoughts?
<tnt>
there are some neg edge stuff in the fx2 interface
<azonenberg>
well its more, idk how much DCD you'll see
<azonenberg>
but i know they optimize the global clock tree for that
<azonenberg>
and possibly not fabric routing
<azonenberg>
wrt uneven rise-fall times
<tnt>
timing numbers for negedge vs rise edge in icecube2 are +- 1ns
<tnt>
(or in that order of magnitude)
<whitequark>
marcan: yeah the fx2 interface has some negedge stuff
<whitequark>
but the tolerances on that are fairly wide
<marcan>
azonenberg: keep in mind this is just fabric to get it into the gclk tree
<whitequark>
so i think it's fine
<marcan>
so not a gclk input, but still becoming a gclk eventually
<azonenberg>
marcan: yeah but if it's uneven going into the gclk, it will be uneven on the tree
<azonenberg>
GIGO
<azonenberg>
the question is a) how much distortion you see and b) how much your design cares
<azonenberg>
I can't answer either, just pointing it out as a red lfag
<marcan>
of course, but it's not going to spend much time outside the gclk is what I'm saying
<whitequark>
we can test this easily enough
<tnt>
whitequark: did you ever manage to create a design that fails reliably (wrt to the fx2 thing ?)
<whitequark>
tnt: not yet
<marcan>
are we still changing CLKIF to an output, btw? I think we don't *have* to any more, unless you want to open up that PLL to dual-output modes too
<whitequark>
i think we have to, don't we?
<marcan>
I don't think so, as long as the PLL is used in single output mode
<marcan>
it only takes over the adjacent ibuf if you use that second output
<marcan>
and the only useful mode there, since we already have CLKREF on another pin, is the dual output mode
<whitequark>
oh, that simplifies things considerably
<whitequark>
excellent then, this is as future-proofed as i can imagine
<daveshah>
FWIW, I've seen picorv32 run fine at the usual 16MHz on an UltraPlus using no global clocking at all
<daveshah>
I think a short stretch of routing will be fine
<whitequark>
our clock is 48 MHz on CLKREF
<daveshah>
But this is also a 2-3x faster HX
<whitequark>
I guess...
<marcan>
dammit I can't find the lattice doc that actually explained this
<daveshah>
Yes, the second output isn't that useful
<marcan>
right, so you get to pick 0deg with delay, 90deg with delaw, raw pll output, and raw pll output /2
<marcan>
on each port
<marcan>
so some design might want to use two options from those I guess, but it would have to be a pretty niche thing
<daveshah>
A register is often good enough for /2 if phase & duty aren't important