12:47 <tnt> Well ... I implemented the 'streaming' mode in a way that works. (I'm not a jtag expert but I'm pretty sure openocd is doing DRPAUSE wrong and I had to "match their wrongness").

12:47 <tnt> It still sucks :/ 30MHz JTAGBone is 20x slower at downloading a litescope trace than a 2Mbaud UARTBone.

13:34 <tnt> Unfortunately I think there is a bunch of inefficiencies points that compound:

13:35 <tnt> - AFAICT LiteScope just uses plain old single-at-a-time register read to get the data, but each read is one command, then the latency to wait for the response and then get the data. No bursting or anything to avoid that long latency cycle.

13:37 <tnt> - The whole valid/ready handshake on the jtagbone also means that it can only send one byte per drscan burst because if the ready bit it reads back is 0, it would have no way to stop any further bytes in the burst to go through should the 'ready' bit flip to 1 during a burst.

14:09 <_florent_> tnt: litex_server is able to automatically regroup read access in bursts with https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_server.py#L24

14:10 <_florent_> tnt: this should happen during the LiteScope upload

14:10 <tnt> _florent_: but they're not sequential reads

14:10 <tnt> I mean ... thre is a few sequential to read the width of the monitored burst.

14:10 <tnt> but then it's reading the same address again.

14:11 <tnt> So lets say you monitor 64 bits, it will read address 0 4 0 4 0 4 0 4 0 4 ....

14:11 <tnt> So sure, it regroups the 0 4 in a burst, but that's not much compared to all the reads to get the whole data.

14:13 <tnt> Also in litescope_cli it's calling regs.xxxx.read() so it would want the result before issuing the next one, so it wouldn't have any opportunity to merge.

14:14 <_florent_> tnt: it will indeed have more effect on large capture buses

14:18 <tnt> should probably rever d8df6cb27d0d2611ab4e4fd41d303c111525581c too. I guess there was a reason it wasn't in the list and I just assumed it was an inadvertant omission.

14:20 <_florent_> tnt: but yes, this is a simple upload protocol and this could be optimized

14:21 <tnt> That's what I'm looking at now. It's probably the shortest path to increase performance.

14:21 <tnt> (rather than keep banging my head against JTAGBone)

14:26 <_florent_> tnt: to allow fixed bursts, we could also only expose the data on a 32-bit CSR and use DownConverter between the mem FIFO and the CSR interface.

14:26 <_florent_> tnt: this would avoid the 0 4 0 4 0 4 etc... pattern and allow read_merger to generate a proper fixed burst

14:26 <tnt> Yes, that's the plan.

14:27 <_florent_> but we should also probably avoid checking mem_valid for each data: https://github.com/enjoy-digital/litescope/blob/master/litescope/software/driver/analyzer.py#L162

14:27 <tnt> And I also have a plan to deal with the 'mem_valid' it sticks in there.

14:28 <_florent_> ok good :)

14:29 <_florent_> instead of the valid, you could report the mem.level on a CSR

14:29 <tnt> I think the valid is mostly there to deal with the CDC fifo becoming empty

14:30 <tnt> in case the 'scope' clock domain is slow vs the 'sys' one.

14:31 <tnt> Or maybe not ... because it aborts if not valid.

14:31 <tnt> Then yeah, actually just reading the level at the beginning instead of storage_length would do.

14:35 <_florent_> tnt: I did something very close to speed-up crossover UART, this can maybe be useful: https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_term.py#L122-L131

14:36 <_florent_> tnt: here I was monitoring full/empty CSR but principle will be similar with a level CSR.

14:38 <tnt> _florent_: is there convenient way to get the native CSR bus width ?

14:38 <tnt> (instead of just CSRStatus(32) ...)

14:42 <_florent_> The SoC has it (self.csr_data_width), but this is not directly available from the core, this could be a parameter of LiteScopeAnalyzer

14:44 <_florent_> tnt: csr_data_width of 8 is still supported, but not sure it's useful have it optimized with LiteScope since mostly here for retro-compabitibility and almost everyone is probably using csr_data_width=32 now

16:19 <tnt> Gotta run now, but first results are encouraging. ~ 7x speed up of the download phase and > 85% of the theoritical max bitrate of UART.

16:41 <_florent_> Great!

16:55 <jevinskie[m]> About JTAGbone speed… I’ve been pondering for a while about adding another bit to the protocol. If set, it would initiate a DMA from a following addr/length pair and stream it out

16:59 <_florent_> jevinskie[m]: we could think about an alternative protocol to speed up large transfers yes. (I was also thinking doing something similar for Etherbone where we could just stream the data on a specific UDP port to/from the Host)

19:09 <tnt> jevinskie[m]: well the protocol actually already support that since it's the same UARTBone protocol and supports bursting.

19:10 <tnt> But an improvement to the tunneling made in JTAGBone would be that instead of a 'ready' bit (in the device -> host directly), we use an 'not almost full' bit instead. So that if it's not set, we can safely push several chars because there is enough buffer space.

21:08 <tnt> Pushed a PR for the new proto. Should probably be tested by a few more people though :)

22:49 <znullptr[m]> used all defaults for install ` litex_sim --cpu-type=vexriscv ` : ../libc/libc.a(libc_ssp_chk_fail.c.o): in function `__chk_fail': undefined reference to `write'