00:42 <somlo> zyp: thanks, that makes sense

00:42 <somlo> cr1901_modern: when I plug in the usb cable to my nexys4ddr, I get *two* /dev/ttyUSB* devices, 0 and 1

00:43 <somlo> 0 is the "jtag" (used by openocd to push bitstream). 1 is the "normal" uart that's going to get the console traffic, works fine with screen and minicom, etc.

00:45 <somlo> now if you pass '--uart-name jtag_uart', the SoC ends up connecting its uart external "pads" to the jtag (usb0) device

00:46 <somlo> the "quirk" is that you can't speak "serial" to it directly, it has to be tunneled over openocd, which litex_term knows how to do

00:46 <cr1901_modern> How do you make a SoC with two serial ports?

00:48 <somlo> cr1901_modern: heh, I haven't made it to that part *yet* -- once I had the jtag_uart working I declared victory and started running errands (it's evening here) :) I'll figure that part out tomorrow

00:48 <cr1901_modern> (The answer might be "you don't")

00:49 <somlo> but I have a bunch of pads free (to what connects to my computer as usb1), so I think I need to instantiate another uart IP block connected to those pads, and somehow do the litescope-over-uart thing using *it*

00:50 <somlo> it all depends on what litex does when you pass "--uart-name jtag_uart" on the build command line :)

00:51 <somlo> per _florent_ (earlier), you definitely should be able to make a SoC with two uarts if you hook up an external (pmod) uart

00:51 <cr1901_modern> I think calling "add_uart" twice will do what I want

