<marcan>
whitequark: I just realized; should we add a (weak?) pull-up to sync?
<marcan>
(or pull-down)
<marcan>
just to prevent it floating all over the place if unused
_whitelogger has joined #glasgow
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
m4ssi has joined #glasgow
thaytan has quit [Ping timeout: 250 seconds]
Dark-Star has quit [Quit: No Ping reply in 180 seconds.]
Dark-Star has joined #glasgow
gsuberland has joined #glasgow
thaytan has joined #glasgow
<whitequark>
marcan: isn't the internal FPGA pullup sufficient?
<whitequark>
or wait, internal FPGA pullup would mean that the SYNC is driven
<whitequark>
marcan: so we have a pull-down on DIR already so that DIR isn't floating and then the FPGA-side pin is driven by the shifter
<whitequark>
and the other side of the shifter has a pull-up
<whitequark>
nothing is floating here, is it?
m4ssi has quit [Remote host closed the connection]
<marcan>
whitequark: the external side does not have a pull-anything, so when SYNC is an input (default state due to the DIR pull) and not connected externally, the shifter will see garbage and drive garbage into the FPGA
<whitequark>
marcan: wait, why don't we have a pull on the external side?
<whitequark>
did you remove it?
<marcan>
I think that got removed when we switched over to a shifter?
<marcan>
since the idea was that it's no longer an open drain thing
<whitequark>
but... if it's not open drain, how do you connect multiple devices/
<whitequark>
*?
<marcan>
well one would have to be the master
<marcan>
remember we talked about the problem of all the pulls paralleling together
<marcan>
and making it undriveable
<marcan>
and the idea was to just throw in the shifter and series resistor and call it safe enough to have one side drive hard
<marcan>
(nothing is likely to explode if there is a bus conflict)
<whitequark>
imo we should add back a weak pull on the external side, weak enough parallelizing many devices will be ok
<whitequark>
rationale
<whitequark>
if one device is driving hard, it's still fine
<whitequark>
but you also have the option of connecting an external OD sync source
<whitequark>
without having to wirewrap a resistor
<whitequark>
you could get a fucking relay to do it
<whitequark>
cc gruetzkopf
<whitequark>
or an optocouple
<gruetzkopf>
hmm
<gruetzkopf>
i rear relays AND wirewrap
<marcan>
yeah
<gruetzkopf>
both things i do
<gruetzkopf>
*hear
<marcan>
whitequark: I think it should be weak enough to be usable for low-speed sync stuff, and if you want hard edges, drive it hard.
<marcan>
pull up or down?
<marcan>
values we have lying around: 220k, 100k, 10k, 20k, 59k, 24k3
<marcan>
aksi 49k9
<marcan>
*also
<whitequark>
pull up definitely
<whitequark>
if we use 10k resistors we can parallelize how many devices? 10 of them?
<marcan>
24mA drive, so 137 ohms equiv
<marcan>
10 should be fine
<whitequark>
yep let's do that
<marcan>
whitequark: done
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±2] https://git.io/fjtze
<davidc__>
marcan / whitequark / edsen : fab suggestion; use an extra-thick PCB to decrease flexing from connector insertion/removal. Should help prevent capacitor / solder joing cracks
<davidc__>
Also, is there a mating connector for J5 (the LVDS connector) that will fit with the shrouded I/O header installed
<davidc__>
Also, are J8/J9 intended to be populated as shown in the renders? I'd be very nervous about the clearance between, say, J8 and the I/O header
<whitequark>
they are unpopulated, it is an option if you want different pull resistor values
<davidc__>
Ok. I've had shrouded headers come in oversize before, so I'd be careful about how close stuff is to them
<davidc__>
(as in U33/U35 are close enough to make me nervous, and J8 I wouldn't expect to fit)
<whitequark>
on the boards I have J8 will fit
<davidc__>
whitequark: with the exact I/O connector you have, yes. If you want to do a volume run using cheaper connectors (say, a reel from 4ucon), the header might be a bit bigger. Just mentioning it because this has bitten me before :)
<whitequark>
that's entirely fair
<whitequark>
and yeah, i've thought about it
<whitequark>
ultimately glasgow is not a board that can be made for dirt cheap with bargain bin components and that's fine
<whitequark>
if you want that you probably just want to bitbang an ft232
<whitequark>
or even ch431
<whitequark>
J5 does have a bit of "if it isn't a crash it's clearance" going on
<whitequark>
davidc__: the recommended mating part for J5 is Amphenol 20021321-00040T4LF
<whitequark>
which i should put somewhere on the schematic
<davidc__>
Fair enough (re: speccing an exact part). I did a partial design/layout review a few days ago, I'll recheck my notes tonight against the current layout
<davidc__>
hmm, that LVDS bank connector doesn't have alignment pins
<davidc__>
(the one on the current board)
* Hellsenberg
is only used to building stuff with parts in parts bin, which gets filled with stuff pulled from other boards
<whitequark>
alignment pins?
<davidc__>
whitequark: little plastic pegs under the center of the connector that keep the connector from floating around on the solder
<whitequark>
ohh, those
<whitequark>
yeah
<davidc__>
can lead to enough random position error to cause insertion problems, when the position needs to be fixed relative to the other headers
<whitequark>
no, the LVDS connector is supposed to only mate to a special LVDS daughterboard
<davidc__>
Ok, so there is no intention to have a daughterboard that connects to both the IO headers and the LVDS header at the same time?
<whitequark>
nope
<whitequark>
it really doesn't work height-wise
<davidc__>
Yeah, connector height was also on my to-check list :)
<whitequark>
the revC LVDS bank is a bit of an oddity, really
<whitequark>
i didn't intend it to be there at all, but marcan didn't like an entire unused FPGA bank
<whitequark>
so we did this
<whitequark>
it won't be on revD most likely, though maybe we can still fit it in the CB256 FPGA...
<marcan>
whitequark: oh yeah, I was going to ask about something
<marcan>
wait nevermind
<marcan>
I had a brain fart
<marcan>
ignore me
<davidc__>
whitequark: fair enough. In my experience, unused banks like that are ultra-useful to have around, but I can understand why one would want to remove it for simplification
<whitequark>
davidc__: we may keep it in revD if it's convenient enough
<davidc__>
Anyhow, I'll review tonight and see if I have meaningful input
<whitequark>
but it's not a hard promise
<marcan>
whitequark: I don't think we can leave that in revD
<marcan>
not enough pins
<marcan>
but at that point you have 32 "proper" pinsn to play with
m4ssi has joined #glasgow
<whitequark>
marcan: we'd have to go to CB256 in revD, no/
<whitequark>
because we don't have 64 more pins we can use for banks C and D
<Hellsenberg>
would using a FFC for that LVDS bank work?
<marcan>
whitequark: 32
<whitequark>
er, yes
<marcan>
and yes, we do
<whitequark>
we still don't have 32 iirc
<whitequark>
where?
<marcan>
I mean we have to go to CB256
<marcan>
but I don't know that that buys us enough new pins to keep the whole LVDS bank
<whitequark>
oh
<marcan>
I mean i didn't count, maybe it does
<marcan>
but my working assumption was it doesn't
<whitequark>
i think it does, but i'd need to recheck
<davidc__>
Also, whats up with that weird silkscreen line near pin-1
<davidc__>
is that a kicad thing?
<marcan>
davidc__: J6-J9 fit next to the IO headers, I just checked (I picked some female 1.27mm headers up on LCSC recently)
carter has quit [Read error: Connection reset by peer]
<marcan>
this is on revC0; I expect no issues with revC1 re: U35 etc
esden has quit [Read error: Connection reset by peer]
esden has joined #glasgow
carter has joined #glasgow
<marcan>
consider the headers end at the last pin position + 0.025"; the silkscreen is a good guide for the X dimension
<davidc__>
(in any case, if the convention is "long line" at pin1 mark, that convention is inverted for U35/U33)
<marcan>
basically the 3D render is ~accurate in that dimension, and there is plenty of room between the end of the header and U35/JU33
<marcan>
davidc__: I copied that from U34; "long line" seemed problematic with pinless packages like this
<marcan>
but I actually didn't find this clear in the conventions
<marcan>
either way someone will complain when the package is upstreamed if it's wrong
<davidc__>
marcan: re headers, my concern was J2->U35, and J2->J8 ; specifically, tolerance on J2
<marcan>
oh, J2
<marcan>
so empirically the ones we have fit inside the silkscreen
<davidc__>
re long lines: convention seems opposite on U29 vs U33
<marcan>
J2->J8 is tight on paper, but in practice J8 is narrower than what kicad shows there and the silkscreen model
<davidc__>
U29 "long line near pin 1"
<marcan>
see U34
<davidc__>
U33 "long line at opposite end of pin 1"
<marcan>
the convention as I understood it is "difference on pin 1"
<marcan>
so the lines are the width of the device
<marcan>
and pin 1 either has a longer line, or a shorter line
<marcan>
longer seems to be for pinned packages, shorter for no-lead packages?
<marcan>
that was my guess based on U34
<davidc__>
delightful. I hate whoever came up with that convention
<marcan>
yeah I dunno
<davidc__>
(soldermask alignment is usually poor enought that I keep it the hell away from pads...
<davidc__>
marcan: in any case, J2 tolerance is a non-issue. whitequark said that will be a specified BOM item rather than a generic
<marcan>
yes
<davidc__>
so if the manufacturer specs tolerance, and its reputable, then no big deal.
<marcan>
and really I don't think we're *that* tight; I mean if you have oversized connectors sure, but no reasonable tolerance will make it crash into the IC
<whitequark>
I was talking about the connector mating to J5, not J2 itself
<whitequark>
J2 is *already* a specific connector
<whitequark>
in our BOM, anyway
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjt23
<davidc__>
whitequark: to be completely clear on what I was trying to say: boxed/shrouded headers like J2 are the ones I've had tolerance issues with. I don't think its an issue for this design if you spec a particular part and prohibit subs at your fab.
<davidc__>
(i think we're in agreement, I just wanted to make sure I was being clear :) )
<whitequark>
ack
<whitequark>
the glasgow fab situation is a bit weird because i don't fab any of them
<davidc__>
Also, edsen: how do you prefer to do PCB testing? I know some fabs would prefer to have testpads on the bottom for every required testpoint
<davidc__>
so you can just drop it in a pogo jig and not worry about connector wear / stuff like that
<whitequark>
end to end testing of glasgow requires USB
<whitequark>
and a special adapter that loops back the I/O bank pins
<whitequark>
i'm not entirely sure how to best fit it here...
<davidc__>
depending on your fab, connector-to-board failures may not occur with any likelyhood. So sometimes you can do all that fixturing via testpads on the back of the board for each signal on the connector (including USB)
<davidc__>
USB HS will run over pogo pins to a testpad (and surprisingly well)
<whitequark>
can we please never use "high speed" again
<whitequark>
i've worked with usb for so long and i can never remember which fucking bitrate it is
<davidc__>
480 :)
<whitequark>
right
<whitequark>
yeah, two short stubs are probably okay
<whitequark>
i'm more concerned about the IO connectors
<davidc__>
Anyhow, these are all just options. Doesn't matter if your fab partner(s) don't plan to use that way of testing
<davidc__>
or if their connector solder failure rate is high enough to require testing
<whitequark>
we might want to add testpoints even if esden wouldn't use them
<davidc__>
(Re USB connectors, using the actual USB connector for testing can be problematic.... plug starts to wear out of tolerance at $N insertions... then starts bending the pins inside the USB housing on the board)
<davidc__>
(since the connector is broken, it makes fine contact, but ruins the connector for normal cables. Yes this has happened to me)
<whitequark>
oh dear
<davidc__>
Solution is generally to force replacement of the test cable every $N boards tested, but that can be difficult to enforce at the fab
<_whitenotifier-1>
[Glasgow] whitequark opened issue #121: MG2048 - https://git.io/fjt2d
<davidc__>
Pin headers are usually pretty robust, but the sockets can start getting flaky after a few hundred insertions as the spring fingers weaken
<whitequark>
the insertion and removal force is also super high
<whitequark>
this isn't a problem if the glasgow is in a case
<whitequark>
and you don't do that continuously
<davidc__>
usually for throughhole you can also pick-up the back of the pins with "cup" pogo pins
<davidc__>
so you can test electrical to the actual "pin" without requiring a cable insertion
<whitequark>
yeah I was wondering about that
<davidc__>
Also, when everything is probed from the back without cables, the human part of the test time gets super low which is better for accuracy and of course, cost
<sorear>
doesn't USB-A have a tolerance requirement of 100k insertion cycles? is C much worse?
<whitequark>
we use B-micro
<whitequark>
B-micro is rated for 10k
<whitequark>
but that's... optimistic
<davidc__>
sorear: that assumes that your fab is a) using an in spec cable, and b) hasn't stepped on the cable, and c) hasn't inserted that test cable into an out-of-spec socket with great force
<whitequark>
i sense multiple stories
<davidc__>
hah, a) and b) are hypotheticals; c) I'm pretty sure is what had happened
<_whitenotifier-1>
[Glasgow] whitequark opened issue #122: USB test points - https://git.io/fjtaf
<sorear>
oh, reading comprehension fail, I missed that this was about mfg-time testing