<d1b2>
<xabean> I now want to know what unit of measurement "ppb" is, heh
<cyborg_ar>
parts per billion
Stormwind_mobile has quit [Remote host closed the connection]
Stormwind_mobile has joined #glasgow
aquijoule_ has joined #glasgow
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #glasgow
<cyborg_ar>
hm looking around, did anyone make a frequency/event counter applet?
<whitequark>
attie was making one, the PR is currently a draft
<whitequark>
i'd be happy to review it if he finished it!
<whitequark>
the thing i insisted on reworking is to make the frequency counter use a ripple counter instead of a traditional synchronous one with carries, which greatly increases its upper frequency limit
<cyborg_ar>
yeah that would be the interesting thing for a dedicated frequency counter applet
<cyborg_ar>
gettting as close as possible to the upper frequency limit of the fpga
<whitequark>
you'll bump into level shifters first, i suspect
<whitequark>
definitely at lower voltages
<whitequark>
and if you find something at 5V that toggles at 200MHz i will be impressed
<cyborg_ar>
yeah, i guess that would be a fun thing to do once the boards are made, characterizing the IO
<cyborg_ar>
do you know what drive strength they are supposed to have at 5 volts?
<cyborg_ar>
and is there any sort of slew rate control?
<eddyb>
frequency counters you say? ( stares at the weird REFCLK)
<cyborg_ar>
well not as interested on absolute frequency measurement
<cyborg_ar>
you could concievably feed a reference clock on some io, or use it for counting events
<whitequark>
which boards are made?
<cyborg_ar>
the crowdsupply glasgows
<whitequark>
we've been making very similar boards for more than a year
<whitequark>
just not in large batches
DarthCloud has quit [Ping timeout: 240 seconds]
DarthCloud has joined #glasgow
futarisIRCcloud has joined #glasgow
<cyborg_ar>
ah just looked up the schematics, the drive strength is 32mA
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 256 seconds]
PyroPeter_ is now known as PyroPeter
egg|laptop|egg has quit [Read error: Connection reset by peer]
egg|laptop|egg_ has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<d1b2>
<J> I'm in awe that it's up to 600% so quickly. :D
<marcan>
whitequark: so apparently apple's debug interface stuff just bitbangs PD with a STM32 anyway
<marcan>
their debug cables I mean
<whitequark>
marcan: yep, sounds like PD
<marcan>
?
<marcan>
you said bitbanging it was a bad idea due to the levels, but I guess they get away with it :p
<whitequark>
if you don't need to interact with chargers that don't implement BMC, you don't care about the TX waveform
<whitequark>
and none of the two devices involved is a dumb charger
<marcan>
oh you mean like a dumb charger AND cable PD
<marcan>
on the same wire
<whitequark>
like you only need to match the 12 point TX eye if the other side has a filter that needs to output a given DC offset
<whitequark>
because that's what the TX eye is *for
<marcan>
riiiight
<whitequark>
some uh engineer from TI has designed both the PD part and the TI PHYs that are compliant with it
<whitequark>
i do not think highly of this scheme
<whitequark>
it kinda shows that it's too complex if you need the same guy to write both the standard AND the circuitry that implements the standard
<electronic_eel>
marcan: you are sure they don't use a STM32 variant with integrated PD PHY?
<marcan>
that's a thing? I'm not
<whitequark>
oh nice, those exist now?
<marcan>
this is just third hand info
<electronic_eel>
the newer STM32G series have PD PHYs
<marcan>
huuuuh
<marcan>
well that sounds perfect for *my* implementation
<marcan>
usb dev/host and pd
<whitequark>
i foresee frustration with STM IP in your future
<electronic_eel>
just look out for the exact order numbers. the smaller packages have two variants, one has necessary pins bonded out, the other one not
<electronic_eel>
whitequark: foresee ... you are the digital logic witch here ;)
<marcan>
I can't find the G0 with UCPD
<marcan>
did this get covidelayed?
<marcan>
the G4s have it
<whitequark>
electronic_eel: mmm?
<whitequark>
if not for the analog madness i would probably implement PD in gateware at some point
<whitequark>
but i am kinda lost when it comes to that absurd TX eye
<marcan>
ah STM32G071RB
<marcan>
I think their product selector site is just broken
<whitequark>
i think the TI controllers basically have a DAC for it with some OTP calibration
<electronic_eel>
marcan: the currently released G0 have just the PD, not a regular usb device hw. i think they have some planned that have, but they are delayed
<marcan>
wait no their pagintion is just shit
<whitequark>
which is a suitably larger hammer, i guess
<whitequark>
from talking to someone who reversed it, i think tps65982 stores the calibration envelope into the PHY at the start or something along those lines
<whitequark>
and then switches between the points
<whitequark>
kinda like how PCIe preemphasis works
<electronic_eel>
so like a dac?
<whitequark>
DAC and some of the FSM that drives it integrated into the silicon
<whitequark>
and a buffer I guess
<whitequark>
I wish they made discrete ICs like that and actually I vaguely recall someone finding just such an IC
<marcan>
electronic_eel: yeah I guess I need G4 for USB right now
<whitequark>
I think it terminated all of the protocol up to GoodCRC handling which is fine I guess
<whitequark>
idk, it feels like picking between similarly unpleasant options
<marcan>
whitequark: that's what FUSB302 does
<marcan>
it'll do GoodCRD for you (if you want)
<marcan>
and the TX side is basically you can do raw tokens, or ask it to 4b5b convert things for you
<whitequark>
ah that was probably what i looked at
<marcan>
it's what I'm using
<whitequark>
ok, revE will use FUSB302 then :)
<marcan>
:)
<whitequark>
a *lot* better than bitbanging PD on the FX3
<marcan>
RX side does not give you raw tokens but it does tell you what SOP type it received
<whitequark>
which is what i expected i would have to do
<marcan>
I don't think you can turn *off* SOP so if you want auto-goodcrc you can't implement, like, a cable plug
<whitequark>
for the most part, i don't want raw tokens, i want to be able to fix shit when it breaks
<marcan>
but if you turn that off it should work
<whitequark>
and it seems to implement little enough of PD stack that it can't critically break stuff
<marcan>
the goodcrc default register values violate the spec; the spec says rev is ignored but SHOULD be 00, and it isn't by default :p
<electronic_eel>
marcan: you just want basic uart over usb right? i'd say a STM32F042 and a FUSB302 should be cheaper than a STM32G4
<marcan>
but you can change it
<marcan>
electronic_eel: yeah
<marcan>
I'll probably throw in a USB hub too
<marcan>
so I can map out the M1 USB device mode
<marcan>
well, uart + stuff but I assume it's not hideously limited?
<marcan>
4 endpoints would be nice
<marcan>
two UARTs, one passthrough, one for internal config
<marcan>
I can live with doing the latter over control transfers though
<electronic_eel>
hmm, the memory can get quite tight on the F0s with usb
<marcan>
also do those do DFU?
egg|laptop|egg has joined #glasgow
<electronic_eel>
they have DFU
<marcan>
good
<marcan>
looks like it does up to 8 endpoints, that should be fine
<electronic_eel>
the main obstacle i had with these were the 6 kb of sram. make sure that is enough for you, otherwise use the G4
<marcan>
1K USB buffer, right?
<marcan>
I mean that should be enough for a UART and a commandline
<electronic_eel>
the usb peripheral has 1 kb of integrated buffer. it is shared with can, but you aren't gonna use that
<marcan>
yeah
<marcan>
whitequark: https://github.com/AsahiLinux/vdmtool read the code for that for an overview of what's actually required. I stripped out the humongous blob of USB-PD garbage that the original tool had.
<marcan>
that just does the bare minimum to negotiate with a dumb host and send VDMs
egg|laptop|egg has quit [Remote host closed the connection]
<whitequark>
"humongous blob of USB-PD garbage" ahhh, how accurate
<whitequark>
yep very nice
<whitequark>
for now i'll avoid being dragged into PD on that level, there are more important things i need to do wrt glasgow
<whitequark>
but it will come in handy
<marcan>
yeah
<whitequark>
so i was just thinking
<whitequark>
once Attie finishes the ripple counter, i could probably use it to measure PCIe REFCLK
<whitequark>
since that's "only" 100 MHz
<whitequark>
oh wait, i couldn't
<whitequark>
that's HCSL, it is not compatible voltage swing wise
<electronic_eel>
could you adapt the lvds inputs?
<whitequark>
possibly
<whitequark>
0 to 0.75V swing
<whitequark>
wow, an actual use for the LVDS bank, that's a... second
<whitequark>
the first one was the SMIA applet, which i couldn't finish because, well, no LVDS inputs and also some issues with async applets
<whitequark>
i actually did get to data acquisition i believe
<whitequark>
implemented the absolutely humongous i2c control register bank
<sorear>
how many passives would you need to connect it to the normal inputs?
<whitequark>
you'll need actives.
<electronic_eel>
a fast comparator i'd say
<whitequark>
could probably use uh... one comparator?
<marcan>
whitequark: btw, I don't know how you do bus-powered devices with the FUSB302, but I guess you'd just hardwire the pulldown resistors on CCx (and disable the internal ones) and just run the whole thing off of VBUS?
<marcan>
the datasheet is mum on that, I don't think there is any kind of useful bootstrap implemented since you need to turn on the resistors for VBUS to appear
<marcan>
and you don't get VCONN for a non-cable implementation
<marcan>
yeah I think that's the only way pretty much
<whitequark>
the PD trigger cable i have uses a FUSB302 clone
<whitequark>
and i think it does that
<marcan>
if you have external power you can use it as a full featured DRP etc; if you're bus powered then you're going to need external resistors to bootstrap VBUS ON
Lofty has quit [Quit: Love you all~]
ZirconiumX has joined #glasgow
<d1b2>
<Attie> sounds like I should finish up the freq counter!
<d1b2>
<Attie> but yeah, it won't work for PCIe
Maxxed has quit [Ping timeout: 240 seconds]
Maxxed has joined #glasgow
uberushaximus has quit [Ping timeout: 240 seconds]
<d1b2>
<you_snus_you_lose> instead of a comparator you can just use one transistor to amplify the refclk signal to cmos levels
<d1b2>
<you_snus_you_lose> comparators that work well to 100MHz are rare
<d1b2>
<you_snus_you_lose> 2sc3356 should do the job
<whitequark>
hm
<whitequark>
yeah the only one i can find i can easily buy is ad8611
<sorear>
dumb question: what would happen if you connected a transformer to an IO
<whitequark>
it would... transform? :p
<eddyb>
wow, so among the stuff I got is a slightly better multimeter, and with this one I can see something very weird on the lanes' DC offset (on the half-dead X99): the chipset x4 slot has -0.1V, another slot has 0.15V and yet another has 0.25V. the others don't seem to have any, but it's possible I probed wrong
<sorear>
the datasheet capacitance is 6 pF, so 1500 ohm at 100 MHz, a 1:5 transformer or so would match that to a 75 ohm input
<whitequark>
yep
<whitequark>
you could do it i think
<eddyb>
I guess I should measure the working board too lol
<eddyb>
but at least this one seems to have noise on the level of 5mV not 100mV, so there's that
<sorear>
but that doesn't just match the impedence, it also increases the voltage swing 5x ???
<eddyb>
hmm, given how little current you need to pass through it, just how tiny could that transformer be?
<eddyb>
and do they make arrays of them in a single package :P
<d1b2>
<you_snus_you_lose> and 75 ohms of reactance is not the same thing as 75 ohms of resistance
<d1b2>
<you_snus_you_lose> you are better off treating it as an "open circuit" and add a shunt 75 ohm resistor if you really need to make it look like 75 ohms
<sorear>
fair
<d1b2>
<you_snus_you_lose> depends on your objective of course
<d1b2>
<you_snus_you_lose> if you want to make the pin as sensitive as possible, you'd tune out the capacitance and then design an impedance match that goes from 75 ohms to a very high impedance
<d1b2>
<you_snus_you_lose> like transform 75 to 1000 ohms
<eddyb>
okay so it's a bit above 0.3V on a working board
<d1b2>
<you_snus_you_lose> is it not ac coupled?
<sorear>
i'm just wondering if there's a way to do the refclk thing on a normal glasgow input. energetically I think it should be possible
<eddyb>
I'm not super sure I understand what the hell is going on in that other one lol
<sorear>
the voltage swing is too low for the input margin, and the impedence is also completely wrong, but those can be played against each other
<d1b2>
<you_snus_you_lose> what's the goal here, to get a pci-e refclk into a cmos input?
<d1b2>
<you_snus_you_lose> that's easy
<d1b2>
<you_snus_you_lose> buffer it with a 2sc3356
<eddyb>
I wish I had a glass table or some kind of rig to look at the board from undearneath without taking off the CPU and the massive cooler :P
<eddyb>
I wonder if there's just physical damage somewhere causing all this PCIe weirdness
<eddyb>
if would make much more sense if it was exactly one slot that was messed up
<eddyb>
or, well, I'm not super sure what's going on, but it sounds like some of what I'm seeing might be expected? but it's a bit of a whacky configuration. so maybe it still is firmware, hmpf
<eddyb>
hmm what's a good first thing to test the Glasgow on? oh right whitequark said `glasgow run analyzer --pins-i 0:6` when I suggested straight-up recording the 7seg pins. presumably that outputs one of those signal trace files I can open in a viewer (I forget the name, gtkwave?)
<eddyb>
lol I left the X99 on and it's randomly beeping, minutes later
<eddyb>
poor thing is probably still trying to do something with itself
<eddyb>
(mood)
<whitequark>
gtkwave or pulseview
<_whitenotifier>
[glasgow] electroniceel commented on issue #220: Qualification tests for revC2: pre INA233 - https://git.io/JLHD8
<_whitenotifier>
[glasgow] electroniceel assigned issue #220: Qualification tests for revC2: pre INA233 - https://git.io/JTw0C
<marcan>
electronic_eel, whitequark: so apparently cypress has the CCG3 which is a PD controller with an M0 and a USB peripheral (they market it as billboard class, but it's just their standard USB-FS block?)
<whitequark>
marcan: yep
<whitequark>
that's ez-pd right?
<marcan>
yeah[
<whitequark>
iirc i looked at those parts and they had a stupid selection of packages, something like wlcsp only
<electronic_eel>
from a hw side it looks better suited than the stm32g0
<whitequark>
oh i probably just missed that then
<whitequark>
ignore me
<whitequark>
five bucks for a m0 with pd and usb fs, wow
<electronic_eel>
but they are quite pricey
<whitequark>
i guess that's just how cypress does
<whitequark>
i wonder if the more expensive cypress MCUs means they are going to make them for longer
<whitequark>
that silicon can't possibly be expensive to make
<electronic_eel>
and you will be pretty much alone figuring out the peripherals. the stm32 are much more common, so you'll find lots of resources about the quirks of their peripherals
<whitequark>
on the other hand, cypress tends to not have quirky peripherals
<whitequark>
the fx2 has what, one erratum?
<marcan>
yeah. the STM32 is going to have a lot nicer ecosystem
<whitequark>
i've uh, heard not very good things about the STM32 ecosystem from someone who was figuring stuff out (with fusb302, coincidentally)
<whitequark>
in terms of c code you can grab and use, anyway
<whitequark>
the rust one is better in some ways and worse in others
<electronic_eel>
for example the timers are a joke compared to what the stm32 offer, they don't have dma,...
<whitequark>
oh, that sort of quirk
<electronic_eel>
so as general purpose mcus the cypress isn't very good
<jpa->
stm32 ecosystem is almost too wide.. there is lot of good stuff and lot of pretty bad stuff
<jpa->
and a lot of the vendor-provided libraries are pretty crappy
<eddyb>
whitequark: thanks!
<eddyb>
heh, the LEDs aren't blinding, but I get lens flare, and it's really tough on my potatocam
<jpa->
in my experience: as long as STM32xxxxx.h is enough, ST's stuff is ok; but HAL & cube are quite annoying; chibios is nice, libopencm3 is ok
<electronic_eel>
jpa-: just my experience. forget hal & cube
<eddyb>
I wonder what the easiest way to get some diffusion thing going on could be. I have some white PLA and a 3D printer that hasn't been used in almost a year,
<whitequark>
jpa-: yeah that sounds about what i heard
<eddyb>
hmm, I can see I can set up pull-{up,down}s, but it's not clear if I need to connect Vsense?
<eddyb>
I'm hoping that even if it's needed, nothing bad will happen, but better be safe than sorry
<_whitenotifier>
[glasgow] electroniceel commented on issue #220: Qualification tests for revC2: pre INA233 - https://git.io/JLHSM
<_whitenotifier>
[glasgow] whitequark commented on issue #220: Qualification tests for revC2: pre INA233 - https://git.io/JLH9s
<whitequark>
eddyb: Vsense is optional
<whitequark>
it is purely an ADC that may be used (or not used) at your discretion
<eddyb>
ah, nice!
<whitequark>
and the applets have a shortcut for "use the same voltage as the DUT" if you do connect Vsense
<whitequark>
they can also automatically power off Vio if Vsense drops to avoid back-powering the target through e.g. JTAG pins
<whitequark>
which tends to make ESD diodes on the JTAG pins extremely unhappy and sometimes stop existing
<eddyb>
hmm, what's the sample rate on that? like could it be reasonably used as a (slow) analog input
<whitequark>
on the order of 1 kHz
<eddyb>
ah, one of those :P
<whitequark>
except you do not have any guarantee of regular sampling
<whitequark>
it's an analog oscilloscope the same way your network card's LED is a video output
<eddyb>
that's still probably way faster than a multimeter, right? but not good enough for subsampling shenanigans
<whitequark>
technically yes, but you probably want to use just about anything else instead
<whitequark>
it's also way less precise than a multimeter
<eddyb>
lol
<whitequark>
depending on revision you might be getting something like 8 bits of resolution and some noise on top of that
<whitequark>
actually it's flat out impossible to tell offhand for me how much resolution you have because we specify 3 different ADCs depending on availability
<eddyb>
curious in what state it is when it gets here. the things on the top left are 4 100Msps ADCs
<eddyb>
(and their respective frontends)
<whitequark>
oh nvm it still has the info
<eddyb>
these go for like $200-$600 "used" (tho they might be different configurations? unclear)
<whitequark>
wow, xc4062xl, that's *vintage*
<whitequark>
cc mwk
<whitequark>
that FPGA is from 1999
<eddyb>
I got attracted by the big chips but then I also realized that it's basically a 4ch oscilloscope :P
<whitequark>
there are probably engineers in this channel younger than that FPGA
<eddyb>
also note the i960 :D
<eddyb>
that one arch with the weird XOR mention on wikipedia
<whitequark>
yeah yeah
<gruetzkopf>
i do actually have a few i960 socs
<gruetzkopf>
complete with nontransparent pci64@66MHz bridges
<gruetzkopf>
and a compaq lightsout full-size PCI card
<eddyb>
anyway, I suspect the 4ch of 100Msps alone could be neat to play with and might not even require cooperation from the rest of the board. tho I would still want to try and get it working for its intended purpose if possible
<whitequark>
they might be sampling with a phase offset to get 100 MSPS
<whitequark>
probably all four together then?
<eddyb>
nnno I don't think I saw "100" anywhere
<eddyb>
just lossy memory
<mwk>
meow?
<_whitenotifier>
[glasgow] whitequark commented on issue #252: recover flashing doesn't work when firmware or gateware is flashed - https://git.io/JLHHJ
<_whitenotifier>
[glasgow] electroniceel commented on issue #220: Qualification tests for revC2: pre INA233 - https://git.io/JLHHU
<whitequark>
mwk: see backlog, ancient xilinx fpga!
<eddyb>
looks like a simple 8-bit parallel ADC, so presumably I can try poking it with the Glasgow once I get the board :3
<mwk>
... it's not ancient enough if I have tooling for it
<eddyb>
tho these might've been more expensive originally, since they have the DIMM socket
<whitequark>
mwk: don't you have tooling for like
<mwk>
oh huh there are two of them
<whitequark>
all xilinx devices
<mwk>
no, sadly
<eddyb>
anyway, uhh, if anyone wants me to poke it in any way, find JTAG, etc. I'll be happy to
<mwk>
I'm missing xc40** (without suffix, and with h/d/a suffx), xc52**, xc62**, xc71**, xc81**
<whitequark>
eddyb: i mean you could find jtag using the jtag-pinout applet
<mwk>
JTAG is pretty well-documented
<whitequark>
just hook it up to ... arbitrary connectors until you succeed
<eddyb>
heh yeah
<whitequark>
oh, the FPGA, not the board
<eddyb>
I was thinking more, once I have that, if anyone wants access
<_whitenotifier>
[glasgow] electroniceel commented on issue #252: recover flashing doesn't work when firmware or gateware is flashed - https://git.io/JLHHc
<eddyb>
not sure how much bitstream protection they had back them
<eddyb>
*then
<mwk>
none
<eddyb>
:D
<mwk>
I mean, well, maybe there's a "disable readback" bit there or something
<_whitenotifier>
[glasgow] whitequark commented on issue #252: recover flashing doesn't work when firmware or gateware is flashed - https://git.io/JLHHW
<mwk>
but it's pretty useless when it has to be uploaded from some external flash in the first place
<eddyb>
oh haha how do I keep forgetting basic stuff like that
<eddyb>
right, when I first saw the board I was thinking the first thing I might try to do is dump all the flash chips I can spot
<eddyb>
tho if it requires desoldering I would try to get it working first
<_whitenotifier>
[glasgow] whitequark commented on issue #252: recover flashing doesn't work when firmware or gateware is flashed - https://git.io/JLHHB
<eddyb>
anyway uhhh hopefully the Romanian Post doesn't give it the same treatment they did to that X470 mobo (I got an empty and damaged box, most likely stolen. sad thing is, it had a weird USB current protection error that I was hoping to fix, so whoever took it likely threw it away or had to sell it as defective again,)
<_whitenotifier>
[glasgow] whitequark commented on issue #252: recover flashing doesn't work when firmware or gateware is flashed - https://git.io/JLHHu
<_whitenotifier>
[glasgow] electroniceel commented on issue #252: recover flashing doesn't work when firmware or gateware is flashed - https://git.io/JLHH1
<_whitenotifier>
[glasgow] whitequark commented on issue #252: recover flashing doesn't work when firmware or gateware is flashed - https://git.io/JLHHH
<_whitenotifier>
[glasgow] whitequark commented on issue #252: recover flashing doesn't work when firmware or gateware is flashed - https://git.io/JLHHA
<_whitenotifier>
[glasgow] electroniceel commented on issue #252: recover flashing doesn't work when firmware or gateware is flashed - https://git.io/JLHQv
<_whitenotifier>
[glasgow] whitequark commented on issue #252: recover flashing doesn't work when firmware or gateware is flashed - https://git.io/JLHQL
<_whitenotifier>
[glasgow] electroniceel commented on issue #252: recover flashing doesn't work when firmware or gateware is flashed - https://git.io/JLHQm
egg|laptop|egg has joined #glasgow
<eddyb>
> E: g.applet.interface.analyzer: FIFO overrun, shutting down
<eddyb>
does that mean it can't keep up?
<d1b2>
<Attie> yes... likely too many edges (iirc it does RLE-type compression on the stream)
<d1b2>
<Attie> are you poking at a PCIe clock? or have a floating input?
<eddyb>
right, so if I hooked it up to SPI flash, the moment it started reading all 128Mbits, it filled the queue :P
<d1b2>
<Attie> heh, very possibly... any visibility on the clock rate?
<eddyb>
I did get something, tho, screenshot once I get the protocol decoder working
<eddyb>
these are all 8 pins of the DIP8 socketed flash (which was a PITA to grab on to, but still, :D)
<d1b2>
<Attie> hah, well done
<d1b2>
<Attie> that looks like ~20MHz, but it could be more... the clock looks to be a little aliased / jittery
<eddyb>
given the clock is a waste of events, is there an SPI decoder applet? that would only FIFO the actual data
<eddyb>
I guess it'd also be at least 8x less data even ignoring the clock
<d1b2>
<Attie> there is an SPI controller applet
<d1b2>
<Attie> don't think there's currently an SPI sniffer applet though
<d1b2>
<Attie> (or peripheral side applet either)
<d1b2>
<Attie> do you feel up to the challenge?
<eddyb>
a bit surprised, since that's literally the first thing that popped into my head in terms of low-speed stuff in consumer hardware to take a peek at :P
<eddyb>
oh uhh maybe? but also I got lazy and grabbed Glasgow from nixpkgs, it would take a bit more effort to run from my local checkout
<d1b2>
<Attie> it should be pretty straight forward to get it running from a checkout
<d1b2>
<Attie> perhapsa venv, and then python3 ./setup.py develop
<eddyb>
I've used nmigen before, and the reliable way to do it requires specifying all the dependencies through Nix (I couldn't get venv to play nicely, or maybe I didn't know how to use it). it should only take me like 5 minutes, I just have to go do it. I guess I can keep the grabbers as-is to repeat the test later
<eddyb>
like it's mostly copy-pasting, I just didn't do it because I wanted low-effort "does the hardware work"
<d1b2>
<Attie> fair enough
<electronic_eel>
getting glasgow running from a local checkout shouldn't be too hard. the spi flash decoder is more complicated though. i think you'd need a proper async clock domain to make it work because of the clock speed that is usually used by mainboards
<eddyb>
also, I forgot I got ground off the tower cooler heatsink lmfao
<d1b2>
<Attie> haha, ew...
<eddyb>
like, one of the pins being probes is literally the chip's GND pin, I just didn't want to disturb the castle of cards
<eddyb>
*probed
<eddyb>
electronic_eel: eugh
<d1b2>
<Attie> feel free to make an issue for an "SPI sniffer" type applet... i think it would be a useful one to have
<electronic_eel>
whitequark wrote that she tried to sniff the lpc bus before and it didn't work without async clock domain. that was when she decided to develop nmigen, because omigen couldn't do that properly
<electronic_eel>
and lpc is a similar speedn than the spi flash (33 MHz)
<d1b2>
<Attie> oh, hah......
<eddyb>
that came up a few days ago, yeah, but wou- OH
<eddyb>
I guess that might explain the weird clock edges huh
<eddyb>
or rather, the inconsistency in the clock line being recorded
<d1b2>
<Attie> yip
GNUmoon has quit [Remote host closed the connection]
<d1b2>
<Attie> (i mentioned aliased / jittery above... I'd suspect the former first)
GNUmoon has joined #glasgow
<electronic_eel>
iirc there is a flash type info block at the start of the flash, the chipset reads that out and decides based on the data which speed to use. so you can change that block to lower the speed. but the lowest speed is iirc 20 MHz
<kmc>
so the fpga is sampling the SPI clock according to its internal clock? and it's better to sample triggered on the SPI clock?
<kmc>
that seems like a great example of something glasgow can do that a MCU-based tool couldn't :D
<kmc>
externally clocked LA
<electronic_eel>
kmc: yes, exactly
<d1b2>
<Attie> aye
<kmc>
should allow much higher speeds recording digital buses
<eddyb>
if anyone is wondering just how janky my setup is, the socketed SPI flash is in the top right (had to take this at an angle because of the light positioning)
<d1b2>
<Attie> ee, tight
m4ssi has joined #glasgow
<d1b2>
<Attie> ... it's socketed though, so you could pull it out, and use the SPI controller applet to read out the contents
<d1b2>
<Attie> (not quite sure what you're after here... playing with glasgow vs flash contents vs is the board alive)
<eddyb>
yupp, pulling it out was the plan, this was more of a curiosity + making sure I understand how to use the Glasgow
<d1b2>
<Attie> oky
DarthCloud has joined #glasgow
<eddyb>
the board has a POST code so I know it gets pretty far, the PCIe slots are the weird bit, and reading the flash is because I want to try and figure out what version it has (couldn't get BIOS Flashback to work)
<eddyb>
s/weird bit/outright broken
<d1b2>
<Attie> ah yes
<d1b2>
<Attie> (fwiw, i'm really not convinved by using a multimeter to determine PCIe activity / aliveness)
<d1b2>
<Attie> @whitequark - is it possible to get sys_clk_freq (or similar) from the device object?...
<d1b2>
<Attie> i.e: we have target.sys_clk_freq availble in GlasgowApplet.build(), but I can't see a way to get it from within GlasgowApplet.run()
<d1b2>
<Attie> (without storing it on the applet)
<eddyb>
I mean, yes, it's just that the other board I have is far more consistent in its behavior, and it's failing to bring up GPU on PCIe that it gives up on, it's just not super clear what is at fault
<d1b2>
<Attie> hmm, very frustrating - i presume you've already tried onboard / other slots / other cards? (don't mean to cover what you've already done)
<d1b2>
<Attie> *onboard video
<d1b2>
<Attie> ... or even BMC-esque video
<eddyb>
X99 is a non-mainstream platform, it literally doesn't have pins in the socket for iGPU power/output :P
<eddyb>
BMC would be nice but sadly not a server mobo
<d1b2>
<Attie> ohh, hah
<eddyb>
tried all the slots, and electrically they're all weird in different ways. also there's that thing where the fan on the smol test GPU I have keeps... restarting randomly, every few seconds
<eddyb>
so maybe link integrity is compromised?
<gruetzkopf>
could also be a simple power problem
<d1b2>
<Attie> the GPU is powered correctly?
<eddyb>
I'm specifically using tiny things that don't require any external power
<d1b2>
<Attie> (if it's a modular power supply, is it the correct cable? the pin map is not common amongst all)
<eddyb>
you know, I did get one of those silly mining riser things, I wonder if I can get that working because AFAICT it doesn't pass power through the USB3 cable
<d1b2>
<Attie> re tiny / no power... hmm, don't forget "no power" actually means "all power via motherboard"
<d1b2>
<Attie> the mining risers are just PCIe over USB3, you'll need to power it separately, and certainly is worth a shot (for the above reason)
<kmc>
well, PCIe over USB3 cables
<kmc>
I don't think they implement any of the USB3 protocol although I could be wrong
<d1b2>
<Attie> correct
<kmc>
I have some of those silly things in storage too...
<d1b2>
<Attie> there's no refclk either i don't think, it's just the Tx / Rx pairs
<eddyb>
hmm it looks like they pass some power through the cable, but it's probably just 3.3V?
<eddyb>
anyway, I can't get the weird constant restarting behavior with the riser, but it doesn't work any better or anything
<kmc>
oh I had another question about Glasgow: are the pins on the LVDS header independent from everything else?
<kmc>
that is I can use those however I want from gateware without interfering with the other functionality?
<d1b2>
<Attie> independent? yes
<kmc>
and what are the electrical specs on that? should I just look at the iCE40HX8K datasheet for that?
<agg>
they're directly wired to the ice40, but are pins that have optional comparators for differential input
<d1b2>
<Attie> the datasheet would be the best place to look, there's no protection on them, and they just go to the FPGAs pads
<d1b2>
<Attie> *comparators, in the FPGA... not discrete
<d1b2>
<Attie> @eddyb - oh shame
<d1b2>
<Attie> if you haven't already, i'd be tempted to suggest another graphics card (possibly one with extra power)
<d1b2>
<Attie> you've been at it for a while though, so not sure I can add much... sorry!
<gruetzkopf>
Attie: they put refclk on d+/d-
<d1b2>
<Attie> ah interesting... i was just looking for a pinout / schematic, but coming up empty
egg|laptop|egg has quit [Remote host closed the connection]
<eddyb>
and soon thereafter the FIFO overrun occurs
<eddyb>
anyway makes sense it would read SFDP first thing
<kmc>
what exactly is the use case for the SYNC header on Glasgow?
egg|laptop|egg has joined #glasgow
azolast has joined #glasgow
azolast has quit [Remote host closed the connection]
<d1b2>
<Attie> @kmc - the intention is to allow multiple glasgows to be connected together, and effectively increase channel count
<sorear>
AFAIK nobody has used it yet for any reason so I still have some lingering doubts it's fit for purpose
Lofty has quit [Remote host closed the connection]
miek has quit [Ping timeout: 260 seconds]
miek has joined #glasgow
ZirconiumX has joined #glasgow
ZirconiumX is now known as Lofty
<d1b2>
<NorthernDom> Hello! I’m about to support the CS campaign with a purchase, but I’m Not quite sure I can wait, so going to fab/assemble some boards in the meantime, can I ask out of curiosity why we use the RevC1 and not the RevC2 for that? 🤔
<d1b2>
<Attie> revC2 is still being worked on, not quite ready yet
<d1b2>
<Attie> also, the campaign will likely ship revC3 (minor tweaks past the revC2 prototypes we currently have)
<d1b2>
<NorthernDom> Ah I figured as much. Great work. This is so exciting. What are the fabrication requirements? Is this JLCable? Or PCBWay jobbie?
<electronic_eel>
JLC doesn't have the FPGA and the FX2 iirc
<d1b2>
<Attie> if you're going to assemble yourself, I seem to remember people have got bare boards from JLC okay
<d1b2>
<NorthernDom> Oh no I mean for the bare PCB. I’ll do the assembly
<electronic_eel>
yeah, the pcbs from jlc are fine. the revC2 prototypes were made at jlc
<d1b2>
<NorthernDom> Thanks a bunch. Let me know if there is anything I can help with (other than purchasing from CS).
<d1b2>
<Attie> welcome to the club 🙂
<d1b2>
<NorthernDom> I’m happy to be here!
<sorear>
I think people have also done mixed service/hand assembly
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
<whitequark>
agg: Attie: every document used in Glasgow itself has been archived in, well, the Glasgow archive.
<whitequark>
specifically because vendors can't be trusted.
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
<d1b2>
<Attie> i saw that, i approve
egg|laptop|egg has quit [Remote host closed the connection]
<_whitenotifier>
[glasgow] electroniceel commented on issue #220: Qualification tests for revC2: pre INA233 - https://git.io/JLQJj
<_whitenotifier>
[glasgow] electroniceel commented on issue #220: Qualification tests for revC2: pre INA233 - https://git.io/JLQUK
<electronic_eel>
whitequark: re the archive: i've seen that parts on Glasgow itself are missing, like the ds for the ice40 and the fx2. it seems to just contain stuff applets are written for
<electronic_eel>
is that intentional?
<electronic_eel>
it looks like one vendor already dropped relevant info: the current ds of the ATECC doesn't contain anything about the registers and commands anymore
<electronic_eel>
now we aren't using the ATECC anymore, but it is a prime example why not to trust vendors
GNUmoon has quit [Ping timeout: 240 seconds]
egg|laptop|egg has joined #glasgow
<_whitenotifier>
[glasgow] electroniceel commented on issue #220: Qualification tests for revC2: pre INA233 - https://git.io/JLQkC
egg|laptop|egg has quit [Remote host closed the connection]
<_whitenotifier>
[glasgow] electroniceel commented on issue #220: Qualification tests for revC2: pre INA233 - https://git.io/JLQIL
GNUmoon has joined #glasgow
<d1b2>
<davoid> random question, is the plan to compensate "live" for the drop over the sense-resistor (i.e. by reading the shunt voltage at INA233)
<electronic_eel>
the adjust-voltage divider of the voltage regulator is behind the shunt resistor
<electronic_eel>
so the voltage regulator will automatically compensate for it
<electronic_eel>
no software necessary
egg|laptop|egg has joined #glasgow
<d1b2>
<davoid> ah, that's good! then you just have to rely on the fact that the regulator output is what we set it to do
<d1b2>
<davoid> or the current meas will be off
<d1b2>
<davoid> or I take that back... actual source current will be correct, but current going through gpio's to the outside world vs losses in the on-board regulator will be unknown (less relevant for the use-case I guess since we're not measuring uA's)
<electronic_eel>
sorry, I don't get what the problem is
<electronic_eel>
the INA233 will correctly measure what the dut will draw through the vio pin and what goes through the port pins
<electronic_eel>
it can only measure vio and gpios together
<d1b2>
<davoid> I did a similar design to be used in an automated factory test-setup and due to tolerances in regulators vs load, the io-rails might be 3.15V instead of 3.3V, this is where I wish I'd had the control to read it back and compensate for it
<electronic_eel>
you can measure any differences between set-voltage an real voltage with the vsense pin
<electronic_eel>
that goes to the INA233 and can be read back
<electronic_eel>
but it is not hardwired and it is an expected usecase that the user connects it to something else
<electronic_eel>
so there is no code in firmware to automatically compensate for any differences
<electronic_eel>
but we plan to allow calibration and to store calibration coefficients in eeprom in the future
<electronic_eel>
since the voltage regulators just provide 150 mA (guaranteed value, about 300 mA can be drawn in most cases), drop in wiring will not be that much that it really matters
<d1b2>
<davoid> good, and since these are all gpio's it'n not really used to power things, even though 150mA is plenty for most modern ARM's
<d1b2>
<davoid> def. nice with a per-board calibration process. but how do you calibrate the calibrator 🙂
<d1b2>
<davoid> where you thinking a board that you push onto the blue headers or make use of external DMM's?
<electronic_eel>
there is a Vio pin for each port. it is designed to connect low power duts to it.
<electronic_eel>
so powering a small arm is fully within what Glasgow is designed for
egg|laptop|egg has quit [Remote host closed the connection]
<electronic_eel>
re calibration: i don't think the boards will come pre-calibrated to tight analog specs. the idea is more that users can later self-cal their Glasgow with their own (high-spec) gear
<electronic_eel>
so you hook up your 3458a and enter all the 8.5 digits readout and that is then written to eeprom ;)
<d1b2>
<davoid> sounds reasonable
<d1b2>
<davoid> just checking the latest schematic. are those resistors after the VDAC -> Feedback pin of the LDO 0.1% ?
<d1b2>
<davoid> (again something that can be calibrater)
<electronic_eel>
no, the resistors are regular ones, most probably 1%
<electronic_eel>
also the dac itself is also limited precision
<electronic_eel>
that area will definitely profit from user cal
egg|laptop|egg has joined #glasgow
m4ssi has quit [Remote host closed the connection]
<d1b2>
<davoid> 👍
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
tobbez has joined #glasgow
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]