15:27 <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 core.py, 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::*;

15:28 <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.

15:28 <scanakci> https://www.veripool.org/boards/18/topics/1223-Verilog-Perl-ERROR-on-importing-a-pkg

15:28 <tpb> Title: ERROR on importing a pkg - Verilog-Perl - Veripool (at www.veripool.org)

15:28 <scanakci> https://www.veripool.org/boards/2/topics/1656-Verilator-Parse-error-with-import-name-

15:28 <tpb> Title: Parse error with import name::* - Verilator - Veripool (at www.veripool.org)

15:31 <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.

15:32 <scanakci> Log from litex_sim.py https://usercontent.irccloud-cdn.com/file/L6WRt7yr/log

15:33 <scanakci> This is how my add_source look like: https://usercontent.irccloud-cdn.com/file/01YdC4ML/addsource

15:34 <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.

15:36 <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.

16:51 <_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

16:52 <_florent_> scanakci: do you already have some verilator testbenchs for you CPU?

16:52 <scanakci> BlackParrot repo has verilator testbenchs

16:53 <scanakci> They have bunch of makefiles to run their testbenchs using verilator, which I could run without any problem

16:54 <scanakci> I can see that they are generating a verilatorlist.file which includes paths to the system verilog files used by verilator

16:54 <scanakci> I guess I need to modify litex_sim to accept that kind of file

16:54 <scanakci> as you already pointed

17:03 <_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

17:44 <somlo> _florent_: I was going to send a PR containing this patch: https://pastebin.com/BmKrLmeh (get_csr_header should use the existing SoC shadow base, right now both soc_core and https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/export.py#L159 independently assume their own default 0x8000_0000)

17:44 <tpb> Title: litex/export.py at master · enjoy-digital/litex · GitHub (at github.com)

17:45 <somlo> and then I noticed "with_shadow_base=True", only in get_csr_header. It's only used here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/export.py#L177

17:45 <tpb> Title: litex/export.py at master · enjoy-digital/litex · GitHub (at github.com)

17:46 <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 :)

17:46 <somlo> any thoughts?

17:53 <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?

18:32 <somlo> _florent_: https://github.com/enjoy-digital/litex/pull/274 (I'm fairly confident this one's right)

18:34 <somlo> would still be curious in understanding what role 'with_shadow_base' is supposed to play here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/export.py#L177

18:34 <tpb> Title: litex/export.py at master · enjoy-digital/litex · GitHub (at github.com)

18:47 <scanakci> In gateware file, I am modifying the build_dut.sh and running it. Looks like that if I change the order of files (first header files) in verilator command, the errors vanish.

18:48 <scanakci> __florent_: Does that work for you if I modify build_dut.sh file to read paths or files from a file (verilator looks like to have this capability)? I can then provide modified file to you.

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

19:01 <_florent_> scanakci: if you want, you can create a litex issue for that on github

19:05 <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.

19:10 <_florent_> scanakci: yes sure no problem, that's just to work on the litex_sim issue

19:14 <_florent_> somlo: thanks, i'll look where with_shadow_base is used

21:41 <snajpa> ERROR: Multiple edge sensitive events found for this signal!

21:41 <snajpa> very noob question: how does one debug that? :)

21:42 <snajpa> https://paste.vpsfree.cz/V8_kgujf/

21:42 <tpb> Title: V8_kgujf , Diff | HaveSnippet (at paste.vpsfree.cz)

21:43 <snajpa> here's what I'm trying to do (on top of https://github.com/enjoy-digital/versa_ecp5/)

21:43 <tpb> Title: GitHub - enjoy-digital/versa_ecp5: Versa ECP5 SoC based on LiteX (at github.com)

21:44 <daveshah> snajpa: if you have a look at the full Yosys output (ie the log file) you should see a more useful message

21:52 <snajpa> ok, that's how the emulator PHY is done - it needs to do stuff on both edges of sd_clk

21:52 <snajpa> it that not supported by yosys yet?

21:53 <daveshah> It's not synthesisable Verilog at all

21:54 <snajpa> ok, "the more you don't know you don't know"

21:54 <snajpa> :D

21:54 <daveshah> and although there are some DDR IO hardware primitives they can't implement arbitrary logic like this

21:54 <daveshah> Can you point me to the problematic line?

21:54 <snajpa> so the SD emulator core in LiteSDCard is for simulation only?

21:54 <snajpa> sec

21:55 <snajpa> https://github.com/enjoy-digital/litesdcard/blob/master/litesdcard/emulator/verilog/sd_phy.v

21:55 <tpb> Title: litesdcard/sd_phy.v at master · enjoy-digital/litesdcard · GitHub (at github.com)

21:55 <snajpa> and yosys says:

21:55 <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'.

21:55 <snajpa> ERROR: Multiple edge sensitive events found for this signal!

21:55 <snajpa> spi_cnt is used in both posedge and negedge handling of sd_clk

21:55 <daveshah> Looks like it is supposed to be synthesisable

21:56 <daveshah> No, it isn't

21:56 <daveshah> Just the asynchronous reset is written in an illegal way

21:57 <daveshah> I think splitting https://github.com/enjoy-digital/litesdcard/blob/master/litesdcard/emulator/verilog/sd_phy.v#L196 into an if and an else if should fix it

21:57 <tpb> Title: litesdcard/sd_phy.v at master · enjoy-digital/litesdcard · GitHub (at github.com)

21:57 <daveshah> Each asynchronous reset in the always list has to correspond to an if/else if condition

22:13 <snajpa> daveshah: but that won't help with spi_cnt being written to @ posedge *and* negedge of sd_clk, will it?

22:14 <daveshah> Because it isn't

22:14 <daveshah> It's simply a signal with two asynchronous resets

22:14 <daveshah> You could even factor the "or" out, create a new signal and then have a traditional async reset

23:17 <snajpa> okay this is awesome :)