*** tpb has joined #litex | 00:00 | |
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. | 02:47 |
---|---|---|
*** y2kbugger has joined #litex | 03:07 | |
scanakci | ls | 03:27 |
*** forksand has quit IRC | 04:23 | |
*** forksand has joined #litex | 04:39 | |
*** forksand has quit IRC | 05:04 | |
*** CarlFK has quit IRC | 05:11 | |
*** forksand has joined #litex | 05:19 | |
_florent_ | scanakci: good for the simulation changes, a separate branch or repo would be fine yes | 09:09 |
*** _whitelogger has quit IRC | 10:27 | |
*** _whitelogger has joined #litex | 10:30 | |
*** CarlFK has joined #litex | 12:50 | |
*** y2kbugger has quit IRC | 13:57 | |
*** y2kbugger has joined #litex | 13:58 | |
*** y2kbugger has quit IRC | 14:55 | |
*** y2kbugger has joined #litex | 14:59 | |
*** y2kbugger has quit IRC | 15:04 | |
*** y2kbugger has joined #litex | 15:06 | |
*** CarlFK has quit IRC | 15:08 | |
*** forksand has quit IRC | 15:23 | |
*** forksand has joined #litex | 15:39 | |
*** CarlFK has joined #litex | 16:45 | |
*** acathla has quit IRC | 16:47 | |
*** y2kbugger has quit IRC | 16:57 | |
*** y2kbugger has joined #litex | 17:09 | |
*** acathla has joined #litex | 17:29 | |
*** cansu has joined #litex | 17:29 | |
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:30 |
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:32 |
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:33 |
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:35 |
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:36 |
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:38 |
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:39 |
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:41 |
somlo | cansu: how many axi ports does your CPU have? | 17:42 |
*** ambro718 has joined #litex | 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:46 |
somlo | cansu: here's a picture :) https://pastebin.com/8bWCnWR5 | 17:50 |
*** freemint has joined #litex | 17:56 | |
*** freemint has quit IRC | 18:15 | |
*** freemint has joined #litex | 18:23 | |
*** CarlFK has quit IRC | 18:30 | |
*** freemint has quit IRC | 18:35 | |
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:22 |
*** freemint has joined #litex | 19:24 | |
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:29 |
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:31 |
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:32 |
somlo | once I bypass wb for the cpu-to-litedram datapath, that is | 19:33 |
*** freemint has quit IRC | 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:46 |
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:46 |
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:54 |
*** freemint has joined #litex | 19:54 | |
_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 | 19:56 |
*** freemint has quit IRC | 20:00 | |
*** CarlFK has joined #litex | 20:29 | |
*** freemint has joined #litex | 21:27 | |
*** cansu has quit IRC | 21:30 | |
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:35 |
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). | 21:56 |
*** y2kbugger has quit IRC | 22:01 | |
*** y2kbugger has joined #litex | 22:06 | |
*** ambro718 has quit IRC | 23:00 | |
*** y2kbugger has quit IRC | 23:33 | |
*** y2kbugger has joined #litex | 23:34 | |
*** y2kbugger has quit IRC | 23:40 | |
*** y2kbugger has joined #litex | 23:43 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!