04:36 <xobs> Thanks for that, _florent_ . And because of the `fields` support of CSRs, I can make a non-breaking change to the USB stack and the control bits remain the same: http://rm.fomu.im/usb.html#usb-out-ctrl

04:36 <tpb> Title: USB LiteX SoC Project documentation (at rm.fomu.im)

04:37 <xobs> (bit 0 used to be "advance the fifo")

05:27 <xobs> Is there any advantage to using a CSRConstant versus a CSRStatus? Easier to meet timing, lower resource usage, something like that?

05:29 <xobs> I just tried to move from using CSRStatus to CSRConstant, and the resource usage went up slightly.

05:45 <_florent_> xobs: If CSRStatus is connected to a constant value, i would expect logic resource to be very similar between CSRConstant vs CSRStatus, i would need to check why CSRConstant seems to use a bit more resource

05:46 <xobs> _florent_: It's negligible. Probably just lost in the noise. But that's nice to know that it should be almost the same.

05:49 <_florent_> xobs: btw, to support we signal on CSRStatus, i had to rework the Wishbone 2 CSR bridge (to be sure read accesses are only valid one cycle) and also made it asynchronous (to reduce latency/simplify the code). I tested on a Xilinx design and it seemed to be fine for resource usage/timings, have you noticed a difference on foboot?

05:49 <xobs> _florent_: I haven't tried it on real hardware yet, but I will try it soon.

10:30 <keesj> I am getting started again (installed the xilinx vivado stuff) and used the setup_litex.py to setup the system. I want to test litesdcard and was able to generate the bit stream. but running ./arty.py load in the examples directory returns [loading]...

10:30 <keesj> /bin/sh: 1: source: not found

10:30 <keesj> and && vivado tcl not found . I think the lines might be bash specific

10:37 <keesj> yes.. if I reconfigure bash as main shell (dpkg-reconfigure dash and select no ) it works

10:38 <keesj> "works" is ERROR: [Labtoolstcl 44-469] There is no current hw_target.

10:38 <keesj> (need to udev I think)

11:56 <_florent_> keesj: yes that's probably related to udev

18:43 <scanakci> Hi all, I am a 4th-year grad student from Boston University and recently started a project that involves Litex. So far, I had the chance to read a bunch of documents from both litex and litex-buildenv repos and also spent some time to have a basic understanding of code hierarchy in litex.

18:43 <scanakci> As a first step, we would like to have a minimal version of this SoC and simulate it. I will appreciate if you could give some directions related to this. I have some questions before diving into the project, please bear with me for nonsense or meaningless questions.

18:43 <scanakci> I and my collaborator (@cansu) will try to integrate a recent 64-bit RISC-V based CPU (https://github.com/black-parrot/pre-alpha-release) into the Litex environment. The final goal is to have an SoC running Linux as firmware on FPGA.

18:43 <scanakci> Q1) I can see two options, one is using litex repo and the second is using the litex-buildenv repo. Litex-buildenv seems including more tools in terms of debugging. Should I use litex-buildenv as a beginner in the Litex, or using Litex is more meaningful for any reason?

18:43 <scanakci> Q2) For debugging minimal SoC version, I can see two directions so far. In litex repo, there is litex_sim.py in tools (https://osda.gitlab.io/19/1.1-slides.pdf) and Litex Server, Litex Scope. Another option is using QEMU, Renode from litex-buildenv.

18:43 <scanakci> a. So far, I could not see any documentation related to litex_sim, Litex Server or Litex Scop. Are there documents describing the usage of these tools other than --help? For instance, I tried ./litex_sim.py --output-dir $PWD/simout --cpu-type vexriscv --cpu-variant minimal+debug and ended up having a console with some available commands but I do not know how to go further and what to look for in simout folder. I do not

18:43 <scanakci> have much experience debugging hardware other than using ISE or similar simulation tools, that may be the reason.

18:44 <scanakci> b. In general, which debugging tool would be a better choice? QEMU, Renode, litex_sim or maybe something else?

18:44 <scanakci> Q3) By looking at litex GitHub repo, I can see that we need another folder under soc/cores/cpu/ for the new core and write a core.py to describe this core. It also looks like that we need to include HDL source in the verilog folder. Besides these, are there specific folders, files that you would suggest me to look at? Which ones might be potentially changed for integrating a new core?

18:44 <tpb> Title: GitHub - black-parrot/pre-alpha-release: Black Parrot is coming soon. (at github.com)

18:44 <scanakci> Sorry for the long message.

18:57 <somlo> scanakci: check out https://github.com/enjoy-digital/litex/tree/master/litex/soc/cores/cpu/rocket for existing 64bit RISC-V support (see http://www.contrib.andrew.cmu.edu/~somlo/BTCP for the "runs 64bit linux" part)

18:57 <tpb> Title: litex/litex/soc/cores/cpu/rocket at master · enjoy-digital/litex · GitHub (at github.com)

18:59 <somlo> It should hopefully not be too hard to replace the rocket-chip with black-parrot for your project

19:02 <_florent_> scanakci: hi and welcome!

19:02 <_florent_> for the documentation, you can look at litex-buildenv wiki, that's where you'll find the more documentation

19:04 <_florent_> it's true that documentation is the strong point of the project (we are trying to improve that), but you can generally find example by looking at the different examples/repositories

19:05 <_florent_> There is also https://github.com/litex-hub/fpga_101 that you could try to look at / do

19:05 <tpb> Title: GitHub - litex-hub/fpga_101: FPGA 101 lessons/labs (at github.com)

19:06 <_florent_> For the way to integrate your cpu, yes you'll have to create a cpu wrapper similar to the others CPU and the minimal software needed for it (search in software for __rocket__ define for example to understand what is needed for another CPU)

19:07 <_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)

19:09 <_florent_> litex_sim could be a good starting point for you, it uses verilator to simulate the whole SoC and allow you to interact with it at resonnable speed

19:09 <_florent_> this is also possible to generate a .vcd file with it and that's what will probably be very useful for you

19:10 <_florent_> you can enable tracing, but also select when you want to enable it : https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_sim.py#L204-L209

19:10 <tpb> Title: litex/litex_sim.py at master · enjoy-digital/litex · GitHub (at github.com)

19:11 <_florent_> So this would easily allow you to simulate the SoC, load the ROM and see how it start behaving

19:12 <_florent_> For example, that's what i used when starting working on https://github.com/litex-hub/linux-on-litex-vexriscv and integrate correctly VexRiscv

19:12 <tpb> Title: GitHub - litex-hub/linux-on-litex-vexriscv: Linux on LiteX-VexRiscv (at github.com)

19:13 <_florent_> now for litex-buildenv vs litex, litex-buildenv will mostly provide scripts/packages to ease installing things and build software, but if you already have litex installed, you can just use that

19:16 <_florent_> i just saw that black-parrot is in verilog, so litex_sim would work (verilator)

19:20 <_florent_> also for QEMU/Renode, i would say it would be useful if you were doing the opposite: doing your own peripheral connected to a RISC-V CPU. Here that's the CPU you want to debug, the litex_sim approach seems more appropriate

19:42 <sorear> oh neat, forgot there was stuff going on at BU

21:03 <scanakci> _florent_ & somio: thank you so much for the answers! glad to be here!

23:04 <futarisIRCcloud> scanakci: Sounds like a great project. There's generally always someone here that can answer your litex questions, and if you're lucky, they're in the same timezone as you. Otherwise, check the logs in a day or two, https://logs.timvideos.us/%23litex/latest.log.html ...