<_whitenotifier-c>
[Glasgow] whitequark opened issue #97: Make both PLLs usable in theory - https://git.io/fhH6O
<_whitenotifier-c>
[Glasgow] whitequark opened issue #98: Export production files for revC0 - https://git.io/fhH6s
<_whitenotifier-c>
[Glasgow] whitequark assigned issue #98: Export production files for revC0 - https://git.io/fhH6s
<_whitenotifier-c>
[Glasgow] whitequark commented on issue #89: Use SB_GB_IO instead of SB_IO+SB_GB - https://git.io/fhH6c
<_whitenotifier-c>
[Glasgow] daveshah1 commented on issue #97: Make both PLLs usable in theory - https://git.io/fhHik
<_whitenotifier-c>
[Glasgow] whitequark commented on issue #97: Make both PLLs usable in theory - https://git.io/fhHiL
<_whitenotifier-c>
[Glasgow] daveshah1 commented on issue #97: Make both PLLs usable in theory - https://git.io/fhHim
<_whitenotifier-c>
[Glasgow] whitequark commented on issue #97: Make both PLLs usable in theory - https://git.io/fhHi3
<_whitenotifier-c>
[Glasgow] daveshah1 commented on issue #97: Make both PLLs usable in theory - https://git.io/fhHiZ
<tnt>
whitequark: I haven't done the diagrams, yet, but sourcing the if_clk from the ice40 doesn't seem to help much. with d_out0(0) d_out(1), that means you get the if_clk rising edge right in the middle of the data you output. So ice40 -> FX2 works great, plenty of margin for both hold & setup time. But ehn that means that compared to the internal clock of the ice40, the external ifclk is delayed by ~4ns (clk->out) + 16.6 ns (half period at 30 MHz). Then the FX2 needs
<tnt>
Only way I see to have it at the next cycle is to have the if_clk you output be 90 deg out of phase wrt to the internal version by using both PLL output.
<whitequark>
hmmm that's bad
<tnt>
Which ... you can't do because the pin used for clk_if is in the same IOB as the one used for D6 and so have to use the same clock.
<whitequark>
"Then the FX2 needs" < text was cut off here
<whitequark>
I assume inverting the clock wouldn't work either?
<tnt>
Then the FX2 needs 15 ns to output the next data after detecting the rising edge.
<tnt>
That means that data becomes valid at t=35.6ns. (wrt to the internal version of the if_clk). Meaning your only hope to sample that is to sample it on the falling edge of the internal if_clk and resync it to the internal rising edge, and then
<tnt>
you again have the 2 cycle latency between outputing an edge and being able to get the value that the FX2 has output on that edge.
<whitequark>
also, what about outputting the clock directly through the pin (without a register, just via global buffer) but outputting data via the DDR register?
<tnt>
If you invert the clock, then it's the iCE40 -> FX2 direction that fails.
<whitequark>
right
<tnt>
wrt to directly outputting the clock ... I have no idea. Need to find the timing numbers for that.
<tnt>
The revC CLK_IF doesn't share an IOB with anything else so the 90deg would work there.
<whitequark>
I don't want to spend a PLL on the FX2 interface though
<tnt>
Where is the 30M coming from ?
<whitequark>
FX2. I can do 48M instead of 30M
<whitequark>
48M wouldn't clear timing on revAB
<tnt>
oh righ it's clk_ref ?
<whitequark>
yes
<tnt>
whitequark: outputing the clock directly /might/ work.
<tnt>
icecube seems to indicated that doing that is 3.4 ns slower clock-to-out vs a DDR register output (for the rising edge ... falling edge numbers are different).
<tnt>
setup time for the fx2 is 3.2 ns.
_whitelogger has joined #glasgow
<whitequark>
is that for UP5K or HX8K?
<tnt>
That was the UP5k
pke has joined #glasgow
<marcan>
bgamari: there is one "required" fix over revC0, adding two resistors. but they're trivial to tack on.
<marcan>
the problem if you build master is that it would be an "oddball" revision that we don't have a name for, other changes will likely go in before revC1
<bgamari>
marcan, are they included in master?
<bgamari>
mm
<bgamari>
alright
<marcan>
they are, but that
<marcan>
the resistors just go between VIO and GND on the headers, so it's a trivial mod
<marcan>
(adjacent pins)
<bgamari>
sure
<bgamari>
has any consideration been given to adding protection diodes to the LVDS bank?
<bgamari>
it would no doubt be tricky to fit
<marcan>
it's deliberately raw FPGA pins because external hardware is required to use it for most purposes
<bgamari>
sure
<marcan>
it's not intended to be used as a general purpose I/O port for most people
<marcan>
it's there if you need it but you're in charge of all the details :-)
<bgamari>
nevertheless, the header does pose an ESD hazard
<marcan>
you can just not mount it :-)
<bgamari>
fair enough
<bgamari>
admittedly I have no idea how you would fit them
<marcan>
yeah I don't think it's going to happen, realistically
<bgamari>
sure
<marcan>
also the FPGA might already have clamp diodes? it seems undocumented
<bgamari>
marcan, it likely has something but they are likely pretty small
<bgamari>
what is the time-frame for C1 to be tagged?
<marcan>
ask whitequark, but if I had to pull a number out of my ass, a month?
<bgamari>
cool
<marcan>
there's been some talk about messing with the FX2<->FPGA pinout for reasons related to the PLL
<marcan>
if there is a "big" change that will probably be it, assuming we validate the rest of the hardware and nothing major is screwed up