<d1b2>
<louis> Still screwin' with it, but here's a sneak peek
<d1b2>
<louis> May change it to instead graph all selected on the same graph widget
<azonenberg>
Nice
<azonenberg>
btw, not sure if you've looked at liblogtools in detail yet
<azonenberg>
but if you wanted to make a log sink that would push bridge console output into the debug stream on the socket
<azonenberg>
that is totally doable
<azonenberg>
logtools supports arbitrarily many sinks that messages can be sent to
<azonenberg>
the only two currently implemented are console and files
<azonenberg>
but that is in no way an architectural limitation
<azonenberg>
just never had a reason to build others
<azonenberg>
@louis: also rather than a "G" button maybe have a column titled "graph" that contains a Gtk::Switch?
<azonenberg>
or a Gtk::CheckButton
<azonenberg>
might look better that way
massi has joined #scopehal
nelgau_ has quit [Ping timeout: 250 seconds]
nelgau has joined #scopehal
massi has quit [Quit: Leaving]
bvernoux has joined #scopehal
azonenberg has quit [Ping timeout: 240 seconds]
azonenberg has joined #scopehal
<d1b2>
<Aleksorsist> Quick question, does glscopeclient do persistence with the triggered data it gets in, or does it somehow get the persistence data from the scope?
<azonenberg>
aleksorsist: persistence is all implemented in postprocessing based on stacking multiple acquisitions
<azonenberg>
there is currently no support for downloading hardware based persistence from the scope
<azonenberg>
at least Pico has this capability in hardware
<azonenberg>
unsure about other vendors
<azonenberg>
but we don't implement it yet
<d1b2>
<Aleksorsist> Perfect, just got to get the triggering then
<azonenberg>
Long term i would like to support persistence in hardware to get faster update rates and detection of rare glitches etc
<azonenberg>
But the alternative approach is of course just to try to capture waveforms at faster rates and stream to the host
<azonenberg>
which is basically what you're going for
<azonenberg>
as of now we max out at one waveform per GPU frame but i have plans to improve the rendering path to handle frames arriving fastr than they can be displayed
<azonenberg>
such that you get persistence within single GPU frames
<azonenberg>
your hardware, the dslogic stuff, and i think possibly the picoscope 6000e family are the only scopes in the pipeline so far where this might be a problem
<azonenberg>
nothing else is this fast :p
<azonenberg>
(also i will continue to recommend that you push triggering to fpga vs trying to stream it all over the thunderbolt interface)
<d1b2>
<Aleksorsist> That is the obvious (and probably best) solution! Software triggering has proven feasible though and I really want to see what's possible with it
<d1b2>
<Aleksorsist> Worst case is a switch my forever backordered a35t to an a50t and do triggering in that
<azonenberg>
i mean simple edge triggering should be doable in hardware on a 35t
<azonenberg>
just a question of capture buffer for pretrigger etc
<d1b2>
<Aleksorsist> Our 35t is 90% utilized 😬
<azonenberg>
oh fun lol
<azonenberg>
yeah that makes it trickier
<d1b2>
<Aleksorsist> Hard to get both 32 bit wide ddr3l and PCIe dma in
<d1b2>
<Aleksorsist> Had to tweak some non-gui options in the xdma core just to get it to fit lol
<d1b2>
<Aleksorsist> The Datamover IP is bloated and buggy so maybe writing a custom one could free the space needed
<d1b2>
<Aleksorsist> That plus reconfiguring the FPGA when changing triggers could do it. Though PCIe would not like that one bit
<azonenberg>
So, funny you mention that
<azonenberg>
i had been talking with some other folks about "poor man's partial reconfig" for triggers
<azonenberg>
essentially building a state machine containing some SRLC32E's
<azonenberg>
which you serially load with truth tables
<azonenberg>
and then use as LUT5s
<azonenberg>
i've done this in the past for other purposes
<GyrosGeier>
I've written very lean PCIe DMA blocks in VHDL that sit on top of the TLP streaming interface
<GyrosGeier>
omitting things like transfers that are not 8 byte aligned saves a lot
<GyrosGeier>
also, the streaming interface is asynchronous for the most part
<GyrosGeier>
you send a TLP and get a reply at some later point
<GyrosGeier>
(or in the case of DMA writes, you send TLPs)
<d1b2>
<Aleksorsist> Both of these are very interesting
<d1b2>
<Aleksorsist> For the reconfigurable triggering I assume it's a programmable sequence of rising or falling edges
<d1b2>
<Aleksorsist> As for PCIe, streaming could be very promising, as it may eliminate the ddr3 buffer needed by the memory mapped xdma core
<azonenberg>
and well, my plan was actually to create a state machine and a bunch of blocks that could detect various things
<azonenberg>
for example, a clocked deserializer
<azonenberg>
or an edge detector
<azonenberg>
or a window check that looks for levels inside/outside some range
<azonenberg>
etc
<azonenberg>
then you'd be able to trigger on an arbitrary sequence of them, possibly with specific timing
<GyrosGeier>
Aleksorsist, it might also be worthwhile to run the DDR interface in a kind of streaming mode
<d1b2>
<Aleksorsist> @GyrosGeier That was something I considered, but it's only worth it if the PCIe core is streaming as well. And the xdma core streaming implementation is awful, running at around 50MB/s instead of >1GB/s
<d1b2>
<Aleksorsist> @azonenberg A kind of triggering toolbox of things you can chain together arbitrarily, that would be really cool
<GyrosGeier>
the PCIe streaming needs to insert 128 bits of TLP headers every 4kB at least
<azonenberg>
Yeah. i have some notes i threw together
<azonenberg>
but the plan was to try and make this some kind of open standard eventually
<_florent_>
Aleksorsist: PCIe does not require that much buffering, just enough the absorb the temporary PCIe unavailability (which can vary a bit depending the machine). I've always managed to avoid buffering in DRAM on 7-Series FPGAs when doing continuous TX/RX streaming at up to 13/14Gbps in each direction for a Gen2 X4 link.
<azonenberg>
_florent_: oh hey, while you're here
<_florent_>
Aleksorsist: What's your PCIe configuration?
<azonenberg>
I would like to add litescope support to glscopeclient at some point in the indefinite near future
<azonenberg>
if you're interested in helping out with that
<_florent_>
azonenberg: yes sure, but in fact LiteScope if very simple and also a bit limited (since just storing samples in BRAM)
<azonenberg>
of course. but that is the point
<azonenberg>
i want to support cross triggering of ILAs and external scopes
<azonenberg>
in order to do combined debug of on and off chip components
<_florent_>
azonenberg: but that could still be intersting to simplify things and use the internal decoders of GLScopeClient
<azonenberg>
trigger on a checksum failure in the FPGA
<azonenberg>
then jump to the analog PHY capture of the signal and investigate what corrupted the packet
<azonenberg>
etc
<tnt>
possible complication of litescope is that it has a bunch different transports if you want to implement those natively in glscopeclient.
<azonenberg>
tnt: i'm thinking the bridge approach probably makes the most sense
<azonenberg>
have N different backends for the bridge and one socket api to scopehal
<azonenberg>
that's what we've traditionally done for things that did not have a native scpi interface
<tnt>
ok so you can just re-use the litex_server thing.
<azonenberg>
the other reason being, we do not want to require you to link libscopehal against dozens of vendor API blobs
<azonenberg>
when you are only going to use one or two of those instruments
<azonenberg>
we want one portable binary and then you install the bridges required by your hardware if it lacks a native usbtmc, rs232, or ethernet interface
<d1b2>
<Aleksorsist> @ florent how much Bram did you need for the buffering? My experiments showed that 512KB was needed, any less would drop samples due to latency caused by the OS. My configuration is a xilinx XDMA core in memory mapped mode reading from ddr3, which is written to by a xilinx datamover block.
<d1b2>
<Aleksorsist> @ florent (this would require the largest artix part, so it was more worthwhile to use ddr3)
<azonenberg>
_florent_: Yeah my main interest is on chip debug integrated with external instruments
<azonenberg>
and cross triggering
<azonenberg>
i want to reverse engineer the jtag protocol for the xilinx ila as well
<azonenberg>
so i can integrate with their ip
<_florent_>
Alerksorsist: For Gen2 X4, 13-14Gbps of continuous streaming, I'm using maximum 128KB of buffering for each direction (but 128KB was only required on some specific machines, 64KB is enough on most)
<d1b2>
<Aleksorsist> Florent: what IP is this on for PCIe?
<azonenberg>
litepcie i assume
<_florent_>
yes
<d1b2>
<Aleksorsist> Impressive! I never gave it a try since there was no windows driver
<_florent_>
Aleksorsist: indeed, I was going to ask you the question (if you wanted to windows support)
<d1b2>
<Aleksorsist> Has anyone built a windows driver for it?
<_florent_>
there's only a Linux driver for now
<d1b2>
<Aleksorsist> Florent: Ah, that may be an issue. We're aiming for Linux and Windows. I don't know what getting a windows driver done would entail, but I imagine it would be painful
<d1b2>
<Aleksorsist> Florent: which sucks since it sounds like I could ditch the ddr3 and free up loads of FPGA space by using litepcie
<_florent_>
Aleksorsist: Sorry yes, a windows driver is not planned and I'm not able to estimate the efforts. But in case you can to test LitePCIe on Linux, happy to prepare a design for your hardware.
<azonenberg>
@aleksorsist: might be worth having a chat with @mp about that eventually
<d1b2>
<Aleksorsist> True, it would save me a lot of hassle to use LitePCIe and I could definitely look at commissioning a Windows driver once our campaign is over.
<azonenberg>
anyway, you can always decide later, up to the point that you actually put ram in the sockets
<azonenberg>
or solder it on
<azonenberg>
(i forget if you were going sodimm or chip-down)
<azonenberg>
or even later, you can just not use it
<d1b2>
<Aleksorsist> Florent: I'd really appreciate a demo if you have time!
<d1b2>
<Aleksorsist> Azonenberg: true, choice to pop/depop can be zero hour lol
<d1b2>
<Aleksorsist> Azonenberg: we are chip down
<_florent_>
Aleksorsist: can you share info about your hardware? At minima I need the PCIe pinout to prepare the design, the design could run from the PCIe clock if you don't have other clock for the system.
<d1b2>
<Aleksorsist> Florent: we actually run from the PCIe clock already. Everything is open source under the ThunderScope repo and I can grab you the xcf pinout file if that will help too
<d1b2>
<Aleksorsist> Florent: Sorry for the messy organization, the repo needs some clean-up which I've had no time for 😅
<_florent_>
Aleksorsist: Thanks. I'll prepare this tomorrow then. I'll pre-generate the FPGA bistream to avoid you the LiteX installation on your side :)
<d1b2>
<Aleksorsist> Florent: Much appreciated :) Also realized that if this works I'll be well within the power budget and won't have to do something very janky to draw more amps (and with less power comes less chunky heatsink over FPGA). I am very excited 😄
<d1b2>
<Aleksorsist> Now if only Windows didn't exist...
<d1b2>
<Aleksorsist> One can dream of a better world that would be
<azonenberg>
lol
<_florent_>
Aleksorsit: :) I could also be interested by a Windows driver for LitePCIe and could probably find some funds to help developing it.
<azonenberg>
Awesome
bvernoux has quit [Quit: Leaving]
<_florent_>
Aleksorsit: just for info, here is a board designed for a client:
<_florent_>
it's able to do 3G-SDI TX/RX on 4 channels without buffering in DDR
<_florent_>
so equivalent of >300MS/s on each channel in your case, so I'm really confident you can avoid the DDR
<_florent_>
It's late here, going to bed. I'll prepare and share the PCIe design tomorrow.
<azonenberg>
yeah streaming is a whole different ballgame. my problem in most of my projects is doing buffered/triggered capture of much higher volumes of data
<azonenberg>
(e.g. 80 Gbps of logic analyzer samples)
<d1b2>
<Aleksorsist> Florent: Sweet looking board! Thanks again for the help 🙂
<d1b2>
<Aleksorsist> Florent: And working together to make a windows driver sounds like an excellent idea