<nickoe>
on a real target, why can't I load the demo.bin with lxterm via jtag? I have self.add_jtagbone() in the target, I can get theident with litex_cli --ident etc. I can get traces with litescope via that litex_server, started via jtag
2021-04-29
<geertu>
_florent_: Cool! Thanks to litescope, you no longer need a real scope, so found a new use for it? ;^)
<thorns514>
every time I add a valenty usb core for debug bridge (instead of uart) with its 12mhz/48mhz clocks, the litescope_cli never waits for my cyc trigger, it just dumps immediately...
<thorns514>
is there a trick to getting litescope to trigger properly on a soc with multiple clock domains?
2021-04-10
<thorns514>
aha well I got my module working at least, even if I never figured out the litescope triggering problem
<_florent_>
thorns514: LiteScope indeed also needs the csr.csv to get the register mapping (analyzer.csv only provides the mapping of the analyzer signals)
<thorns514>
does the litescope cli/RemoteClient need the soc csr.csv (with all the CSR regs and memory map etc), in addition to the analyzer CSV with the tapped wires? it's complaining that the remote has no "regs", and it works if I rename the file that I saved my soc --csr-csv to as csr.csv (which the RemoteClient seems to default to) ...
<thorns514>
if I have a USB debug bridge working with a valenty DummyUsb core in my soc, verified with wishbone-tool, should I expect this also to work with litescope using lxserver?
<thorns514>
if I have a uart that I want to use to serialboot some firmware, and then reuse in lxserver to connect to litescope_cli, is this possible ?
2021-03-22
<keesj>
becase the litescope adds with_etherbone but I guess there must then be a similar options for taking over the serial as wishbone master
<keesj>
becase the litescope adds with_etherbone but I guess there must then be a similar options for taking over the serial as wishbone master
2021-03-12
<zyp>
I ran a rough comparison vs etherbone, it's a little bit slower -- 26.6 seconds to transfer a big litescope buffer over usb vs 19.7 seconds over etherbone
2021-03-11
<shorne>
I am doing litescope tracing, and have a paper tracing the hole sdcard wiring to understand which wires best to probe, its taken me some time.
2021-03-08
<_florent_>
zyp: sorry for the time you spent on that, I thought the core was already running in the eth clock domain. For info I found the issue by capturing the ethphy.source with LiteScope and saw some backpressure on the ready signal (that is not supposed to happen).
<_florent_>
shorne: Good you got jtagbone working, LiteScope will indeed use some blockrams, so this can be tricky on a design that is already already almost full
<shorne>
ok, now its building, time to try out litescope
<shorne>
changing the litescope sample depth doesnt seem to help
<shorne>
well, jtagbone is working, but having an issue getting litescope to route, my design needs 101 RAM cells, but the device as 100
2021-03-07
<zyp>
hmm, litescope is not getting a trigger on arp.rx.sink.valid
<zyp>
I was hoping to avoid having to set up another wishbone bridge to be able to use litescope :)
<_florent_>
zyp: ok, I really think this is related to the PHY or reset sequence. That would be interesting to add LiteScope on the PHY source/sink and compare with frames on the Host with Wireshark
<_florent_>
zyp: Eventually with LiteScope
<_florent_>
Another option could be to use LiteScope over JTAG
<shorne_>
Hello, On my arty board I switched on etherbone to try to use litescope
2021-03-03
<shorne_>
_florent_: thanks, I was reading *a* page on litescope, but I think your link is much more detailed
<_florent_>
nickoe: with --with-analyzer, you have to use litex_server and litescope_cli to get your dump:
<_florent_>
nickoe: I would first recomment starting from litex_sim and the Litescope tutorial at: https://github.com/enjoy-digital/litex/wiki/Use-LiteScope-To-Debug-A-SoC (and make sure you reproduce the results), then adapt this to your own needs. This will give you a starting point that you can progressively adapt.
2021-02-27
<yootis>
Is there an easy way to generate verilog of litescope and the UART interface so I can insert it into a verilog-only design?
2021-02-19
<_florent_>
tmbinc: scope is a good name yes (we could still change it later if we found a better name), litex-scope would also have been a good name but is maybe too close to LiteScope so will be confusing, so scope is probably better
<_florent_>
tmbinc: this how pre-trigger is implemented in LiteScope (but with a BlockRAM FIFO). I'm also realizing that working on this will also be useful to use a LiteDRAM FIFO with LiteScope :) (wanted to work on this for some time now).
<_florent_>
somlo: otherwise for the SDCard issue under Linux, we could create an issue for that (eventually in linux-on-litex-rocket if easier for you), with steps to reproduce and eventual Litescope debug code, this can allow us to converge faster.
2021-02-04
<somlo>
in that case, I should try *adopting* it (I am using two-day-old versions of litex_[server|client|term] and litescope_client)
2021-02-02
<_florent_>
run Litescope over the uartbone to capture the write/read accesses from the JTAG
<_florent_>
for bringing this up, I would recommend using a design with a SoC and both uartbone and jtagbone bridge with Litescope on the JTAG signals
<_florent_>
somlo: also litescope will be stressing the link a bit, that's a bit ambitious for a first test :) I would first test with simple accesses to the scratch register (eventually with litex_client --read/--write/--regs)
<somlo>
daveshah: same behavior with the explicitly negated signal -- I'm going to assume it was OK with the original syntax, and dig elsewhere for why the vcd isn't getting downloaded from litescope_cli...
<somlo>
running litescope_cli gets stuck "downloading" the vcd file
2021-01-28
<somlo>
_florent_: not sure how litescope would help, but I tried `mem_read` and `mem_write` from the litex bios prompt
<_florent_>
somlo: strange, this would need to be investigated... A good use case for Litescope now that you are familiar with it :)
<_florent_>
somlo: if litescope_cli works, this should also works
<somlo>
_florent_: so I tried using my jtag_bone enabled rocket SoC (on nexys4ddr), with the litex_server (same setup that works with litescope_cli)
<_florent_>
acathla: Litescope is nice for things that are difficult to simulate but here I would look at this in simulation
2021-01-27
<zyp>
acathla, can you try adding bus_interconnect also to the litescope capture?
<somlo>
_florent_: litescope is awesome, and I love that I know how to use it now (thanks again for that, btw). But I just came to realize I actually need to understand the LiteSDCard (and DMA) FSMs, to even stand a chance of figuring out why they're misbehaving (and only under Linux, not in the bios)...
<somlo>
_florent_: fwiw, jtagbone and litescope work -- it's that the soc was internally renamed from "basesoc" to just "soc", so the names of the signals I was passing into the client were wrong
<somlo>
but my old litescope_cli command line: `litescope_cli -v basesoc_cpu_mem_axi_aw_payload_addr 0x80000000 -r basesoc_cpu_mem_axi_w_valid`
2021-01-25
<_florent_>
litescope_cll
<acathla>
How can I connect a litex_server to a litex_sim ? Through ethernet only? I added --with-analyzer to use litescope_cli.
2021-01-24
<_florent_>
cr1901_modern: thanks, I was in fact also aware of this one :) but I'm not sure it's CDC related here and only happens when sending characters while doing the reset. I have an OrangeCrab design with LiteScope in place that I could use to have a closer look at this, will do that tomorrow.
2021-01-22
<somlo>
_florent_: thanks, building ok again :) Is the idea to go back to using the "normal" uart for console and do litescope over JTAG?
2021-01-20
<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 :)
<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"
<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?
<somlo>
_florent_: in litescope_cli, can you combine trigger criteria, such as "-r sig_1 AND -v sig2 0x80000000" ?
<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
<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.
<somlo>
_florent_, cr1901_modern: I managed to build and test litescope via the "normal" uart (with console tunneled over jtag)
<acathla>
zyp, with a capture with LiteScope
<_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.
<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*
2021-01-19
<somlo>
but so far so good, I now have an open UART to try to use for litescope.
<somlo>
otherwise looks like it's working OK, now on to bridging litescope over the "regular" uart
<somlo_>
I'm supposed to use console-over-jtag to free up my "regular" uart for litescope debugging
<somlo_>
ethernet works great (for litescope) on the nexys, but that in turn means I can't netboot the kernel, which means I have to screw around moving the microSD card back and forth between the board and my laptop to update the kernel+bbl I'm trying to boot and debug, in conjunction with the bitstream/gateware I'm *also* trying to debug at the same time :)
<somlo_>
oh wait, do I already have two serial devices in play over the same serial cable (the jtag used to program the board, and the "regular" serial console uart)? And here I'd be re-using the jtag for actual console i/o, and the "normal" serial uart for litescope purposes?
<somlo_>
so that would be multiplexing the console and litescope data over the same serial link?
<somlo_>
i.e., will there be an additional /dev/ttyUSBXYZ device for litescope debugging, or (probably this, since you already mentioned multiplexing) it's all multiplexed over the same serial link (console *and* litescope transfers) ?
<acathla>
_florent_, right, but can you run litex_term while litescope is running, on the same uart with crossover?
<_florent_>
somlo_: sure :), also if that can be useful: LiteScope can also be run over UART
<somlo_>
it's just that I have a lot of moving parts (bitstream changes x kernel sdcard driver changes) and not having netboot capabilities leads to lots of plugging and unplugging of the sdcard to copy updated boot.bin images to it... Wanted to streamline my workflow before I really dive in and test my new-found skills with litescope :D
<somlo_>
_florent_: I'll check out the hybrid mode (one already has to modify the target files to instrument them for litescope, so a bit more hackery while at it should be ok)
<somlo_>
I'll order a pmod and do some hacking, should make for a much less painful litescope debugging experience...
2021-01-18
<acathla>
hansfbaier, yes. The Wiki says: Note: LiteScope also accepts Migen's Records, but it gives me an error when I try : TypeError: object of type 'UART' has no len()
<acathla>
How do I captures signals with LiteScope that are in submodules from the main soc module ? And all those signals that are not self.something ? Since it's all flat in the end in Verilog those should all be accessible.
2021-01-16
<somlo>
_florent_: got litescope working with the actual fpga board \o/
2021-01-15
<somlo>
_florent_: I think I managed to hook up litex_sim, litex_server, and litescope_cli, and to trigger a capture based on the rising edge of a signal.
<_florent_>
somlo: as we already discussed by mail, LiteScope can also be very powerful to develop/debug Linux drivers! You should really try it :)
2021-01-13
<_florent_>
at least, I think you would have a better visibility by including a LiteScope module or outputing some signals to a scope, this would also be very useful to understand how things are working
2021-01-08
<oter>
yoseng I cut/pasted the relevant bits of a LiteDRAMDMAReader example here: https://pastebin.com/Y6cuUAcJ. The bus width etc. (where not generic) are for the ECPIC-5 Lattice board (sorry, don't have yours). It's super naive, but helped me learn. As _florent_ pointed out, love using Litescope to see what's going on. Trigger the example DMA read sequence via a write to the CRG called "output". Any other trigger (button?) would do too.
<_florent_>
You could also use a larger FPGA board (Arty for example) with your design + LiteScope to analyze the transfers on the wishbone bus
2020-12-16
<joseng>
Am I right in the assumption that the async FIFOs in migen are First Word Fall Through (by default)? Seems to from my tests with it and and watch the output with litescope
<joseng>
Ok, newby error. I ran litescope_cli in the wrong folder, where it found the analyzer.csv from the simulator and not in the build folder where the correct file from the SoC is....
<joseng>
Only litescope_cli does not come back from "[running]"
<joseng>
_florent_ After starting the litex_server again several times, now litex_cli --ident works and also litescope_cli runs successful
<joseng>
Then I wanted to run the litex_sim as in the litescope wiki page, but when I run this with "litex_sim --with-etherbone --with-analyzer" and then "litex_server --udp --udp-ip=192.168.10.113" (ip of my ubuntu VM), I get a timeout from litex_server
<joseng>
Hi all, can someone give me a hint how to get the litex_server/litex_sim and litescope_cli working? First I tried to put in the UARTWishboneBridge in my SoC and start the litex_server over uart and then just run the litescope_cli in another terminal window, but I get a timeout when uploading/starting (I see the connection from litescope_cli in the
2020-11-10
<promach3>
Is it technically feasible to use litescope to check litedram signals using usb on orangecrab ?
<_florent_>
dkozel: it's possible to use Chipscope on LiteX design, but you'll have to use the generated names in the verilog. On LiteX designs, it's generally easier to use LiteScope, but in some specific cases i'm also using Chipscope
2020-07-20
<_florent_>
zyp: interesting for your VFIO work. That would be interesting to add Litescope on the DMA Writer/Reader to see what is going on. I suspect the DMA Reader get stuck by issuing read requests but don't get the completion if the IOMMU is unmapped. If this is what is happening, we could add a register to be flush all the pending read requests restart from a clean state.
2020-07-11
<zyp>
the way I see it, while integrating a nmigen core by treating it as a black box is easy, it has some disadvantages like not being able to easily hook up litescope to internal signals
2020-06-30
<zyp>
yeah, litescope puts everything behind a set of CSRs
<lf>
ah i have not read how litescope transfers date. but if that is behinde one address then yes that should give big bust
<zyp>
the slow part of using litescope is dumping the capture buffer after the capture is finished
<zyp>
help what? it'd help for litescope
<zyp>
although litescope shouldn't need that when dumping the buffer, so the protocol could be extended to add a «read address A N times»
<lf>
i would need to look into litescop but maybe there is a way to change the reading behavier to get less overhead when reading or optimies it more for this buffering behevier
<zyp>
I've found that one of my usb-uart adapters takes like 10x longer to transfer a litescope buffer than another, because it's using a buffering strategy optimized for throughput rather than latency, or something like that
2020-06-14
<ronyrus>
I'm using liteScope to sample the signals.
2020-05-22
<zyp>
if I take out the cpu and the litescope from my build, I'm at 1191 TRELLIS_SLICE, and if my understanding is correct, each of those are comparable to two LCs
2020-05-19
<oter_>
Had great fun and learnt a lot following and adapting examples and diving deep using the LiteScope - ergo trying the same for main_ram access now.
<oter_>
Hi zyp, I have a module that reads/writes to UDP packets (based on LiteEthTTYRX/TX, not via CPU) and would like to access the DDR3 RAM on my versa_ecp5 board (again, not via code on the CPU). Ideally reading/writing 32 bit RAM values. Love that I can peek and poke via the wishbone-tool and use the LiteScope for debugging; but for the main task, I'm mostly trying to build a eth-connected accelerator and use the Lite* parts w/o code on the
2020-05-04
<_florent_>
also, if you just want to see how the CPU starts, no need to use the UART, so i could just use LiteScope over UART?
<benh>
how easy is litescope to use ? :-)
<_florent_>
benh: do you want i prepare a design for the Arty (IIRC that's the board you are using) with LiteScope on the Microwatt interface and replace the ROM with a SRAM you could reload easily? This would give you a lot more visibility
2020-04-30
<zyp>
(I'm using the uart port of a blackmagic probe, because the ftdi adapters I've got got so much latency that dumping the litescope buffer gets super slow)
<xobs>
It may be that litescope requires streamed writes. I haven't looked.
<zyp>
xobs, at some point I'd have to ask for your help to look into why litescope doesn't work properly via wishbone-tool (but does via litex_server)
2020-04-29
<shuffle2>
i guess i need to setup this litescope thing over uart to try and figure out what's wrong? :(
2020-04-20
<_florent_>
zyp: not sure we have numbers for LiteScope over Wishbone Bridge, but it's indeed a bit slow and there is a bottleneck that needs to be investigated. I could have a look, but using Etherbone will indeed be a lot faster.
2020-04-19
<zyp>
does anybody happen to have any numbers on wishbone bridge performance? I'm currently using litescope with the uart bridge and I'm getting impatient every time I make a capture, waiting for it to transfer
2020-04-06
<zyp>
I'm also looking forward until ethernet works more stable on the colorlight board, I guess it'll be a lot faster to dump the litescope buffer over etherbone rather than the uart bridge :)
<_florent_>
zyp: litex_server is probably slower and has less features than wishbone-tool, but that's what i'd recommend at first for LiteScope if you don't need specific features from wishbone tool. I've only used wishbone-tool for the specific cases that were not possible with litex_server (ex UART in Crossover mode over Etherbone) and it was working great, but i haven't tested personally LiteScope with it.
<zyp>
I'm having some problems getting litescope to work via wishbone-tool - works fine via litex_server.py
2020-01-22
<_florent_>
acathla: ok thanks, can you create an issue on LiteScope repo for that?
<xobs>
_florent_: I was getting ready to use litescope, and I found an issue in wishbone-tool where it doesn't support transfers with more than one word. So that's another yak to shave! But that's really a thing I should have already fixed.
<xobs>
florent (or anyone else): have you ever encountered an issue where the UART rx IRQ gets stuck? I'm trying to get litescope working so I can get a better idea of why...
2019-09-25
<_florent_>
For the debug, LiteScope is mostly useful for debug on hardware, but for your project you should be able to do almost everything in simulation, so i'm not sure you need it (at least now)