<cansu>
Hi, as @scanakci mentioned, we are trying to integrate Black Parrot CPU into Litex. Black Parrot will use AXI as bus protocol and I just wanted to be sure that my understanding is correct. @gsomlo, In Rocket, you have adapted Wishbone to AXI and there already exists an interface between those two, right? I assume with some minor modifications, we can make the connection between Black parrot and Wishbone without the
<cansu>
need of a new shim. I would appreciate if you can correct me if I am wrong. Thanks in advance!
<cansu>
Sorry for the typo @somlo
<sorear>
how much public information on the plans for black parrot are there
<scanakci>
I and Cansu recently started looking into that. Other than github repo, there are short workshop papers, and presentations about it.
<scanakci>
currently, we are not working on hardware development. My labmates were working on it till some point. We collaborate with University of Washington to add LiteX support.
<sorear>
I’m very curious about what your plans are to become compellingly better than Rocket
<scanakci>
sorear: I really do not have much background neither on Rocket nor Blackparrot to answer that.
<somlo>
right now, Litex's main system bus is 32-bit wishbone, so rocket's core.py adds a 64bit AXI-to-wishbone, and a 64-to-32bit wishbone down-converter to *both* of Rocket's axi interfaces, before connecting them to the wishbone bus as masters
<somlo>
that's a bit suboptimal, as Rocket does its own internal routing: cached ram accesses over a mem-AXI, and MMIO accesses over a second mmio-AXI interface
<somlo>
does Black Parrot's verilog interface provide more than one AXI master interface?
<somlo>
you should start by connecting them all to the LiteX 32-bit wishbone as masters, similarly to how Rocket is doing it right now
<somlo>
In the mean time, I'm trying to find the cycles to connect cached RAM directly to LiteDRAM's data via a dedicated, native-AXI link
<somlo>
leaving just MMIO accesses via the 64-to-32 axi->wishbone downshifter
<somlo>
but you should not need to do that during your first pass, better to keep things simple until you get something working
<cansu>
somlo: Thanks a lot! Black Parrot’s verilog interface is under development. We will probably have a better idea in the next 2 weeks how their AXI will look like.
<somlo>
sorear: w/o being familiar with Black Parrot (or Ariane, for that matter), I like the idea of something written natively in Verilog, whether it beats rocket in performance or not :)
<sorear>
hmm, if there are (a) BU people (b) with significant technical and planning knoledge of BlackParrot around I’d like to get to know them
<sorear>
somlo: depressing but valid, rip vscale
<scanakci>
somlo: Thank you so much. I have a separate question than this. Did you simulate Linux on Rocket Core using Litex? I read your blog about FPGA implementation but could not see something similar to linux-on-vexriscv Litex repo.
<scanakci>
I can simulate BIOS using litex_sim using any of the variants. I was curious if went further than BIOS on simulation
<somlo>
scanakci: I used the litex built-in (verilator-based) simulator to get rocket all the way into loading the bios
<somlo>
litex/litex/tools/litex_sim.py --with-ethernet --with-sdram --cpu-type rocket --cpu-variant linux
<somlo>
I did try to load linux from there (had to pre-load the memory with --ram-init something.bin, waiting for verilator to simulate the ethernet interface was too slow)
<scanakci>
I see. Do you think that it is better for me to switch to FPGA after coming to this point(loading the bios) or booting up the linux in the same simulation environment?
<somlo>
and it takes a looong time to actually boot linux on a 64-bit simulated chip, but you do get to see it happen
<scanakci>
I see, thank you. I will probably go on with FPGA once we come to the loading the bios point
<somlo>
I'd go as far as making sure I'm seeing the kernel print out things to the console, or at least get the simulator to prove you're executing early boot code, before switching to an fpga
<scanakci>
Sure. Currently, where do you store the BIOS in Litex environment?
<scanakci>
is it in SRAM since you launch the simulator wiith that option?
<somlo>
I think the bios is always in SRAM, whether simulated or part of an fpga bitstream image
freemint has quit [Ping timeout: 245 seconds]
CarlFK has quit [Read error: No route to host]
CarlFK has joined #litex
Samreen has joined #litex
Samreen has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 276 seconds]
rohitksingh has joined #litex
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
CarlFK has quit [Ping timeout: 240 seconds]
CarlFK has joined #litex
<acathla>
Ok, I'm lost. What's the best practice with litex? Where do I put my own code, how does it (python) finds it? How compatible an example from litex-buildenv can be with standalone litex?
<acathla>
I copied a tinyfpga_bx/base.py to litex/litex/boards/targets but it's still using litex from litex-buildenv/third_party/...
<_florent_>
acathla: i can explain you how to do things with standalone litex
<_florent_>
install migen, litex, the core with litex_setup.py:
<acathla>
I found (again) the sys.path changed, a clean shell helps
<_florent_>
so i think you have a conflict somewhere between versions
<acathla>
I removed everything in /usr/local/lib/python3.6/dist-packages/*, I had different versions of migen and... dust
<acathla>
now I have egg-links, and : File "simple.py", line 13, in <module>
<acathla>
ModuleNotFoundError: No module named 'litex'
<acathla>
from litex.soc.integration.soc_core import *
<acathla>
"
<_florent_>
you just removed everything and executed litex_setup.py init install?
<_florent_>
maybe add a sudo before python3 litex_setup.pu init install
<acathla>
I did. I had to do a sudo python3 setup.py install to add litex
<acathla>
And now I still have the AXI problem :(
rohitksingh has quit [Ping timeout: 252 seconds]
freemint has joined #litex
<acathla>
Ok, rm -Rfing everything...
<_florent_>
yes that's probably better, then use litex_setup.py script
<acathla>
Ok, I had old litex stuff probably installed by hand (git clone) a long time ago
<acathla>
Everything seems to be in place. So now, where's the best place to put my migen libs ? in litex-buildenv there is a gateware directory, should I use the "gen" directory?
<acathla>
there should be a library directory, arduino like (sorry), to easily add third party libs or your own
<_florent_>
in fact, now that it's installed, you just can execute the target in place, so you are free to choose how you want to organize things :)
<_florent_>
for example: create your own library with a setup.py
<_florent_>
or for simple project, just have your custom library files near your target
<_florent_>
or put that in a gateware directory as done in litex-buildenv
nrossi has quit [Read error: Connection reset by peer]
xobs has quit [Remote host closed the connection]
synaption[m] has quit [Remote host closed the connection]
john_k[m] has quit [Remote host closed the connection]
xobs has joined #litex
nrossi has joined #litex
synaption[m] has joined #litex
john_k[m] has joined #litex
freemint has quit [Ping timeout: 250 seconds]
<acathla>
_florent_, thank you, I progress. Now the vexriscv-lite does not want to be built by yosys :(
<_florent_>
ah, what's the issue? which board are you using?
<acathla>
tinyfpga_bx
<acathla>
old, but not too old, version of yosys works
<_florent_>
ok, the tinyfpga_bx does not have that much block ram memory, so it's possible you'll have to reduce ROM/SRAM sizes
<acathla>
Yosys from github says : "ERROR: multiple drivers on net 'CO' (carry.CO and $logic_or$/usr/local/bin/../share/yosys/ice40/cells_sim.v:145$1491.Y)"
<acathla>
(version Yosys 0.9+899 )
<daveshah>
You might need newer nextpnr
<daveshah>
There have been changes to the JSON format
<acathla>
_florent_, it's ok, after a crash because linux cannot handle correctly the lack of memory, everything seems to be built
<acathla>
LED is still not blinking but, gateware/firmware were built
forksand has joined #litex
cansu has quit [Quit: Connection closed for inactivity]
<_florent_>
acathla: good
forksand has quit [Ping timeout: 240 seconds]
freemint has quit [Ping timeout: 250 seconds]
forksand has joined #litex
<somlo>
\o/ -- my batch of TrellisBoards (https://github.com/daveshah1/TrellisBoard) just got delivered! As soon as I find a set of rubber "feet", it's off to getting litex+rocket running on an 85k ecp5 :)
<somlo>
daveshah: I'm assuming the power supply from the versa should work, not sure about what usb cable I should use for programming and serial console
<daveshah>
Make sure you put a jumper on the USB setting of J15, connect type C (start with type C not 12V)
<somlo>
hmm, add "type-c usb cable" to the list of things I need to procure before I can start having some fun... :)
<somlo>
daveshah: re. yosys PR 1425 & nextpnr PR 337, on the ecp5versa and litex+rocket
<somlo>
with yosys #c7f1368 and nextpnr #927077e I would usually get it to pass 60MHz in about 4-5 attempts (got above 55 on average), with "-abc9 -nowidelut" and the xc7dsp yosys patch applied on top of #c7f1368
<somlo>
yesterday I updated to yosys #da347b9 and nextpnr #cb8d90b, and only managed three runs this morning before I recompiled them both with PRs 1425 and 337, respectively. About the same area (98% TRELLIS_SLICE) as before, around 55MHz Fmax each run.
<somlo>
with both PRs applied, I'm getting about the same results (after two runs so far -- 98% area, 55-56 MHz Fmax)
<somlo>
I'll start my usual loop and see how long until I manage 60MHz, but it's not immediately different at first glance.
<somlo>
Not sure what else changed since (#c7f1368, #927077e) that would have any bearing on my results...
<daveshah>
Thanks for checking! The reduction might be more in number of BRAMs than in amount of logic, although perhaps not an issue for Rocket
<somlo>
I can re-run with vs. without the PRs and look at BRAMs (didn't occur to me to pay attention, since TRELLIS_SLICE is my constraining factor :)
<somlo>
daveshah: so, before the PRs I get 79% DP16KD, after (with) the PRs it goes down to 56%
<daveshah>
Not bad
<daveshah>
Good to see some improvement
<somlo>
30% (ish) reduction in utilization, that's totally worth writing home about :)
<somlo>
daveshah: oh, and quite hilariously, after I backed out of the PRs to get you the "before" numbers on DP16KD, that run went on to finish with a 62.01MHz Fmax :)
<somlo>
and just to be sure, I booted linux on it to see if it works (it does)...