LiteScope: more help needed

[gsomlo]

Here's the patch I've applied to litex (latest upstream version, incl. all dependencies). Also shown are the commands I'm using to (attempt to) pull data out of the SoC with litescope_cli:

$ litex-boards/litex_boards/targets/digilent_nexys_video.py --build \
    --cpu-type rocket --cpu-variant linux \
    --cpu-num-cores 4 --cpu-mem-width 2 --sys-clk-freq 50e6 \     # or `--cpu-mem-width 1` if testing built-in up-converter
    --with-ethernet --with-sdcard --with-sata --sata-gen 1 \
    --with-jtagbone --csr-csv ./csr.csv
$ litex_server --jtag --jtag-config ./openocd_nexys_video.cfg
$ litescope_cli --csv ./analyzer.csv --csr-csv ./csr.csv \
    -v main_basesoc_rocket_l2fb_axi_aw_payload_addr 0x80000000

diff --git a/litex/soc/integration/soc.py b/litex/soc/integration/soc.py
index 17fe98f7..cd1dc03e 100644
--- a/litex/soc/integration/soc.py
+++ b/litex/soc/integration/soc.py
@@ -30,6 +30,7 @@ from litex.soc.interconnect import stream
 from litex.soc.interconnect import wishbone
 from litex.soc.interconnect import axi
 
+from litescope import LiteScopeAnalyzer
 
 # Helpers ------------------------------------------------------------------------------------------
 
@@ -1632,6 +1633,7 @@ class LiteXSoC(SoC):
                             port         = port,
                             base_address = self.bus.regions["main_ram"].origin
                         )
+                        self.dut_axi = mem_bus
                     # UpConvert.
                     elif data_width_ratio > 1:
                         axi_port = axi.AXIInterface(
@@ -1647,6 +1649,7 @@ class LiteXSoC(SoC):
                             port         = port,
                             base_address = self.bus.regions["main_ram"].origin
                         )
+                        self.dut_axi = axi_port
                     # DownConvert. FIXME: Pass through Wishbone for now, create/use native AXI converter.
                     else:
                         mem_wb  = wishbone.Interface(
@@ -1677,6 +1680,18 @@ class LiteXSoC(SoC):
                     else:
                         raise NotImplementedError
 
+        # set up LiteScope:
+        analyzer_signals = [
+            self.cpu.l2fb_axi.aw, self.cpu.l2fb_axi.w, self.cpu.l2fb_axi.b,
+            self.cpu.l2fb_axi.ar, self.cpu.l2fb_axi.r,
+            self.dut_axi.aw, self.dut_axi.w, self.dut_axi.b,
+            self.dut_axi.ar, self.dut_axi.r,
+        ]
+        self.submodules.analyzer = LiteScopeAnalyzer(analyzer_signals,
+            depth = 64,
+            clock_domain = "sys",
+            csr_csv = "analyzer.csv")
+
         # Connect Main bus to LiteDRAM (with optional L2 Cache) ------------------------------------
         connect_main_bus_to_dram = (
             # No memory buses.

Once it's all set up, and litescope_cli says [running], I issue the following command at the LiteX bios prompt:

litex> sata_sec2mem 1000000 0x80000000

and nothing happens. I'd expect the address to be written over the axi aw channel as the DMA master (LiteSATA) is pushing data through the Rocket chip.

Any hint as to why the actual 0x80000000 address would not be expected to show up literally over the AXI aw channel, and how else I should be looking for it as part of a trigger expression much appreciated!

@enjoy-digital @Dolu1990 -- you're my most likely source of ideas, but if anyone else has a clue, please help :)

[AndrewD]

What is your trigger condition for litescope_cli: the aw channel matching the full address?

Maybe add a control signal too and trigger on that?

[gsomlo]

On Thu, Jan 04, 2024 at 05:34:26PM -0800, AndrewD wrote:

What is your trigger condition for litescope_cli: the aw channel matching the full address?

Yes.

Maybe add a control signal too and trigger on that?

Assuming that specifying additional triggers implies an "AND", why would additional restrictions improve my chances of triggering the data collection?

Triggering on just -r main_basesoc_rocket_l2fb_axi_aw_valid successfully triggers data collection as soon as I transfer a sector to RAM, but the address and data fields in the axi channels look like unrecognizable garbage...

[gsomlo]

Here's what I get when I trigger on a combination of values and control signals:

litescope_cli --csv ./analyzer.csv --csr-csv ./csr.csv \
  -v main_basesoc_rocket_mem_axi_aw_payload_addr 0x80000000 \
  -r main_basesoc_rocket_mem_axi_aw_valid \
  -r main_basesoc_rocket_mem_axi_aw_ready

Weirdly enough, payload_addr is nowhere near 0x80000000, so I'm not quite sure what's going on :)

[gsomlo]

hmm, I always assumed multiple triggers on the same command line are AND-ed together, but maybe they're OR-ed instead, which would explain why I'm getting garbage in the address field ?

@enjoy-digital -- can you clarify ? :)

[gsomlo]

For completeness, I ran:

./litescope_cli --csv ./analyzer.csv --csr-csv ./csr.csv -v main_basesoc_rocket_mem_axi_aw_payload_addr 0x80000000

without any additional (OR-ed or AND-ed) triggers, and got this:

The address is not 0x80000000 when trig goes high, and at some point (much) later, when it is 0x80000000, valid and ready are not both high...

Am I reading this wrong?

(also, main_basesoc_rocket_l2fb_axi_aw_payload_addr is never 0x80000000, since if I use that, the capture never triggers, as per one of my earlier posts in this thread)