<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/Jvu8z
<_whitenotifier-3>
[scopehal-apps] azonenberg 7e0415d - Continued file-save work. Directory and top level YAML file are created; window dimensions, waveform group, and splitter config are serialized. No waveform area config or actual waveform data yet. See #3.
<tnt>
azonenberg: yes, the offset worked.
<tnt>
next step is to actually try a real signal and not just a dirct connection from the wavegen :p
<azonenberg>
:)
m4ssi has joined #scopehal
wbraun has joined #scopehal
m4ssi has quit [Ping timeout: 240 seconds]
m4ssi has joined #scopehal
massi_ has joined #scopehal
m4ssi has quit [Read error: Connection reset by peer]
massi_ has quit [Read error: Connection reset by peer]
m4ssi has joined #scopehal
m4ssi has quit [Read error: Connection reset by peer]
m4ssi has joined #scopehal
<Error_404>
ahh yes, re-discovered the original issue. deadlock because sometimes the siglents just won't respond to you
<Error_404>
going to just hack in a sendcommand that retries properly with some back-off so that the ui thread doesn't totally die
<Error_404>
for some reason they go ahead and ack you, but just..don't..bother responding with any payload
<tnt>
The agilent does that if you have several scpi connections open. The other are still active at a TCP level but only 1 actually gets responses.
<Error_404>
yeah, the siglent will do that too, but at least it's deterministic
<Error_404>
this is just...eventually, and probably on a wavedesc packet.
<monochroma>
Error_404: binary patch the firmware
<Error_404>
/mute monochroma
<Error_404>
oops i mean
<tnt>
lol
_whitelogger has joined #scopehal
<tnt>
azonenberg: I'm not sure how to do it though. I'd like to evaluate the signal quality of a hyperram DQ line. But they are bidirectional, so at some point in the access they are host driven and at some other point they are device driven and ideally I'd like to have different eyes for both phases.
<tnt>
(yeah, I picked a super-easy one right ? :)
<azonenberg>
tnt: Separate DQ r/w eyes for bidirectional buses is planned but not yet implemented
<azonenberg>
the basic idea is that you'll gate the eye sampling clock by a protocol decoder that outputs a "is writing" and "is reading" bit
<azonenberg>
then do a separate eye using each clock
<azonenberg>
but that needs a little more work to be usable
<azonenberg>
The "gate" input to the CDR PLL is supposed to take in a boolean clock-enable signal and output a gated recovered clock, but it doesn't quite work right
<azonenberg>
in the case of DDRx it's a bit easier because you don't need to do CDR, you have DQS
<azonenberg>
So you can just use a not-yet-written filter to edge detect DQS and gate that by state == WRITING or READING
<tnt>
Hah, here I have RWDS which sort of work like DQS for the data cycles. (but it's used for another purpose during the address phase).
<azonenberg>
yeah i've looked at hyperram a bit, never finished my controller
<tnt>
I also wanted to check the eye vs the clk as well because the controller doesn't actually use RWDS edges for capture, it only validates them during the memory training phase to find good delay/phase values.
<azonenberg>
i think for readback you'd want to look at RWDS, CS#, CLK, and DQ
<azonenberg>
if you use DQ7 you get the R/W bit for free ;)
<tnt>
ahah :)
<azonenberg>
Then for write eye you could look at any DQ pin because you wouldn't need to look at RWDS
<azonenberg>
anyway a hyperram decode i think is a prerequisite to this
<_whitenotifier-3>
[scopehal] four0four pushed 1 commit to Siglent-WIP [+0/-0/±1] https://git.io/JvudM
<_whitenotifier-3>
[scopehal] four0four 99468ea - fix-up some chunks that got lost in the merge
<azonenberg>
Error_404: so after this, what's the status of the siglent driver?
<Error_404>
I'm..bad at git is what
<Error_404>
but
<Error_404>
it builds/works fine against the master branch, working on working-around that no response issue I mentioned last night
<azonenberg>
So it's functional but incomplete?
<Error_404>
also looks like there's a new SCPITransport() scopes instatiate with? will add that too
<Error_404>
functional in that sometimes it grabs a trace before the scope hangs up on you and the ui thread deadlocks yes
<azonenberg>
Yes. the goal is to be able to drop in uart vs usb etc later on
<Error_404>
I wouldn't put it in master until I fix that
<Error_404>
ok
<azonenberg>
if the scope itself is hanging, and you need to add workarounds for that, i'd still put it in master
<azonenberg>
My general rule for merging something to master is that it makes a release no less functional
<Error_404>
oh, yeah this changes nothing for anyone else
<azonenberg>
adding new drivers that aren't at 100% is OK, people can hack on that. Just no regressions
<Error_404>
I think I can merge it to scopehal
<azonenberg>
So what I want in the near future from you is... merge this to master, then update glscopeclient main with code to create it using the driver name "lecroy_lan"
<azonenberg>
with "siglent_lan" as an acceptable alias
<azonenberg>
then update scopehal-docs in the siglent section with info on driver arguments and current test status / known issues
<Error_404>
k, putting that together
<azonenberg>
this same driver should also work on lecroy T3DSO and i have someone interested in testing that
<azonenberg>
i want to see if it has the same hang issue
<_whitenotifier-3>
[scopehal-apps] four0four pushed 1 commit to master [+0/-0/±1] https://git.io/JvuFa
<Error_404>
they can use that master with the -WIP branch of scopehal to test it
<azonenberg>
Error_404: please merge the current siglent driver into master on scopehal and do further driver dev on master at least until we get to a somewhat stable base of the siglent driver
<azonenberg>
as long as you don't push code that doesn't compile, you're making it no less functional
<Error_404>
sounds good
<azonenberg>
if you want to do private dev branches after that point that's fine. But master is what i expect testers to be working on
<_whitenotifier-3>
[scopehal] four0four pushed 3 commits to master [+2/-6/±13] https://git.io/JvuFS
<azonenberg>
And update docs. Let me add you to that repo
<Error_404>
yeah, that's in progress
<azonenberg>
added
<azonenberg>
Error_404: one of the reasons the old siglent driver doesnt use SCPITransport, btw, is that the lecroy driver currently assumes some stuff happens in blocks like VICP
<azonenberg>
refactoring that is a TODO on my end
<azonenberg>
so you may not be able to do that until i fix scopehal:68
<Error_404>
ahh, ok. let me know when that's ready and I'll refactor it then
<azonenberg>
scopehal:71 is the ticket for doing that on the siglent driver
<Error_404>
nice, ok
<azonenberg>
short term priority is making it work, the only problem from this architecture is it doesnt fit into the overall scopehal arch quite as cleanly, and once we implement usb/rs232 SCPITransport's they won't be trivial dropins for lecroy/siglent scopes
<azonenberg>
So i'd say your top priority is the doc update, second is continuing workarounds for scope quirks and hangs
<_whitenotifier-3>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/Jvubt