02:47 <scanakci> _florent_: I guess I am done with the necessary changes to fix the issue that we discussed. I will probably let you know tomorrow. Do you mind having a separate branch for blackparrot? I think it is the easiest way for final integration, too. I can also create a separate repo.

03:27 <scanakci> ls

09:09 <_florent_> scanakci: good for the simulation changes, a separate branch or repo would be fine yes

17:30 <cansu> Hello @somlo, I have another question. I was checking wishbone-axi interface in rocket core and as far as I understood, in core.py file, two interfaces for axi(64 bit), two interfaces for wishbone(64bit) are defined and then converted to each other by using AXI2WB and then downconverted to 32 bit ibus and dbus wishbone interfaces. What I could not understand is where the data is coming to mem_axi and mmio_axi. I could not

17:30 <cansu> see how it is connected to L1 and MMIO in rocket and how you get information for ibus and dbus. If you can explain briefly or send me the file where this connection is made, I would really appreciate. Thanks in advance.

17:31 <somlo> cansu: most other (32bit) CPU models in LiteX don't have L1 cache, and have separate wishbone ports for instruction vs. data accesses

17:31 <somlo> hence "ibus" and "dbus"

17:32 <somlo> they're both masters on the wishbone bus, and whichever the CPU happens to use, it will write or read data over the bus

17:33 <somlo> data which then gets routed to a CSR (mmio register), sram, bootrom, or main_ram, depending on the address

17:33 <somlo> ok, now on to Rocket -- which has an "on-board" L1 cache, and internal routing of read/write accesses

17:34 <somlo> you build Rocket with hard-coded MMIO and RAM address ranges, when generating the verilog (in the rocket/verilog litex submodule)

17:34 <somlo> these ranges should match what LiteX has specified in rocket/core.py (or else things can't work)

17:35 <somlo> If a read/write access to an MMIO address (as per rocket's internal routing map) occurs, it will come out over the mmio_axi port

17:35 <somlo> if it's to/from a RAM range, the mem_axi port will be used instead

17:36 <somlo> doesn't matter, both end up being converted to 32-bit wishbone, and wired into ibus and dbus (again, doesn't matter, they're both masters on the wb bus)

17:36 <somlo> so ibus and dbus are "misnomers" as far as rocket is concerned, it's just that litex is coded to expect those two and add them to the masters list on the wishbone interconnect

17:37 <somlo> so I think mem_axi is converted to 64bit wb, then to 32bit wb, then connected to the bus as the "ibus" master port

17:37 <somlo> mmio_axi is undergoing a similar conversion to 32bit wb, and ends up as the "dbus" wb master

17:39 <somlo> now, with the latest litex commit from yesterday (b627a8fe), the *only* thing being accessed over mem_axi is actual RAM starting at 0x8000_0000, everything else goes over mmio_axi

17:41 <somlo> which means my next step is to decouple Rocket's mem_axi port and LiteDRAM's data port from the wishbone bus, and just hook them up to each other, point-to-point, at native 64bit axi

17:41 <somlo> which should hopefully improve memory bandwidth significantly.

17:42 <somlo> cansu: how many axi ports does your CPU have?

17:46 <somlo> cansu: hope that all makes sense, if not let me know and I can elaborate on whichever bits were too vague :)

17:50 <somlo> cansu: here's a picture :) https://pastebin.com/8bWCnWR5

19:22 <cansu> @somlo Our CPU does not have any AXI ports yet and we are considering to make a connection from MEM-CCE interface to Wishbone, just for LiteX integration. I am just trying to figure out how things are working in Rocket. I will check your explanation and get back to you very soon. Thank you very much for your time and for the detailed explanation!

19:29 <somlo> cansu: if all (instruction and data) accesses are done over a single wishbone port, you won't have to worry about axi, conversion, or routing

19:30 <somlo> you may have to down-convert wishbone to 32-bit (if yours will be 64 natively)

19:31 <somlo> then you need to connect either ibus or dbus to the 32-bit master side of your cpu-facing wishbone port

19:32 <somlo> not sure what happens if one of them (ibus or dbus) is 'None' right now, but I'm thinking of adding a check for that as a patch

19:32 <somlo> because I will also only have one to connect to the wishbone bus...

19:33 <somlo> once I bypass wb for the cpu-to-litedram datapath, that is

19:45 <_florent_> somlo: this should simplify things:

19:45 <_florent_> https://github.com/enjoy-digital/litex/commit/1045cda39e63b3bfcf1d24d26dbc15837e25d9e3

19:45 <tpb> Title: cpu: add buses list and use it in soc_core to add bus masters · enjoy-digital/litex@1045cda · GitHub (at github.com)

19:45 <_florent_> https://github.com/enjoy-digital/litex/commit/467d35edee9fd95ab7527a822f1300ebae75211c

19:45 <tpb> Title: cpu/rocket: rename ibus/dbus to mem_wb/mmio_wb and add size suffix · enjoy-digital/litex@467d35e · GitHub (at github.com)

19:53 <somlo> _florent_: thanks, that makes it simple and straightforward; also for cansu if the new cpu only comes with a single, universal wishbone port!

19:55 <_florent_> yes and in the future we would even allow buses to be wb or axi and non-32-bit and do the adaptation directly in the SoC

21:35 <scanakci> __florent_: The branch is ready to be pushed. I guess you need to add me as a contributor before I push the branch.

21:56 <scanakci> I added an environment variable (FILE_LIST_PATH) to the "litex/build/sim/core/Makefile" file to specify the filelist. Verilator accepts this file with -f. I think it may be good to add another function which specify the path of filelist instead of specifying folder path (i.e. add_source_dir).