azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps, https://github.com/azonenberg/scopehal, https://github.com/azonenberg/scopehal-docs | Logs: https://freenode.irclog.whitequark.org/scopehal
bvernoux has quit [Quit: Leaving]
<_whitenotifier-f> [scopehal] azonenberg opened issue #344: LeCroyOscilloscope: handle "DC" coupling type for active probes. Don't try to change attenuation on them - https://git.io/Jk2i8
<_whitenotifier-f> [scopehal] azonenberg labeled issue #344: LeCroyOscilloscope: handle "DC" coupling type for active probes. Don't try to change attenuation on them - https://git.io/Jk2i8
<_whitenotifier-f> [scopehal] azonenberg opened issue #345: Add "invert" option for use with differential probes - https://git.io/Jk2iS
<_whitenotifier-f> [scopehal] azonenberg labeled issue #345: Add "invert" option for use with differential probes - https://git.io/Jk2iS
<azonenberg> Playing with some 5 Gbps PCie
<azonenberg> so far its not decoding right, i get a bazillion 8b10b errors
<azonenberg> the eye is pretty open so i have to debug more, i feel like i'm probably misaligning somehow
<azonenberg> I got exactly one SKIP sequence in my test that gave me a valid decode
<azonenberg> every other time even though the waveform looked almost the same i got garbage
<azonenberg> so i think my 8b10b decode isnt liking the data for some reason
<monochroma> :o
<azonenberg> ok its more complicated than that, the pll is involved too i think
<azonenberg> So, to start... i originally wrote the 8b10b aligning code for Ethernet
<azonenberg> And 1000base-X has *huge* numbers of commas in the idle sequences between packets
<azonenberg> So your SNR for alignment is superb
<azonenberg> to give you an idea, on the saved test waveform i was working with for 1000base-X, I have 2 commas at offset 6, 3020 at offset 1, and none at any other phase
<azonenberg> So it's extremely obvious what the correct alignment is
<azonenberg> PCIe and SATA have much less commas because they send scrambled data between packets
<azonenberg> Which means i need to be able to do a valid alignment with a much smaller number of commas
<azonenberg> The problematic sequence i'm seeing now is K29.7 K28.5 K28.0
<azonenberg> end of good packet, comma, skip
Degi has quit [Ping timeout: 256 seconds]
<azonenberg> K29.7- is 1011101000 and K28.5- is 0011111010
<azonenberg> The thing is, K29.7 K28.5 combined forms 10111010000011111010 which has five zeroes and five ones in a row back to back
<azonenberg> I think what might be happening is that at high data rates compared to the sample rate, it doesn't take a lot of drift for the PLL to desync enough that you get a bit error at the end of that long run
<azonenberg> What i'm seeing in the error case is that I decode the bit sequence as ...10100000, but then only four 1s before going low
<azonenberg> so i align to the false negative comma
Degi has joined #scopehal
<azonenberg> The fact that PCIe uses a spread spectrum clock probably doesn't help
<azonenberg> Because my PLL currently is low-order and doesn't track the rate of change of frequency
<azonenberg> So basically i think the failure mode is the perfect storm of relatively low oversampling, (deliberate) clock drift, very few commas in the data, and then a long run of bits with a false comma right before the real one
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jk27h
<_whitenotifier-f> [scopehal] azonenberg 3e227da - IBM8b10bDecoder: synchronize only to K28.5, not any other commas. This works fine for most standard protocols, and prevents aligning to false comma sequences.
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jk25J
<_whitenotifier-f> [scopehal] azonenberg bcb2f7b - Fixed typo
<_whitenotifier-f> [scopehal] azonenberg opened issue #346: USB PMA decode fails on low-slew signals - https://git.io/Jk257
<_whitenotifier-f> [scopehal] azonenberg labeled issue #346: USB PMA decode fails on low-slew signals - https://git.io/Jk257
<_whitenotifier-f> [scopehal] azonenberg labeled issue #346: USB PMA decode fails on low-slew signals - https://git.io/Jk257
<_whitenotifier-f> [scopehal-apps] azonenberg opened issue #285: CSV import: allow importing files with header rows - https://git.io/Jk2dJ
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #285: CSV import: allow importing files with header rows - https://git.io/Jk2dJ
<_whitenotifier-f> [scopehal-apps] azonenberg opened issue #286: CSV import: detect digital channels and import correctly - https://git.io/Jk2dI
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #286: CSV import: detect digital channels and import correctly - https://git.io/Jk2dI
<azonenberg> monochroma: ok so at this point i have working 8b10b decoding on my pcie. I should try it on sata and see if it's more reliable now too
<azonenberg> Now i just need to start writing upper layer decodes
<monochroma> oooo
<azonenberg> There are some actual TLPs in there i think, but i'm a ways from being ready to decode them
<miek> the aglent triggers are confusing me, the "glitch" trigger in the scpi docs is actually referred to as a pulse width trigger everywhere else
<miek> azonenberg: how does a real glitch trigger work on the scopes you've used?
<_whitenotifier-f> [scopehal] miek edited issue #342: AgilentOscilloscope: add pulse width trigger support - https://git.io/Jkzab
<azonenberg> miek: That's a very good question. I'm not entirely clear what the difference is between a glitch and pulse width trigger on lecroy
<azonenberg> i implemented a UI to configure the various settings on the scope
<azonenberg> but it doesn't really look any different from a width trigger setting wise
<azonenberg> i haven't done much experimentation to figure that out
<azonenberg> in any case, we have a pulse width trigger type
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
<_whitenotifier-f> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±3] https://git.io/JkacO
<_whitenotifier-f> [scopehal] azonenberg 5019815 - LeCroyOscilloscope: detect active probes and don't allow changing coupling on them. Fixes #344.
<_whitenotifier-f> [scopehal] azonenberg d0e4f58 - LeCroyOscilloscope: Don't allow changing attenuation on active probes
<_whitenotifier-f> [scopehal] azonenberg closed issue #344: LeCroyOscilloscope: handle "DC" coupling type for active probes. Don't try to change attenuation on them - https://git.io/Jk2i8
<_whitenotifier-f> [scopehal-apps] miek commented on issue #284: Agilent MSOX2024A - Performance issues and crash - https://git.io/JkaBZ
<_whitenotifier-f> [scopehal] miek opened pull request #347: AgilentOscilloscope: support pulse width trigger - https://git.io/JkaVt
<azonenberg> miek: your PR looks good except for one minor change
<azonenberg> rather than using PushFloat() like you have, just use to_string_sci()
<azonenberg> which is a scopehal equivalent to std::to_string(double) that outputs scientific notation
<azonenberg> So you can just do SendCommand( path + to_string_sci(f) )
<azonenberg> Fix that and i'll merge
<_whitenotifier-f> [scopehal] miek synchronize pull request #347: AgilentOscilloscope: support pulse width trigger - https://git.io/JkaVt
<_whitenotifier-f> [scopehal] azonenberg pushed 2 commits to master [+2/-0/±4] https://git.io/JkaoM
<_whitenotifier-f> [scopehal] azonenberg dfe8c7b - IBM8b10bDecoder: fixed bug causing incorrect decoding of K28.5+
<_whitenotifier-f> [scopehal] azonenberg c3cbee5 - Finished initial implementation of PCIeGen2LogicalDecoder. See #35.
<azonenberg> monochroma, lain: ping
<azonenberg> Is there any reason for the PCIe logical layer decoder to have a protocol analyzer view?
<lain> I could maybe see it being useful in debugging pcie implementations, unless you can get the same information from another layer
<azonenberg> Hmm
<azonenberg> this is what i have so far
<lain> nice
<azonenberg> So you think displaying raw TLPs, skips, idles, and DLLPs as hexdumps in the protocol analyzer would be good?
<azonenberg> my thought was that the next layer up i would crack all the headers
<azonenberg> and have a proto analyzer view for *that*
<azonenberg> This layer is mostly descrambling and framing etc
<lain> ahm, yeah that makes more sense
<azonenberg> and converting from 64/66 or 8b/10b to a unified representation i can use for a single upper layer stack
<azonenberg> that doesnt (mostly) care what gen of pcie you're on
<_whitenotifier-f> [scopehal] azonenberg closed issue #342: AgilentOscilloscope: add pulse width trigger support - https://git.io/Jkzab
<_whitenotifier-f> [scopehal] azonenberg closed pull request #347: AgilentOscilloscope: support pulse width trigger - https://git.io/JkaVt
<_whitenotifier-f> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JkaK9
<_whitenotifier-f> [scopehal] miek 7f67aff - AgilentOscilloscope: support pulse width trigger fixes #342
<_whitenotifier-f> [scopehal] azonenberg aa3b89f - Merge pull request #347 from miek/agilent_pulsewidth_trigger AgilentOscilloscope: support pulse width trigger
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 2 commits to master [+1/-0/±1] https://git.io/JkaKd
<_whitenotifier-f> [scopehal-apps] azonenberg 10a9993 - Added PCIe Gen2 RX eye mask
<_whitenotifier-f> [scopehal-apps] azonenberg f068c2a - Updated scopehal
<azonenberg> this is the probe setup. Loving this diffprobe so far, my main complaint is that i don't (yet) have two. And the price tag of course
<lain> how much was that one again?
<azonenberg> the order for the solder-in one is pending though... so in a few weeks i should be able to probe both the tx and rx sides
<azonenberg> the one here or the solder-in?
<lain> both
<azonenberg> this one was about 3.8K after tax and shipping
<lain> yow
<azonenberg> The D420 was $1760 plus tax and shipping, plus $275 to cal it to the WL-PBUS which I bought from a third party for $500 + shipping from tel aviv
<azonenberg> Yeah. the combo of these probes, and upgrading sonnet to l2 silver next month, is eating the entirety of my lab budget for Q4 2020
<azonenberg> and probably dipping a bit into Q1 2021 so i can recover my savings :p
<lain> :3
<lain> hehe
<azonenberg> but for the stuff it's allowing me to do, it's definitely worth it
<azonenberg> at this point i can basically see any serial data stream up to 10 Gbps
<azonenberg> and do SI work out to 1-2 Gbps
<lain> excellent
<azonenberg> incidentally, i can actually read part of an ethernet frame already
<azonenberg> i have a usb3 to gig-e dongle plugged into that port and i'm ping flooding some other host on the lan from it
<azonenberg> to generate pcie traffic for me to look at
<azonenberg> there's a TLP early on in my capture that obviously contains a linux ping payload
<azonenberg> i see incrementing byte sequences then 4 random-looking bytes that are obviously the FCS
<azonenberg> (the ethernet/ip headers must be in an earlier TLP off the start of my capture)
juli966 has joined #scopehal
<lain> ha
<azonenberg> now what would be really cool is if i set the phy to 100baseTX
<azonenberg> and could decode the frame off the wire
<azonenberg> and also see the pcie traffic that generated it
<azonenberg> I might try that later on
<monochroma> XD
<azonenberg> That would actually be a really nice demo
<azonenberg> but oh wait
<azonenberg> it's not pcie to ethernet, it's pcie to usb3 to ethernet
<azonenberg> i guess i need to make a usb3 decode too :p
<azonenberg> Seeing every step on the path would be nice
<monochroma> just need to decode usb3, and then the usb ethernet layer ;)
<azonenberg> Lol
<azonenberg> i mean if i was actually doing serious debug
<azonenberg> i might do that
<azonenberg> write a decoder for either the pcie or usb protocol for the specific chipset i was working with
<monochroma> yeah, hopefully you never get in that situation
<azonenberg> Lol yeah
<azonenberg> But it would be a nice demo of the things you can do with scopehal that are just outright impossible in another platform
<azonenberg> with lecroy software, decoding ethernet and IP inside of pcie tlps just isn't a thing
<azonenberg> in scopehal, it's totally doable
<monochroma> :3
<azonenberg> all you'd need to do is make a decode that takes a pcie tlp stream as input, figure out which TLPs went to a single frame, then call EthernetDecoder::BytesToFrames() on it
<azonenberg> boom, full ethernet decoding, integration with all of the upper layer protocol decodes, wireshark, the works
<azonenberg> i might actually do that at some point just for kicks if the protocol doesnt look too nasty
<azonenberg> not the full chain, just demonstrating ethernet decoding inside of pcie
<azonenberg> would it be super useful? no. is it a cool tech demo? absolutely
<azonenberg> The implication to users being, you can go build this for whatever protocol your system uses
<azonenberg> I will probably make a decode for FTDI chips at some point too
<azonenberg> that takes in a usb data stream and outputs uart text and metadata or something
<monochroma> i remember having to manually decode IP frames on an inline USB sniffer between the DUT and cellular modem, wishing i could just feed the USB CDC ACM into a decoder to decode the PPP frames, and just give me the IPv4 packet dump
<azonenberg> lol
<azonenberg> that's the exact type of scenario i'm talking about
<_whitenotifier-f> [scopehal] azonenberg opened issue #348: PCIe gen 1/2: Known plaintext calculation of scrambler state during beginning of waveform - https://git.io/JkaQP
<_whitenotifier-f> [scopehal] azonenberg labeled issue #348: PCIe gen 1/2: Known plaintext calculation of scrambler state during beginning of waveform - https://git.io/JkaQP
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jka7l
<_whitenotifier-f> [scopehal] azonenberg 5570c94 - PCIe logical: Fixed handling of "scrambler desynced" payloads if we have other control characters before the first K28.5. See #35.
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JkVkL
<_whitenotifier-f> [scopehal] azonenberg 178889d - PCIeGen2LogicalDecoder: Use known plaintext to sync to LFSR earlier during idles rather than waiting for a K28.5 to reset it. Fixes #348.
<_whitenotifier-f> [scopehal] azonenberg closed issue #348: PCIe gen 1/2: Known plaintext calculation of scrambler state during beginning of waveform - https://git.io/JkaQP
<azonenberg> ok so this was a fun optimization
<azonenberg> rather than waiting for a K28.5 comma character, which resets the scrambler
Stephanie has joined #scopehal
Stephanie has quit [Excess Flood]
Stephie has quit [Read error: Connection reset by peer]
Stephanie has joined #scopehal