<marcan>
whitequark: I wasn't happy with the layout, also silkscreen turned out to be a problem
<marcan>
I moved the resistor to the front and the capacitor to the back, so we're back at having only 100n 0402 caps, 4u7 0603 caps, and the two 100Ω PLL filter resistors on the rear
<marcan>
also, iff we need to bring out the remaining FPGA pin and back to the FX2 side of things somehow, I have a vague idea how I'd do that
<whitequark>
marcan: ack
<whitequark>
we probably do need it for PLL
<marcan>
basically if I can squeeze in a via in a terrible place, I can do it
<marcan>
alternatively we swap two IO pins but that changes which pins of the banks are assigned to GCLK/PLL and I really don't want to do that
<marcan>
alter-alternatively there is an easier way to swap those pins but it involves doing it *after* the resistor network and afaik kicad has no nice way of doing pinswaps like that
<marcan>
which would mean breaking up the deduplicated IO bank sheets
<whitequark>
ohhh :S
<whitequark>
do you just not want to do it bc it's a lot of grunt work?
<whitequark>
i could do that maybe
<_whitenotifier-1>
[Glasgow] marcan created branch route-remaining-fpga-pin - https://git.io/fhhGp
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to route-remaining-fpga-pin [+0/-0/±1] https://git.io/fjkyU
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan a33d360 - revC1: route remaining FPGA pin (do not merge)
<marcan>
whitequark: made it work anyway
<marcan>
throwing it in a branch for safekeeping
<marcan>
I don't want to change the GCLK/PLL assignments because right now we've been consistent between revA/B/C and this affects user designs (which IO bank pins are nicely PLL/clock capable)
<marcan>
I did have to slightly mess with one of the diffpairs to make that work, so that one needs re-tuning of the skew
<marcan>
which is useful in some cases, but we want it to work with other inputs too, right
<whitequark>
exactly
<marcan>
what about the second PLL pin thing?
<whitequark>
we have one PLL on CLKREF pad, and another PLL on CLKIF pad
<marcan>
it's the same PLL, right?
<marcan>
just the two pin thing?
<whitequark>
each PLL is connected to two global input buffers
<marcan>
right
<whitequark>
if you use a PLL, you have two options
<whitequark>
either it takes one input buffer with the PLL output
<whitequark>
or it takes two input buffers, with PLL output and PLL input
<whitequark>
hrm
<whitequark>
maybe it already kind of works?..
<whitequark>
this is so fucking confusing
<marcan>
wasn't it the other way around?
<marcan>
the PLL inserts itself between the pin and the gclk
<whitequark>
yes
<whitequark>
but you can use a dual output option for the PLL
<marcan>
yes
<marcan>
which eats both gclks
<whitequark>
oh, I remember now
<whitequark>
let me double check
<whitequark>
this is so badly documented
<whitequark>
marcan: ok, so, the most annoying case here is where we use both PLLs for something that isn't related to FX2 interface
<whitequark>
the PLL 2nd output is always the PLL source clock
<marcan>
yes
<marcan>
well
<marcan>
not always
<whitequark>
so we can't just bypass CLKREF pad through the PLL
<marcan>
that's one option
<whitequark>
oh?
<marcan>
let me find the damn docs again
<marcan>
yes this is terrible
<whitequark>
oh, there is the 2F_CORE primitive
<whitequark>
which outputs the generated clock twice
<whitequark>
or 2F_PAD
<whitequark>
ugh
<whitequark>
marcan: point being, it's not possible to get whatever is on CLKREF when the CLKREF PLL is used for multiplying something that isn't CLKREF, at all
<whitequark>
so we need CLKREF elsewhere
<marcan>
what about CLKIF?
<marcan>
for starters, which is which?
<marcan>
:p
<whitequark>
so if both PLLs are used, CLKIF as well as CLKREF can only be FPGA outputs
<marcan>
looks like CLKIF is on GBIN4 and CLKREF is on GBIN5
<whitequark>
this means that CLKREF will be tristated on the FPGA and unused
<marcan>
not "both PLLs", one of those stupid dial modes
<marcan>
*dual
<whitequark>
the dual modes output either source PLL clock or generated PLL clock
<marcan>
remind me again, in the current implementation which direction are CLKREF/CLKIF?
<whitequark>
CLKREF is always FX2->FPGA
<whitequark>
CLKIF could be FX2->FPGA (current firmware) or FPGA->FX2 (hypothetical dual PLL firmware)
<marcan>
so CLKREF is on GBIN5, and CLKIF is on GBIN4
<marcan>
which are the PLL pins main and alt (to pick some names)
<marcan>
so, on revC0, what you could do is configure that PLL to source from CLKREF, generate some clock based on it, and then either
<marcan>
1) keep CLKIF the way it is, and only use the PLL output in the gateware, CLKREF isn't available, or
<marcan>
2) flip around CLKIF, put the PLL into passthrough output mode, and that gives you CLKREF and the PLL output in the gateware, and then you can output whatever you want into CLKIF
<marcan>
that was the intent when we did revC0
<marcan>
with revC1, if we put CLKREF on another pin, then in case 1, we'd also get CLKREF (on a non-GBUF), or in case 2, we could get CLKREF and whatever the secondary output of the PLL is
<marcan>
does that make sense?
<whitequark>
yeah
<whitequark>
what I'm concerned about is an *applet* using two PLLs to generate something *not* derived from CLKREF or CLKIF at all
<marcan>
right, that's never going to work with C0
<marcan>
so the only way you free up both PLLs for *arbitrary* use is to do what we're talking about putting CLKREF on another pin, and also unconditionally flip CLKIF
<whitequark>
yep
<marcan>
and then we completely decouple that PLL site from the FX2 iface
<whitequark>
yep
<whitequark>
both PLL sites, even
<marcan>
of course
<whitequark>
i don't actually expect this to happen any time soon, even
<marcan>
well the other one never was
<marcan>
:p
<whitequark>
but i want to have the option
<whitequark>
it *would* be nice if the backup CLKREF pin was GBUF capable
<marcan>
I guess that makes three signal traces on the In2 layer, which, meh, I guess it's okay
<whitequark>
let me see
<marcan>
also, I noticed the FPGA was poorly grounded (there was a bottleneck in the plane), mostly just because the clearance settings on that one were too conservative, so I made it match the In2 plane and now it's better
<whitequark>
ack
<whitequark>
btw
<marcan>
(probably not a huge deal for vcc given all the local decoupling, but it might've affected I/O signal integrity)
<whitequark>
what is that squiggle on In2 around the OSHW logo
<_whitenotifier-1>
[Glasgow] electroniceel commented on issue #117: Pins for Addon-Boards - https://git.io/fjk7X
<_whitenotifier-1>
[Glasgow] electroniceel commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjk5v
<_whitenotifier-1>
[Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjk5u
<_whitenotifier-1>
[Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjk5d
<_whitenotifier-1>
[Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjkdR
<marcan>
whitequark: wait, why did you rule out all those shifters/isolators?
<marcan>
our problem with revC0 was the need for a shifter that had no VccA < VccB requirement and compatible voltage ranges, but here we're just isolating, not translating, right?
<marcan>
so almost anything should work?
<whitequark>
marcan: you'd think so, but the PCA9306 requires the B side to be at 5V to work with 3V3...
<whitequark>
according to their docs
<whitequark>
and most others are in a 3x3mm package
<whitequark>
which wouldn't physically fit
<marcan>
whitequark: I think you're too focused on i2c
<marcan>
e.g. SN74LVC2G66
<marcan>
anything with "i2c" in the name is either going to do horrible things by trying to be too smart, or be intended for level shifting, or some other nonsense
<marcan>
we just want a way to isolate the target side
<whitequark>
hmmm
<whitequark>
yes
<whitequark>
good point
<marcan>
I would put some weak-ish pull ups on the target side (e.g. 47K or something, whatever value we have lying around) just to keep that side from floating when disconnected
<marcan>
and rely on our existing FX2-side pulls when connected through
<whitequark>
that works!
<marcan>
now of course the other question is can I actually fit this in :p
<whitequark>
2.30x2.00?
<whitequark>
should work
<marcan>
not the switch, but the rest
<marcan>
I can make the header 5 pins, that would be what, AUXx2, I2Cx2, we still need power
<whitequark>
drop the aux pins?
<marcan>
kill aux entirely?
<whitequark>
in fact, if you can make it six pins
<whitequark>
maybe replicate I2C twice
<whitequark>
once per port
<marcan>
6 pins won't align
<marcan>
needs to be odd
<whitequark>
i don't think it needs to align
<marcan>
and I don't think it fits either
<whitequark>
how would you put a protoboard there anyway
<marcan>
on top?
<whitequark>
there are shrouds
<marcan>
so?
<whitequark>
oh, i see
<whitequark>
hrm
<whitequark>
enhhhhhh
<whitequark>
i don't know
<whitequark>
2x3?
<whitequark>
center gnd
<whitequark>
wait no
<whitequark>
oh, no, that *could* work
<whitequark>
but it wouldn't fit
<whitequark>
and
<whitequark>
two boards wouldn't mesh there anyway
<whitequark>
yeah no
<whitequark>
marcan: i think ditching AUX pins on the FPGA is fine then
<marcan>
I could go back to the 1.27 aux
<whitequark>
so the problem i was thinking about is making sure two addon boards can access these pins
<marcan>
or... connect aux and the target side of the switch together and you can have either (but not both) lol
<whitequark>
ew
<marcan>
that won't mesh unless I use a 2x connector, but that won't fit
<whitequark>
even if you use a 2x connector it wouldn't *really* mesh
<whitequark>
like you could mesh it in theory
<whitequark>
but you don't want to use that weirdly shaped PCB
<whitequark>
so
<whitequark>
there is something we could do.
<whitequark>
we could put I2C on the IO port connectors.
<marcan>
the gnds.
<whitequark>
19 and 20 are unused.
<marcan>
20 is gnd
<marcan>
well if we have a switch now we can afford that.
<whitequark>
oh, 20 is gnd
<marcan>
but if we're going to put i2c on the port connectors you kind of want 3V3 too
<marcan>
since that's referenced to that
<whitequark>
mhmmmm
<whitequark>
yeah it doesn't really work :S
<marcan>
we could also just... not do any of this and just come up with something clever for revD
<marcan>
I mean I totally get the feeling of wanting all this expandability stuff
<marcan>
but revC is too far down the road to do it *well*
<whitequark>
ok
<marcan>
and if we do it *shittily* then we're stuck with that way for revD
<whitequark>
hrm
<marcan>
the least horrible approach I can come up with is to just repurpose a bunch of GNDs of an IO port connector, and call the spare pin 5V or 3V3
<marcan>
(if 5V, expansion boards need an LDO, which isn't a huge deal)
<marcan>
(but it's more flexible that way)
<whitequark>
i know a better approach
<whitequark>
put a pin header to the north of the IO bank connector
<whitequark>
next to pins 1-7
<whitequark>
or 1-3-5 more like
<marcan>
for revD you mean?
<whitequark>
we can prototype that on revD and then make a revC2 with it
<marcan>
I was thinking a pin header next to the connector, yes, in some sane offset
<marcan>
could be side by side, or north, or whatever
<marcan>
but either way none of those options are going to work for revC1; we could put a connector next to pins 1-7 for *A* but *B* is mirrored so that won't work, it'd be 19-13
<whitequark>
oh
<whitequark>
yeah
<whitequark>
yeah let's not do any of this for revC1 then
<whitequark>
maybe uhhh
<whitequark>
let's NC the 20th pin?
<whitequark>
i actually thought it was NC
<marcan>
sure
<marcan>
that seems sane
<marcan>
whitequark: for revD, we could put I²C on those pins (sufficient for add-on boards that request 3V3 VIO), and 5V/3V3 on another connector (makes it harder to fuck up and short something out if those are not part of the main IO connector)
<marcan>
could be some other shrouded connector
<_whitenotifier-1>
[Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjkxz
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±3] https://git.io/fjkxg
<marcan>
whitequark: to extend an olive branch here, how do you feel about duplicating the I²C testpoints on the bottom, and maybe also 5V and 3V3?
<whitequark>
marcan: zero cost to us so sure
<marcan>
what I'm thinking is, if @electroniceel wants to prototype a whole-Glasgow analog expansion board for revC1, under the understanding that we have no way we approve of of making this approach official, they can still just fly-wire 3V3, 5V, and I²C to the four spare pins in the IO connectors (combined)
<marcan>
and that at least means you can easily have a pluggable board without having to hardwire things
<whitequark>
ahhh
<whitequark>
yep
<whitequark>
let's do that
<marcan>
would also allow alternate use cases, e.g. someone wants the AUX pins there instead or whatever
<whitequark>
yeah
<marcan>
obviously under the caveat of "we may redefine those to whatever we want on the next revision"
<whitequark>
that makes sense
<marcan>
but people can play around with that freedom for now
<marcan>
and the fact that it requires mods makes it clear it isn't official
<marcan>
I'll put these under SYNC, since we do have a wide open area there on the back
<marcan>
(and it's near the spared on the B side)
<marcan>
(and next to all the relevant signals)
<marcan>
also, this is generally useful for probing anyway, because it's more sparse on the back and easier to dump a multimeter on without shorting something out, plus the IO connectors make for a nice board support when inverted
<whitequark>
yes
<marcan>
like I wouldn't have minded this when testing the fail i2c thing
<whitequark>
ye
<marcan>
I'll comment on the issue
daveshah has joined #glasgow
<whitequark>
thanks
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjkps
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] whitequark abf2a94 - platform.rev_c0: add aux pins.
<marcan>
whitequark: tbh I like the idea of a "patch me in" port; if we can't just meet most reasonable goals with revD for expandability, I want to keep this idea of an NC or two just so that when I need something stupid I can at least implement it without having a horrible hanging connector.
<whitequark>
yep
<marcan>
like, if you're willing to take a soldering iron to the board, all bets are off but you know what you're doing so go nuts
<marcan>
(alt idea for a future version: run some of the GND pins through 0Ω resistors that can be removed)
<whitequark>
ehhhhh i do not like that very much
<marcan>
just an idea
<_whitenotifier-1>
[Glasgow] marcan commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjkpu
<marcan>
whitequark: I'll make the testpoints 3x2, <sda><scl><gnd> and <5V> space <3V3>
<marcan>
just to try to put clearance around the supply ones
<marcan>
(with space between the rows too)
<marcan>
or something like that anyway
<whitequark>
sweet
kc8apf has joined #glasgow
<whitequark>
tnt: so this is utterly bizarre.
<whitequark>
I added an explicit counter for IN FIFOs on the FPGA side.
<whitequark>
and absolutely nothing changed.
<whitequark>
the ONLY way i can get rid of the weird ass digital noise is by splitting SB_GB_IO back to SB_IO+SB_GB *and* removing the register on FX2 bus.
<whitequark>
why the hell???
<tnt>
whitequark: huh ... yeah I have no clue :/ is the noise more like lost data ? or corrupted data ?
<tnt>
also weird that it seems this one applet is the only affected.
<whitequark>
tnt: corrupted data
<whitequark>
specifically the very last byte in some packets is affected
<whitequark>
I can feed the applet nothing but zeroes or say pure blue
<whitequark>
and in the data that comes out, some reds will appear
<tnt>
maybe something with OE control ?
<whitequark>
reds because the corruption is always in the even byte, and reds are encoded in it
<whitequark>
tnt: doubt it
<whitequark>
i tried adding more wait states
<whitequark>
absolutely nothing changes
<whitequark>
it also appears to... depend on the phase of something???
<Hellsenberg>
logic analyzer time?
<whitequark>
oh hmm, i might have figured it out
<Hellsenberg>
nice
<whitequark>
probably not though
<whitequark>
how in the ever living fuck has this ever worked
<whitequark>
the clock output is not enabled
<Hellsenberg>
lmao
<whitequark>
oh nevermind
<whitequark>
wrong place
<whitequark>
tnt: marcan: wild idea
<whitequark>
what if instead of having an arbiter inside the FPGA...
<whitequark>
i would use GPIF and make the FPGA present four dumb FIFOs
<whitequark>
get rid of ALL of the glue logic
<whitequark>
tnt: out of curiosity i tried FPGA->FX2 path for CLKIF instead of the opposite
<whitequark>
no real change
<whitequark>
marcan: btw I am hitting the slow discharge of Vio capacitor all the time.
<whitequark>
it crashes the gameboy
<tnt>
whitequark: wrt to GPIF: sure that's an alternative. Not really what it would do for this specific issue given ... we have no idea what this issue is :/
<whitequark>
tnt: so it's some kind of race condition between end of packet and packet write...
<whitequark>
tnt: marcan: wild idea terminated
<whitequark>
GPIF can't use most of the control inputs and outputs
<whitequark>
I'd have to try *hard* to shoehorn it into the design
<whitequark>
and it looks like it needs a lot of firmware assistance?
<_whitenotifier-1>
[Glasgow] electroniceel commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjIJT