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]
smkz has quit [Quit: smkz]
smkz has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
Pretzel4Life has joined #scopehal
Pretzel4Ever has quit [Ping timeout: 260 seconds]
electronic_eel_ has joined #scopehal
electronic_eel has quit [Ping timeout: 272 seconds]
juli966 has quit [Quit: Nettalk6 - www.ntalk.de]
<azonenberg> lain: what do you think of making left and right handed variants of the AKL-PT2?
<azonenberg> i.e. ground left or right of the signal contact
<azonenberg> so you can do GSSG pairing of two to probe a diffpair
<lain> ooh
<azonenberg> it would literally just be a mirroring of the copper gerbers
<lain> couldn't you just solder one upside-down?
<azonenberg> that puts the resistors on the underside
<azonenberg> i'm doing it now but it's awkward
<lain> ahh right
<lain> yeah that'd be handy then
Kenley has quit [Read error: Connection reset by peer]
<_whitenotifier-f> [scopehal-apps] azonenberg synchronize pull request #252: Implemented Preferences System - https://git.io/JTovz
<_whitenotifier-f> [scopehal-apps] azonenberg edited issue #43: Add preference for changing protocol decoder field colors (Filter::m_standardColors) - https://git.io/JeHyu
<_whitenotifier-f> [scopehal-apps] azonenberg assigned issue #43: Add preference for changing protocol decoder field colors (Filter::m_standardColors) - https://git.io/JeHyu
azonenberg has quit [Ping timeout: 256 seconds]
azonenberg_work has quit [Ping timeout: 260 seconds]
azonenberg has joined #scopehal
azonenberg_work has joined #scopehal
azonenberg has quit [Remote host closed the connection]
azonenberg has joined #scopehal
azonenberg has quit [Remote host closed the connection]
azonenberg has joined #scopehal
<_whitenotifier-f> [scopehal-apps] azonenberg opened issue #253: MIPI D-PHY compliance wizard - https://git.io/JTK3D
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #253: MIPI D-PHY compliance wizard - https://git.io/JTK3D
<_whitenotifier-f> [scopehal-apps] azonenberg commented on pull request #252: Implemented Preferences System - https://git.io/JTK3Q
azonenberg_work has quit [Ping timeout: 246 seconds]
azonenberg has quit [Ping timeout: 260 seconds]
azonenberg has joined #scopehal
azonenberg_work has joined #scopehal
electronic_eel_ is now known as electronic_eel
juli966 has joined #scopehal
juli966 has quit [Ping timeout: 240 seconds]
juli966 has joined #scopehal
<azonenberg> MIPI D-PHY symbol level decode
<azonenberg> upper level is coming shorlty
<lain> :D
<monochroma> azonenberg: that will be pretty cool, iirc some discreete modem chipsets connect to the SoC via a MIPI interface
<azonenberg> monochroma: I'm not familiar with those at all. My plan is to do the full DPHY decode to bytes of data and control states
<azonenberg> then at some point in the indefinite future do DSI
<monochroma> yeah, i'm not sure how many (if any) are on the market yet
<_whitenotifier-f> [scopehal] azonenberg opened issue #324: MIPI C-PHY protocol decode - https://git.io/JTKr3
<_whitenotifier-f> [scopehal] azonenberg labeled issue #324: MIPI C-PHY protocol decode - https://git.io/JTKr3
<_whitenotifier-f> [scopehal] azonenberg opened issue #325: MIPI A-PHY protocol decode - https://git.io/JTKrR
<_whitenotifier-f> [scopehal] azonenberg labeled issue #325: MIPI A-PHY protocol decode - https://git.io/JTKrR
<_whitenotifier-f> [scopehal] azonenberg labeled issue #326: MIPI M-PHY protocol decode - https://git.io/JTKrE
<_whitenotifier-f> [scopehal] azonenberg opened issue #326: MIPI M-PHY protocol decode - https://git.io/JTKrE
<azonenberg> Not that i have any immediate need, but at least now there are tickets so we can keep track of the fact that this is something to do eventually
<azonenberg> I can get DSI test data easily with this pi setup so i will probably try and record a bunch of it even if i'm not implementing the decode until later
<azonenberg> lain: for the upper half of D-PHY, I think I'm going to call it "D-PHY Data"
<lain> C-PHY is bonkers.
<azonenberg> oh? i havent looked at any of them at all
<azonenberg> i just went down the list of phys on the mipi website and added tickets for each :p
<lain> I haven't looked at A-PHY and I don't remember anything about M-PHY
<azonenberg> M-PHY is fast, it goes up to 11.6 Gbps per lane
<lain> C-PHY is a 3-level thing
<monochroma> lain: where does i3c come in? :P
<azonenberg> MLT3? PAM3? or something weirder
<lain> monochroma: oh god why would you remind me that exists
<azonenberg> you remind me i never made a ticket for that
<_whitenotifier-f> [scopehal] azonenberg opened issue #327: I3C protocol decode - https://git.io/JTKo1
<_whitenotifier-f> [scopehal] azonenberg labeled issue #327: I3C protocol decode - https://git.io/JTKo1
<azonenberg> i've never seen anything that uses it
<azonenberg> but it exists there for i will probably eventually encounter it and write a decode :p
<azonenberg> therefore*
<lain> it's custom 3-level across 3 wires per lane
<monochroma> luckily there are mostly phones, and old phones are cheap
<lain> it's.. wild
<azonenberg> wuuuut
<azonenberg> why
<azonenberg> d... did a three-phase motor design this?
<monochroma> XD
<lain> hahaha
<lain> M-PHY looks pretty sane, 8b10b, maybe pure differential?
<azonenberg> Either that, or the folks from Rendezvous With Rama that triplicate everything :p
<azonenberg> yes, i expect M-PHY is going to just use standard SERDES and be a custom framing over several lanes for striping etc
<azonenberg> But i havent looked in detail
<azonenberg> at the PHY layer it should be sane though
<azonenberg> Seriously though, what were the designers of C-PHY smoking?
<azonenberg> also why three lanes per port?
<azonenberg> "about 2.28 bits per symbol"
<azonenberg> wuuuut
<azonenberg> and i thought MLT-3 was weird
<monochroma> i know some of these have gotten very minimal (if any) actual use
<azonenberg> one can only hlpe
<azonenberg> hope*
<azonenberg> a lot of these "XYZ protocol decode" tickets are placeholders someone can comment on if they need it
<azonenberg> and in the meantime they will gather dust until i encounter it in the wild
<azonenberg> lain: also my plan is for "D-PHY Data" to decode a single lane
<azonenberg> maybe i should rename it to "D-PHY Lane"?
<azonenberg> but data might make more sense since it takes in a data and clock lane
<azonenberg> Anyway, striping is the responsibility of the upper layer protocol
<monochroma> azonenberg: can you think of any power conservation reasons for C-PHY? that's pretty much what MIPI is all about, doing whatever to lower power consumption
<azonenberg> No idea
<azonenberg> I don't really do low power
<lain> azonenberg: "D-PHY Data (Lane)" and "D-PHY Data (Bus)" maybe?
<lain> it's a bit wordy but...
<lain> iirc D-PHY does define how data is striped across lanes, not the higher-level protocols like CSI/DSI
<azonenberg> I'll play with that once i get a multilane interface to look at
<azonenberg> For short term it will be single only
<azonenberg> lain: if the clock stops between DPHY packets
<azonenberg> is the clock running during the start-of-transmission sequence or no>
<azonenberg> ?
<lain> azonenberg: iirc the clock must be running HS for some time prior to data lanes entering HS
<azonenberg> I'm taking a detour before doing symbol decoding to glitch filter the LP states
<azonenberg> any state transition << Tlpx is gonna get filtered out
<azonenberg> setting the cutoff as 40ns for now, Tlpx is 50
<azonenberg> that allows a bit of margin for rise/fall time to make the bit slightly too short
<azonenberg> lain: what is the bit ordering for bytes on csi/dsi?
<azonenberg> lsb or msb first?
<azonenberg> I only have the dphy spec handy and it doesnt specify bit ordering
<lain> azonenberg: both are lsb first
<azonenberg> in fact, the dphy spec *explicitly does not* specify bit ordering
<azonenberg> and states that ordering is 100% up to the upper layer protocol
<azonenberg> while at the same time saying its data is byte oriented :p
<azonenberg> so i dont see how you are supposed to do a clean layered design like this :p
<azonenberg> would specifying lsb first have been so hard?
<azonenberg> at the dphy layer i mean
electronic_eel has quit [Ping timeout: 264 seconds]
electronic_eel has joined #scopehal
<_whitenotifier-f> [scopehal-apps] nshcat synchronize pull request #252: Implemented Preferences System - https://git.io/JTovz
<_whitenotifier-f> [scopehal] azonenberg pushed 4 commits to master [+4/-0/±9] https://git.io/JT64c
<_whitenotifier-f> [scopehal] azonenberg 46519ef - LeCroyOscilloscope: Correctly calculate memory depth in interleaved mode
<_whitenotifier-f> [scopehal] azonenberg beee353 - Symbol level decoding of MIPI D-PHY. See #48.
<_whitenotifier-f> [scopehal] azonenberg fef97a7 - Added glitch filtering to D-PHY LP symbols. See #48.
<_whitenotifier-f> [scopehal] azonenberg 3c2ff32 - Initial implementation of MIPI D-PHY byte-level data decode. Only decodes HS data and framing, not escape mode. Fixes #48.
<_whitenotifier-f> [scopehal] azonenberg closed issue #48: Add MIPI D-PHY protocol decoder - https://git.io/JJfcY
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JT64z
<_whitenotifier-f> [scopehal] azonenberg 31d32d9 - DPhySymbolDecoder: decode high voltages as LP-11 not LP_10
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JT60u
<_whitenotifier-f> [scopehal] azonenberg fcb6df0 - Proper handling of EOT
<_whitenotifier-f> [scopehal-apps] nshcat commented on pull request #252: Implemented Preferences System - https://git.io/JT6Ec
<_whitenotifier-f> [scopehal-apps] azonenberg commented on pull request #252: Implemented Preferences System - https://git.io/JT6E5