tpb has joined #litex
keesj has quit [Ping timeout: 276 seconds]
keesj has joined #litex
CarlFK has joined #litex
CarlFK has quit [Read error: Connection reset by peer]
CarlFK has joined #litex
freeemint has quit [Ping timeout: 250 seconds]
tpb has quit [Disconnected by services]
tpb has joined #litex
CarlFK has quit [Ping timeout: 265 seconds]
freeemint has joined #litex
freeemint has quit [Ping timeout: 276 seconds]
freeemint has joined #litex
spacekookie has quit [Read error: Connection reset by peer]
spacekookie has joined #litex
CarlFK has joined #litex
CarlFK has quit [Quit: Leaving.]
<scanakci> I am having a lot of errors when trying to use litex_sim for blackparrot. Currently, I am writing the cpu wrapper for BlackParrot. While using add_sources in the, I can see that verilator is confused in terms of module, package hierarchy. In the log file (starting from line 16), you can see the errors. The first error is "syntax error, unexpected IDENTIFIER, expecting PACKAGE-IDENTIFIER" import bp_common_pkg::*;
<scanakci> Google tells me that the order of files is important for system verilog. I see these two links which makes me think that a specific file should be provided to Verilator to prevent the confusion.
<tpb> Title: ERROR on importing a pkg - Verilog-Perl - Veripool (at
<tpb> Title: Parse error with import name::* - Verilator - Veripool (at
<scanakci> Is there any way to tell litex_sim the order of files? There is -f flag in Verilator that may be useful I guess. I do not have any experience with Verilator, recently learning.
<scanakci> This is how my add_source look like:
<scanakci> I also looked at other cpus. In general, they have one or two verilog files. I guess similar problems did not happen for those cpus.
<xobs> apropos of nothing (thanks, Dolu!), to flush the data caches in vexriscv the command is `.word 0x500F`. This will come in handy when writing to XIP flash using the CSRs.
<_florent_> scanakci: i haven't used Verilator/litexsim a lot with system-verilog files, i think the way to get it to work to first execute litexsim, then modify the generated files manually to get it working and accepted with verilator and when working/understood, apply this changes back to litexsim
<_florent_> scanakci: do you already have some verilator testbenchs for you CPU?
<scanakci> BlackParrot repo has verilator testbenchs
<scanakci> They have bunch of makefiles to run their testbenchs using verilator, which I could run without any problem
<scanakci> I can see that they are generating a verilatorlist.file which includes paths to the system verilog files used by verilator
<scanakci> I guess I need to modify litex_sim to accept that kind of file
<scanakci> as you already pointed
<_florent_> scanakci: if you give me the manually modified litex_sim generated files that works with BlackParrot, i'm happy to do the integration in LiteX
CarlFK has joined #litex
<somlo> _florent_: I was going to send a PR containing this patch: (get_csr_header should use the existing SoC shadow base, right now both soc_core and independently assume their own default 0x8000_0000)
<tpb> Title: litex/ at master · enjoy-digital/litex · GitHub (at
<somlo> and then I noticed "with_shadow_base=True", only in get_csr_header. It's only used here:
<tpb> Title: litex/ at master · enjoy-digital/litex · GitHub (at
<somlo> and I'm wondering if it's useful at all, or mostly just dead code. I'm thinking of also removing the "with_shadow_base" check, and we can simply set shadow_base to 0 if we don't want it, which should be an orthogonal, future conversation :)
<somlo> any thoughts?
* somlo will be back in 30 minutes, sorry to ask a question and immediately go afk :(
<scanakci> _florent_: To clarify, do you want me to modify the auto-generated files by litex_sim ( some files in gateware and software folders) and make sure those work with blackparrot?
<somlo> _florent_: (I'm fairly confident this one's right)
<somlo> would still be curious in understanding what role 'with_shadow_base' is supposed to play here:
<tpb> Title: litex/ at master · enjoy-digital/litex · GitHub (at
<scanakci> In gateware file, I am modifying the and running it. Looks like that if I change the order of files (first header files) in verilator command, the errors vanish.
<scanakci> __florent_: Does that work for you if I modify file to read paths or files from a file (verilator looks like to have this capability)? I can then provide modified file to you.
freeemint has quit [Ping timeout: 245 seconds]
<_florent_> scanakci: yes, that's what i was suggesting, if you provide me the modified .sh that works, i'll do the modification in litex_sim to make it work (please also provide the skeleton of the blackparrot wrapper you have so that i can test)
<_florent_> scanakci: if you want, you can create a litex issue for that on github
freeemint has joined #litex
<scanakci> _florent_: thank you so much. I will create the issue. Sure, I can provide the wrapper. It will fail at this point since blackparrot does not have an AXI interface. We are working on it in parallel.
<_florent_> scanakci: yes sure no problem, that's just to work on the litex_sim issue
Dolu has quit [Ping timeout: 265 seconds]
<_florent_> somlo: thanks, i'll look where with_shadow_base is used
[tj] has left #litex ["WeeChat 2.4"]
freeemint has quit [Ping timeout: 268 seconds]
freeemint has joined #litex
CarlFK has quit [Ping timeout: 265 seconds]
snajpa has joined #litex
<snajpa> ERROR: Multiple edge sensitive events found for this signal!
<snajpa> very noob question: how does one debug that? :)
<tpb> Title: V8_kgujf , Diff | HaveSnippet (at
<snajpa> here's what I'm trying to do (on top of
<tpb> Title: GitHub - enjoy-digital/versa_ecp5: Versa ECP5 SoC based on LiteX (at
CarlFK has joined #litex
<daveshah> snajpa: if you have a look at the full Yosys output (ie the log file) you should see a more useful message
<snajpa> ok, that's how the emulator PHY is done - it needs to do stuff on both edges of sd_clk
<snajpa> it that not supported by yosys yet?
<daveshah> It's not synthesisable Verilog at all
<snajpa> ok, "the more you don't know you don't know"
<snajpa> :D
<daveshah> and although there are some DDR IO hardware primitives they can't implement arbitrary logic like this
<daveshah> Can you point me to the problematic line?
<snajpa> so the SD emulator core in LiteSDCard is for simulation only?
<snajpa> sec
<tpb> Title: litesdcard/sd_phy.v at master · enjoy-digital/litesdcard · GitHub (at
<snajpa> and yosys says:
<snajpa> Creating register for signal `\sd_phy.\spi_cnt' using process `\sd_phy.$proc$/home/snajpa/fpga/litesdcard/litesdcard/emulator/verilog/sd_phy.v:194$5604'.
<snajpa> ERROR: Multiple edge sensitive events found for this signal!
<snajpa> spi_cnt is used in both posedge and negedge handling of sd_clk
<daveshah> Looks like it is supposed to be synthesisable
<daveshah> No, it isn't
<daveshah> Just the asynchronous reset is written in an illegal way
<daveshah> I think splitting into an if and an else if should fix it
<tpb> Title: litesdcard/sd_phy.v at master · enjoy-digital/litesdcard · GitHub (at
<daveshah> Each asynchronous reset in the always list has to correspond to an if/else if condition
<snajpa> daveshah: but that won't help with spi_cnt being written to @ posedge *and* negedge of sd_clk, will it?
<daveshah> Because it isn't
<daveshah> It's simply a signal with two asynchronous resets
<daveshah> You could even factor the "or" out, create a new signal and then have a traditional async reset
forksand has joined #litex
Dolu has joined #litex
<snajpa> okay this is awesome :)
* snajpa excited as hell
tpb has quit [Remote host closed the connection]