<whitequark>
but honestly it's probably not gonna work in software anyway
<whitequark>
i mean, i'm not even sure how'd you actually have two working in sync
<marcan>
well it'll probably work in practice, I think there's headroom in the Vil etc (but we can't guarantee it per iCE40 datasheet)
<marcan>
four or more would get really iffy
<whitequark>
yeah, that's fine for now, i guess
<marcan>
3 glasgows would try to pull 10mA, pins are specced to 8mA
<marcan>
so probably fine
<marcan>
(it'll just exceed the quoted 0.2V, but still below Vil)
<whitequark>
right
<marcan>
tbh, since we have the FPGA pins now, a better idea would be to have sync-in and sync-out
<marcan>
but what we don't have is the board space for that
<whitequark>
can't fit a transistor in there?
<marcan>
a small one, I think we can
<marcan>
something smaller than sot23 ideally
<whitequark>
hmm
<whitequark>
that would be more robust, yes
<marcan>
like the shifter package or something
<whitequark>
i mean we could just use the shifter.
<marcan>
true, lol.
<marcan>
also tbh I don't like the idea of strong resistors ganging up when several units are paralelled
<whitequark>
yeah, i agree
<whitequark>
another thing
<whitequark>
ESD protection
<marcan>
yeah, the shifter would give us that, right?
<whitequark>
yep
<whitequark>
as good as the other pins, which is good enough
<whitequark>
so we'd just have a sync-OE and sync-IO
<marcan>
ib4 1-bit port c
<marcan>
*inb4
<whitequark>
um
<whitequark>
there is actually a 1-bit port S
<marcan>
hah
<whitequark>
... because I needed 17 pins for something.
<marcan>
hahahahahaha
<marcan>
I bet you felt real good about that
<whitequark>
i think it's not in master because revC0 broke it
<whitequark>
but it used to exist exactly like that
<marcan>
sounds like the kind of thing you'd hate on someone for doing :D
<whitequark>
yes.
<marcan>
(especially without the shifter in there)
<whitequark>
i hate it.
<whitequark>
which is why i really like the idea of putting the shifter there.
<whitequark>
btw, semi-related "fun" fact
<marcan>
tbh, an extra port can be veeery useful sometimes
<whitequark>
i went to the electronics retailer and they... did not have anything i can plug into the LVDS port
<marcan>
like, 16-bit bus and a clock
<whitequark>
yeah
<marcan>
heh
<whitequark>
so with the gameboy, the S port will be used for audio in
<whitequark>
audio will be genlocked by using DCLK as ADC clock, and PS (probably) as CS
<marcan>
ha
<whitequark>
it's super sketchy but hey
<marcan>
ok, so dump a shifter in there?
<whitequark>
yep
<whitequark>
just like all of our other ones
<whitequark>
new299 wants me to see if i can bring up cameralink on ice40... will be fun
<whitequark>
so that's how i'm going to test the LVDS port
<whitequark>
cameralink addon
<marcan>
hah
<marcan>
er, slight problem with the shifter idea
<whitequark>
yea?
<whitequark>
we don't have 3V3 there?
<marcan>
unconfigured FPGA mode
<whitequark>
oh, hmm
<marcan>
it'll just drive hard then
<whitequark>
can't we put one pull-down there?
<marcan>
so that needs a DIR pulldown
<marcan>
yeah
<marcan>
will do that
<marcan>
might have to go on the back side
<marcan>
let me see how this fits
<whitequark>
so you know what i don't know
<whitequark>
how the hell are we gonna fit all the analog shit on revD
<whitequark>
without making the board wider
<marcan>
analog shit?
<whitequark>
shifters, pulls, adc, dac
<whitequark>
the only way i see is to make it a full double sided assembly
<whitequark>
and even then
<whitequark>
maybe that + a six layer board??
<whitequark>
it's not entirely out of question to just make it wider, but it feels like a shame
<marcan>
whitequark: okay, so routing out one of the unused FPGA pins for this was a royal pain in the ass and I had to move a bunch of traces, but I got it done
<marcan>
it did involve adding another signal trace on the 3V3 layer though
<marcan>
if this were a new design I would've reassigned some FPGA IO pins, but I really don't want to do that now
<marcan>
(alternately: I could steal one of the AUX pins, and that would make it trivial, but it feels wrong too for C1)
<marcan>
nothing interesting going on there though
<Hellsenberg>
hm
<Hellsenberg>
just a thicc copper plane for gnd i quess
<marcan>
basically the pins are in the middle of the IO bank, and I had to add a via to escape it, but that punched a hole on top of the 1V2 line going from the FPGA core island to the PLL filter on the inner layer, so I had to re-route that through the bottom side instead
<marcan>
and then getting that down from the bottom side to where it needs to go involved pushing a bunch of vias and traces to make space for another via in the middle of the IO mess
<marcan>
and then there's no way to pull that down on neither the top or bottom sides since those all have horizontal traces for the IO/DIR pins
<marcan>
so in the inner layer it goes, to the lower right corner of the FPGA which is where sync is (and the pullup previously, now the shifter)
<marcan>
and also routing the 1V2 down through the bottom stranded the 3V3 island that the right side IO bank runs off of
<marcan>
so I had to move the LVDS IO supply slightly to make space for that island to connect through the top
<Hellsenberg>
i got lost
<marcan>
yeah me too, this is why this took an hour to get one trace to where it needs to go
<marcan>
:p
<whitequark>
nod
<whitequark>
i'm a bit worried about the PLL
<marcan>
the trace being longer?
<whitequark>
well for one it being there at all
<whitequark>
wait
<marcan>
?
<marcan>
it doesn't matter, it goes to a resistor
<whitequark>
i mean #97
<marcan>
oh
<marcan>
unrelated to the current changes
<whitequark>
yeah, it just also involves ball assignment
<marcan>
and yeah if we need extra balls for the left side PLL thing that is going to be ~hell
<marcan>
at that point I'm getting rid of the AUX connector probably
<whitequark>
ack
<whitequark>
btw, we CAN reassign pins for C1
<Hellsenberg>
what is the AUX connector supposed to do?
<marcan>
it's just spare FPGA pins
<marcan>
and yeah, but I'd rather avoid it unless I *really* have to
<whitequark>
since the pin assignment decision is made by software we have complete freedom to reshuffle them between each rev
<whitequark>
it's awkward, true
<Hellsenberg>
oh, I mixed AUX with SYNC
<marcan>
also, right now, you can legitimately apply the ECNs to revC0 and rebrand it revC1 and it will be functionally equivalent
<marcan>
even the shifter will work without, for the use cases where the old resistor solution works
<marcan>
sync I mean
<_whitenotifier-1>
[Glasgow] whitequark commented on issue #115: ADC on every IO pin - https://git.io/fjkU0
<_whitenotifier-1>
[Glasgow] whitequark closed issue #115: ADC on every IO pin - https://git.io/fhj7M
<whitequark>
yeah, that's useful
<Hellsenberg>
wait wut
<whitequark>
it's definitely very clean
<marcan>
whitequark: oh btw, right now sync has no protection resistor in-line with the shifter (nor does the shifter have any protection resistor in-line with the FPGA), unlike the actual IO pins
<whitequark>
that seems appropriate if it's going to trigger a chain of ten glasgows or whatever
<marcan>
I can definitely fit the former in, the latter... is going to be harder
<marcan>
you mean with or without?
<whitequark>
without
<marcan>
ok
<whitequark>
i don't think it's worth spending a lot of time fitting the inline resistor to the FPGA
<whitequark>
that one is purely a safety feature against bad bitstreams.s..
<marcan>
yeah
<marcan>
also, er, 10K pull-down is too weak
<marcan>
I'll make it 1K
<marcan>
internal pull-ups are 10K or so it seems?
<whitequark>
yes
<whitequark>
kinda low
<whitequark>
not sure why
<marcan>
yeah
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±2] https://git.io/fjkUw
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan 7caa7bc - revC1: add level shifter to SYNC pin, using unused FPGA pin for DIR