00:54 <somlo> don't have easy access to the source (on IRC through layers of cell hotspots and VPNs :) so I can't easily check, but yeah -- either that, or whatever happens inside add_uart with a bunch of different arguments (selecting the pins/pads/whatever connecting the FPGA to the physical interface you intend to use

07:29 <_florent_> somlo: using two regular UARTs is not supported by the BIOS, with JTAG UART the UART of the SoC will be redirected over JTAG which frees up the regular UART pins that you can use to create a UART bridge (add_uartbone) for LiteScope.

12:08 <acathla> Does it seem correct that it takes 156 clock cycles to write a byte on CSR (UART in my case) ?

12:09 <acathla> In a simple for loop in C, executed from RAM, on a VexRiscV variant simple.

12:41 <zyp> how do you measure?

12:44 <zyp> sounds like at least an order of magnitude too much to me

13:49 <acathla> zyp, with a capture with LiteScope

13:51 <zyp> how does the code look? have you checked the disassembly for the write loop?

13:51 <acathla> not yet

14:48 <somlo> _florent_, cr1901_modern: I managed to build and test litescope via the "normal" uart (with console tunneled over jtag)

14:48 <somlo> --with-ethernet --with-sdcard --integrated-rom-size 0x10000 \

14:48 <somlo> --uart-name jtag_uart --with-analyzer --csr-csv ./csr.csv

14:48 <somlo> --cpu-type rocket --cpu-variant linux --sys-clk-freq 50e6 \

14:48 <somlo> litex-boards/litex_boards/targets/nexys4ddr.py --build \

14:51 <somlo> meh, the command line is useless without the patch for the nexys4ddr target: https://pastebin.com/yjXnHPGW

14:51 <tpb> Title: diff --git a/litex_boards/targets/nexys4ddr.py b/litex_boards/targets/nexys4ddr. - Pastebin.com (at pastebin.com)

16:52 <cr1901_modern2> _florent_: Idk if this bug exists when using a terminal from Linux, but right now it's possible to end up in a state in the BIOS firmware where the USB CDC core stops firing interrupts

16:52 <cr1901_modern2> Is this a known bug?

16:54 <somlo> whoo! just managed to order an ecpix5 (85k version) from lambdaconcept \o/

16:55 <somlo> (after fighting several layers of automated credit card security systems, due to the international nature of the transaction, but all's well that ends well :D

16:57 <Zguig> (y)

17:11 <acathla> somlo, if you do some captures with litescope (or an external analyzer), I'm interested in how many clock cycles it takes between two writes.

17:12 <_florent_> cr1901_modern2: I've not seen this behavior no with the tests I did (only linux)

17:14 <_florent_> somlo: good for the jtag_uart/litescope I think it will be very useful for the work you are doing

17:17 <cr1901_modern2> _florent_: Interesting. I'll see if I can find anything.

17:17 <cr1901_modern2> FWIW, it only happens during reset

17:18 <cr1901_modern2> And only sometimes (wheee...)

17:42 <somlo> acathla: I'll have to rebuild it and add the memory port to the list of monitored signals, then I'll try to capture it from the start of memtest

17:43 <somlo> I haven't yet tried to make sense of any of the data included in `dump.vcd`, just worked on getting it to capture something/anything until now

17:48 <somlo> _florent_: one weird thing is that I can add e.g. l2fb_wb to the analyzer_signals list, but *not* l2fb_axi (the latter results in "object of type 'AXIInterface' has no len()" error)

17:50 <_florent_> somlo: probably because l2fb_axi is not a Record but group of Records (aw, ar, w, b, r)

17:50 <somlo> and since mem_axi isn't converted to wishbone (I rocket connects to litedram over a point-to-point axi link that isn't converted to WB), I don't know how I'd look at that interface with litescope

17:50 <somlo> oh, so I should add the individual records separately?

17:50 <_florent_> somlo: yes you can try that

17:50 <somlo> worst case, enumerate all the signals (ugh, I'd rather not have to do that :) )

17:52 <somlo> _florent_: `[ self.cpu.mem_axi.aw, self.cpu.mem_axi.ar, ...]` seems to work (at least it starts building without erroring out, so I hope that takes care of it -- thanks!

18:26 <acathla> Hum, on a versa_ecp5 with a minimal vexriscv, the bios freezes after displaying the date of build.

19:38 <somlo> ok, I can grab the `depth = 512` samples of all my three axi ports, now I'll look at coming up with some interesting trigger condition (since rocket has an internal L1 cache, and will probably try to burst writes to litedram accordingly)

21:21 <_florent_> acathla: make sure to run "rm -rf build" before building your design :)

21:27 <acathla> _florent_, right! I forgot it does not clean the software part

21:35 <acathla> 42 clock cycles on a vexriscv minimal on the versa_ecp5, 156 on the iCE40...

21:53 <somlo> _florent_: in litescope_cli, can you combine trigger criteria, such as "-r sig_1 AND -v sig2 0x80000000" ?

21:55 <somlo> basically, use a boolean expression of various individual signals to trigger collection of the sample?

21:58 <zyp> acathla, how does your write loop look?

23:01 <somlo> _florent_: based on the way add_triggers() is written (https://github.com/enjoy-digital/litescope/blob/master/litescope/software/litescope_cli.py#L53) it looks like there's an implicit AND if one provides multiple triggers on the command line, e.g. "litescope_cli -v basesoc_cpu_mem_axi_aw_payload_addr 0x80000000 -r basesoc_cpu_mem_axi_w_valid"

23:01 <somlo> but then I get this:

23:01 <somlo> Exact: basesoc_cpu_mem_axi_w_valid

23:01 <somlo> Rising edge: basesoc_cpu_mem_axi_w_valid

23:01 <somlo> Condition: basesoc_cpu_mem_axi_aw_payload_addr == 0x80000000

23:01 <somlo> Exact: basesoc_cpu_mem_axi_aw_payload_addr

23:01 <somlo> Exact: basesoc_cpu_mem_axi_aw_payload_addr

23:01 <somlo> [running]...

23:03 <somlo> which even though confusing (the Exact lines are from the Finder, so ultimately it's right) -- results in a trace that doesn't *start* with all those conditions true

23:04 <somlo> I have a few clock cycles, then aw_payload_addr goes to 8000_0000, then a bunch of clock cycles later, when aw_payload_addr goes to some *other* value, I end up with w_valid going high

23:04 <somlo> so, the question is, are the criteria supposed to be exact, or is there some window of wiggle room between when all listed conditions must be true?

23:09 <somlo> I have more questions like what's the relationship between litescope_cli's "--length" and the analyzer.depth argument built into LiteScopeAnalyzer on the SoC side of things?

23:11 <somlo> and maybe a slightly more detailed explanation (man page) for some of the less obvious arguments of litescope_cli, e.g.: "--group", "--subsampling", "--offset", and last but not least, "--length"

23:13 <somlo> anyhow, I think I'll just open an issue against litescope, because if you're going to spend the effort of answering any of these questions, it's better if we capture it there :)

23:15 <somlo> ok, found issue #21 on "sequence" vs. "and" & "or", so that explains why I don't get what I expect by providing multiple triggers on the command line :)

23:28 <somlo> _florent_: it's https://github.com/enjoy-digital/litescope/issues/29 (in addition to #21, to which I subscribed). So please answer there if/when you can, and sorry for the noise in this channel :)

23:59 <acathla> zyp, I used mem_write from the bios this time, to an uart address. It increments the address but it's ok for a simple test I guess