<sorear>
trying to understand the conceptual model of ports, level shifters, and pulls, as seen by an applet that wants to be compatible with whatever we're doing on the hardware side in 10+ years
<whitequark>
can you elaborate?
<sorear>
most applets have N pads, and do SDR (possibly tristate) I/O synchronous to a clock generated within the glasgow board (either by FX2 or a PLL), and the user can bind the pads to pins arbitrarily
<sorear>
selftest seems to be the only one that interacts with the adc/dac setup at `run`-time
<sorear>
the concept of SDR tristate IOs on interchangeable pads is very generic and likely to be a stable interface
<sorear>
the more analog-ish bits are more arbitrary and seem unlikely to have long-term support. a future board wouldn't necessarily have the same number of banks or the same value for pulls; it's not even entirely clear that the "bank" concept would carry over
<whitequark>
revD will be a bigger revC
<whitequark>
I think the concept of banks will stay
<sorear>
revC will have LVDS pins which are not interchangeable with the non-LVDS pins and I'm not sure how applets see this
<whitequark>
each pair will be abstracted as one "pin"
<whitequark>
so, what i need is some kind of constraint manager
<whitequark>
i can't use the one in migen for... reasons
<whitequark>
but i could use the one in nmigen, i think.
<whitequark>
quite frankly the analog bits are not well thought out and i'm going to need to rethink them.
<sorear>
cursed thought this morning: "an RTLIL-to-machine-code converter could be used to make the various existing projects look like slow glasgows with differently-shaped analog bits"; been wondering since then what the conceptual requirements on the analog bits are
<sorear>
(finally found one of the existing projects that I THOUGHT was discussed here but was actually on twitter, whoops)
<whitequark>
sorear: i don't think that'd work
<whitequark>
i mean
<whitequark>
unless you can make RTLIL-to-machine-code converter take the exact same amount of machine clock cycles each time and have it specified
<sorear>
oh right, because sys_clk_freq needs to have some value before _build is called?
<whitequark>
there's a whole lot of problems with that plan but well, yeah
<sorear>
second thought: sys_clk_freq is somewhat of a lie because of applet flow control
<whitequark>
not really
<whitequark>
you can opt into "full" throttle mode if you want
<whitequark>
but it's... not very useful
<whitequark>
i should probably scrap it entirely
<sorear>
why is it not very useful
<whitequark>
because if something wasn't designed with control enable in mind it tends to break if you disable control enable to it
<whitequark>
the only thing that does *not* break is a fully synchronous, fully edge triggered interface that does not use DDR anywhere
<sorear>
can fifo overruns happen currently?
<whitequark>
yep
<whitequark>
it's the applet's responsibility to handle them
<sorear>
are any of the "lot of problems" conceptually interesting
<whitequark>
not to me because i think the result will be a fundamentally inferior experience anyway
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjZs2
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark f015c4c - README: add "what can I do" section.
<sorear>
I should reread a certain conversation about xc2c devboards
<marcan>
anything else I should validate for revC1?
<marcan>
as I said I have the 1.5A switch, but at this point I don't think it's worth it
<whitequark>
marcan: I think we are done.
<marcan>
(aside: I just had a dream that I was JTAGing some huge Altera board with the glasgow without an external PSU and it was tripping the current limit, no shit sherlock. this is fine.)
<whitequark>
lol nice dream
<marcan>
the other thing I could *attempt* to do is validate the new regulators, but is that worth it?
<marcan>
would be a lot of horrible surgery
<whitequark>
mmm, probably not
<whitequark>
I don't foresee anything especially horrible here
<marcan>
yeah
<marcan>
I guess at least I should print the gerber and make sure the footprint isn't fail
<whitequark>
yep
<marcan>
I guess as soon as esden adds his BOM keys we can tag revC1
<sorear>
found it
<sorear>
(2018-11-01 starting 08:50 UTC ish)
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan pushed 2 commits to master [+0/-0/±2] https://git.io/fjZsx
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan 50b6be7 - revC1: nudge some traces
<whitequark>
J6-J9 should maybe be DNP on the pic?
<whitequark>
and in the schematic too
<marcan>
ah, possibly yeah
<whitequark>
and J10
<whitequark>
D12/D13 are DNP as well
<marcan>
and a few resistors are "DNP" too
<marcan>
like the REC thing and some of the rear ones
<marcan>
I guess for those we just remove the 3D model?
<whitequark>
yes
<whitequark>
and yes
<_whitenotifier-3>
[Glasgow] whitequark opened issue #136: Mark DNP parts on schematic as DNP and remove 3D models - https://git.io/fjZGn
<_whitenotifier-3>
[Glasgow] whitequark assigned issue #136: Mark DNP parts on schematic as DNP and remove 3D models - https://git.io/fjZGn
<marcan>
how do we mark things as DNP anyway? until now I've been replacing the value with DNP but that loses information
<whitequark>
uhh, good question
<marcan>
like for the DNP resistors it makes sense because we literally have no value
<marcan>
but the connectors have a specified part, it's just DNP by default
<marcan>
same with the ESD diodes etc
<whitequark>
esden: any idea?
<esden>
I personally have a DNP custom field in the schematic symbols. Set to either nothing or DNP. I know this is strange but putting NO everywhere and YES to DNP parts sounds like negative logic and is a lot of work.
<whitequark>
that's OK with me.
<whitequark>
it's not really strange.
<esden>
Heh, all right so the rule is: custom field named "DNP", with no value for "Populate" or "DNP" value for "Do Not Populate".
<_whitenotifier-3>
[Glasgow] whitequark commented on issue #136: Mark DNP parts on schematic as DNP and remove 3D models - https://git.io/fjZGc
<marcan>
esden: is it okay ti just not have that field present for "populate" parts?
<marcan>
seems like a major PITA to add it everywhere
<marcan>
(as empty)
<esden>
I usually just prefix the model paths with X or something so KiCad does not find them and it is then easy to get them back.
<marcan>
you can remove the models
<whitequark>
marcan: iirc kicad will add an empty field everywhere
<whitequark>
once you add it in the configuration
<marcan>
ah really, ok
<whitequark>
I'd prefix model paths with DNP as well.
<esden>
yes it does, if you add a custom field to one symbol it adds an empty field everywhere else. Same thing if you have custom fields in your environment config. Until you set that value in one symbol it will not be exported into the BOM.
<esden>
If you do it adds that column to the BOM.
<esden>
so are you done with the board? Can I add the keys now? (I do not want to create a merge nightmare) :D
<esden>
I wish git had a semaphore mechanism sometimes. :)
<whitequark>
I am done with it, marcan might not be
<marcan>
just doing the DNPs
<marcan>
looks like those fields don't translate to the board so they don't show up in the fab layer, meh
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±4] https://git.io/fjZGR
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan 12b81a9 - revC1: remove DNP part models & add DNP field in sch
<marcan>
esden: you can take the kicad lock
<marcan>
(though tbh adding keys is unlikely to create a merge nightmare :-) )
<esden>
marcan: let's hope so :)
<whitequark>
kicad likes to randomly reorder shit
<esden>
I am doing it now :)
<whitequark>
which is very annoying, i hope they fix that
<marcan>
for me it's usually pretty consistent when it comes to just changing attributes
<marcan>
but *sometimes* it randomly reorders stuff for no reason, usually just one or two things in the schematic
<marcan>
boards are messier
<marcan>
esden: note that I made up a key for the 0.68 ohm resistors, but you might need to adjust it
<marcan>
not sure how you want to write down <1ohm resistances like that :-)
<esden>
I talked to the devs last weekend about it. they are aware of it. :/
<marcan>
sorear: J6-J9 are optional, for custom pull resistor values if someone wants to reduce (or even remove and replace) the default 10K networks
<marcan>
esden: jfyi, I think we specifically want polymer vs regular electrolytic for the cap, for ESR reasons
<marcan>
(since that isn't covered in the bom key, right?)
<esden>
ohh I think you should set the thermal pad via of the FX2 to have the Pad connection set to "solid" so that it does not make thermal connections to the inner GND layer, but rather be connected solid.
<whitequark>
ugh, we missed that at least twice already
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjZGS
<marcan>
whitequark: btw, even if shorting both IO banks and cooling down the regulators, it does not brown out the board with the 0.5A (0.8A) current limit, so I think we're doing pretty fine there
<marcan>
seems just about right with each bank being able to source 350mA-400mA or so
<whitequark>
ack
<marcan>
I assume the 5V rail is sagging at this point, but not enough to trip the brownout
<sorear>
naive question, what does it mean (above) to have a "solid" inter-layer connection? I'm assuming you're restricted by the process to a finite number of vias of fixed size (and that there's no material difference between a thermal via and an electrical via, copper conducts both well)
<whitequark>
it was about the connection of the via to the inner layer
<whitequark>
there's no such thing as a solid inter-layer connection
<marcan>
sorear: "thermal" in this context means a spoke pattern around the via
<whitequark>
well, not in any PCB process I know of
<marcan>
which is actually never used for real vias, only for through-hole pads
<marcan>
(for solderability)
<marcan>
but kicad has this quirk where thermal vias integral to footprints are actually through-hole pads
<sorear>
hmm, is the "GND plane" not literally a rectangle the size of the pcb??
<marcan>
and those need to be set to disable the "thermals" (which are the spokes)
<sorear>
s/??/?/
<marcan>
yes, but that doesn't mean it enroaches in everything within it
<marcan>
all of these planes will avoid obstacles
<marcan>
that includes respecting the thermal setting of pads
<marcan>
the planes aren't just graphic rectangles, they're fills
<marcan>
which work like "flood fill" in an image editor, plus respecting a clearance around anything they touch
<marcan>
note the confusion between "thermals" (a clearance and spoke pattern intended to *reduce* heat conduction for through-hole solderability) and "thermal vias" (the opposite, vias intended to conduct heat and thus intended to connect directly to a plane)
<marcan>
we had thermals on thermal vias, which is stupid
<marcan>
due to that kicad technicality
<marcan>
thermals are there so that when you solder the GND pin on a connector the GND plane doesn't just suck away all the heat
<marcan>
anyway, I'm really off now :p
<sorear>
thanks
oeuf has quit [Ping timeout: 258 seconds]
mehar_ has joined #glasgow
mehar has quit [Ping timeout: 246 seconds]
mehar_ is now known as mehar
<_whitenotifier-3>
[Glasgow] whitequark commented on issue #136: Mark DNP parts on schematic as DNP and remove 3D models - https://git.io/fjZcD
<_whitenotifier-3>
[Glasgow] whitequark closed issue #136: Mark DNP parts on schematic as DNP and remove 3D models - https://git.io/fjZGn
Jasjar has joined #glasgow
oeuf has joined #glasgow
_whitelogger has joined #glasgow
<electronic_eel>
change R45 (between fpga and sync-shifter) to 47
<electronic_eel>
or change R38, R39, R43 to 33 ohms
<electronic_eel>
would reduce the different part (=reel) count by one
<electronic_eel>
another one:
<electronic_eel>
change R3 (usb shield decoupling) to 100K
<whitequark>
hm
<whitequark>
yes reasonable
<electronic_eel>
don't know if it saves much, but at least this won't hurt and we tried to optimize without compromising features
<whitequark>
it will definitely make esden happy.
<whitequark>
can you prepare a PR?
<electronic_eel>
no problem
<_whitenotifier-3>
[Glasgow] electroniceel opened issue #137: Reduce resistor part count - https://git.io/fjZlj
<_whitenotifier-3>
[Glasgow] whitequark commented on issue #137: Reduce resistor part count - https://git.io/fjZ8J
<_whitenotifier-3>
[Glasgow] electroniceel commented on issue #137: Reduce resistor part count - https://git.io/fjZ8t
<_whitenotifier-3>
[Glasgow] whitequark commented on issue #137: Reduce resistor part count - https://git.io/fjZ8Y
<_whitenotifier-3>
[Glasgow] whitequark commented on issue #137: Reduce resistor part count - https://git.io/fjZ8O
<_whitenotifier-3>
[Glasgow] electroniceel commented on issue #137: Reduce resistor part count - https://git.io/fjZ83
<_whitenotifier-3>
[Glasgow] whitequark commented on issue #137: Reduce resistor part count - https://git.io/fjZ8s
<_whitenotifier-3>
[Glasgow] electroniceel commented on issue #137: Reduce resistor part count - https://git.io/fjZ8G
<electronic_eel>
whitequark: I know you like that part, want to play with it, and I can fully understand
<electronic_eel>
but the ATECC crypto ic could be DNPed too
<whitequark>
it coul
<whitequark>
*could
<electronic_eel>
If Glasgow were a commercial product and there'd be the risk of clones like for Saleae
<electronic_eel>
then something like this would be essential
<electronic_eel>
but with 0BSD there is no such danger
<electronic_eel>
and I think esden can handle warranty stuff just fine without
<whitequark>
well no, it's the opposite
<electronic_eel>
he at least didn't include something like this to his other products
<whitequark>
it's not there for the benefit of the vendor so much as for the benefit of the user
<whitequark>
but maybe people aren't that interested in it
<electronic_eel>
you mean tamper protection?
<whitequark>
nope
<whitequark>
it answers only the question "where did this come from", really
<electronic_eel>
hmm
<electronic_eel>
if I pay directly to esden and get something shipped that matches my order, then I don't have second thoughts
<electronic_eel>
at least not with some non-security-sensitive device like this
<electronic_eel>
so it would only matter with a lot of resellers and 2nd hand market
<whitequark>
it depends on how many people will grab random PCB revisions and populate it with substandard components
<electronic_eel>
does any of the ics, like fx2, ice40 or the eeproms, have an internal serial no?
<whitequark>
nope
<electronic_eel>
damn, i'm used to that from the stm32s
<whitequark>
ice40 could be used as a PUF but that requires a serious amount of research
<electronic_eel>
yeah, and then it fails with different temperature, moisture or unclean power supply
<electronic_eel>
that is not worth it
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<_whitenotifier-3>
[Glasgow] smunaut opened pull request #138: protocol.sfdp: unpack requires the exact right size - https://git.io/fjZ4e
<_whitenotifier-3>
[Glasgow] whitequark commented on pull request #138: protocol.sfdp: unpack requires the exact right size - https://git.io/fjZ4J
<electronic_eel>
whitequark: about the ATECC - wouldn't adding a fancy sticker be enough for the first batch? If we publish a good photo of the backside of a genuine Glasgow from Esden with the sticker, then someone wanting to fake one has to find where to buy exactly these stickers, how to print them correctly and so on. Don't think there is much of a market for that. The cheap components must also look like what is on
<electronic_eel>
esdens boards, since we publish a good photo of the front side too.
<whitequark>
well if we bail on it for the first batch we might as well give up on it entirely
<electronic_eel>
do you think people will still buy new revC1 if revD or E are out?
<whitequark>
yeah
<whitequark>
revE will be far more expensive, and revD might not even have LVDS
<whitequark>
(also more expensive)
<whitequark>
revE in particular does not obsolete revCD
<electronic_eel>
will it work out financially for esden to stock & build like 3 different variants in parallel?
<electronic_eel>
and if we add galvanic isolation in the mix like 5
<whitequark>
i'm not sure if galvanically isolated version should be mass produced
<electronic_eel>
will reduce batch size significantly
<whitequark>
it's very niche indeed
<whitequark>
as for e.g. stocking revCD at the same time, we can make them share most components
<electronic_eel>
then I'd think an addon board instead would make more sense. but that something to discuss at another time
<whitequark>
galvanic isolation will be *incredibly* expensive
<whitequark>
tons of board space, lots of very very pricey ADuM chips...
<electronic_eel>
no adums needed. ti iso7740 would be enough
<electronic_eel>
but board space, yes
<whitequark>
no, that's 4/0...
<electronic_eel>
4/0?
<whitequark>
direction
<electronic_eel>
6 of them for one port
<electronic_eel>
in, out, direction
<electronic_eel>
for 8 channels
<whitequark>
doesn't work well
<whitequark>
you want creepage an antitracking slots
<electronic_eel>
I said it'll take board space...
<whitequark>
no, you can't really mix in,out,dir
<whitequark>
you need a 2/1 isolator
<whitequark>
or maybe you only want 1 isolation barrier per port, not per pin
<whitequark>
then it's easy
<electronic_eel>
there'd be the '1t45 shifters as we have now on the DUT side of course
<whitequark>
yes
<electronic_eel>
ah, you mean every pin isolated against every other?
<whitequark>
yes
<electronic_eel>
don't know if that is practical
<whitequark>
if you don't want every pin isolated, use a serdes
<whitequark>
one of the cheap lvds things
<whitequark>
capacitively couple it
<whitequark>
one
<whitequark>
*done
<whitequark>
well a pair
<tnt>
What's revD planned ?
<electronic_eel>
are there serdes isolation ics rated for high voltages (e.g. 5kv like the iso7740)
<electronic_eel>
?
<electronic_eel>
and converters to connect the shifters to?
<electronic_eel>
I haven't used serdes before
<whitequark>
you don't need one
<whitequark>
you just use a 5 kV capacitor
<whitequark>
since that's how the iso7740 works internally
<electronic_eel>
and then? how do i connect the shifters?
<daveshah>
Have to make sure it's a small enough value capacitor that it doesn't pass significant AC
<daveshah>
And then make sure your line coding is good enough that it survives the capacitor
<whitequark>
electronic_eel: the same way as with many ADuMs
<whitequark>
daveshah: ah yes, lvds video is not dc balanced, annoying
<whitequark>
tnt: no ETA
<electronic_eel>
daveshah: good points, there is no line coding when you want to emulate arbitrary protocols
<daveshah>
The line coding would be between the FPGA and the SerDes
<daveshah>
Maybe you could exploit TMDS devices
<tnt>
whitequark: sorry, bad sentece, I meant what is it vs revC. I know revE is ecp5 wiht lots more IOs.
<marcan>
just 2xrevC
<whitequark>
tnt: ohhhh, what not when
<whitequark>
yeah what marcan said
<marcan>
4 banks
<tnt>
ok.
<electronic_eel>
and hopefully a proper interface for addon boards
<tnt>
Is there really no multibit equivalent to the 1T45 btw ? (i.e. single chip with multiple lanes but still independent direction control)
<whitequark>
nope.
<whitequark>
absolutely anywhere.
<whitequark>
not even with inferior characteristics
<marcan>
whitequark: fwiw, this thing has been shorted out for all afternoon (accidentally lol) and it survived fine
<marcan>
regulators still regulate
<whitequark>
sweet
<whitequark>
electronic_eel: daveshah: yeah TMDS would work
<marcan>
whitequark: btw, I just did a short circuit current test on the MIC, it limits at about 800mA
<marcan>
on both rails independently
<marcan>
but then again the upstream 5V is also limited around there
<marcan>
so I dunno exactly what's hitting first
<whitequark>
ack
<esden>
Ohh I just see another thing that could be done to make solder stencil release better and the fillet pattern cleaner in reflow. Make all the square pads roundrect. Especially on the bigger parts. Thermal pads can and probably should be left square as they are no fillets. I usually do that change on my boards.
<esden>
well not especially on the bigger parts but on all parts that still have square pads. The only part I am not 100% sure if it would work or not are the esd protection diode arrays.
<esden>
I can make that change locally before I generate the gerber files too. You don't have to have it upstream. I know that you like using the upstream footprints and they don't have roundrect pads except for the passives.
cr1901_modern1 has joined #glasgow
cr1901_modern2 has joined #glasgow
cr1901_modern has quit [Ping timeout: 245 seconds]
cr1901_modern1 has quit [Ping timeout: 244 seconds]
<marcan>
esden: yeah, makes sense to do it locally, otherwise we'd have to customize all the footprints locally
<marcan>
I think that detail is a "manufacturing tweak", and probably process-dependent, so it probably makes sense to do it as a postproduction step
<marcan>
probably with a python script or something before generating gerbers
<esden>
Yeah I guess... :/ This is not the most convenient answer for me. ;)
<esden>
and especially for those that manually assemble the boards this change will be useful I think. But ok I will just do that on my end then. :)
<_whitenotifier-3>
[Glasgow] marcan commented on issue #49: Implement MPSSE subtarget and FTDI emulation mode - https://git.io/fjZ6O
<marcan>
maybe we should just have an official postprocessing script that just "fixes shit"
<marcan>
like makes everything DNP not have 3D packages, makes all those pads non-soldermask, goes through everything and rounds all the corners...
<marcan>
if it's scripted I don't mind having it
<marcan>
I just don't want to be *manually* editing all the pads on all footprints every time we update, nor do I want to actually fork all those footprints
<esden>
yeah I wanted to steal obra gerber generation script and start adding stuff like that.
<esden>
his talk is not released yet but he made a lot of kicad automation stuff for his keyboard creation.
<esden>
yeah manually is always problematic I agree, automatic needs to handle center thermal pad exceptions though, so it needs to have a bit of logic still.
<esden>
but I think it is doable
<marcan>
should be dosable
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjZ64
<marcan>
*doable
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan b783967 - revC1: nudge two vias around the ESD diode arrays