wallento on bug1469
VPI: Support for vpiModule Add… (compare)
wallento on vpi-module
Add --public-flat-rw switch, bu… Internals: AstComment optional … Fix mis-indenting AstComments w… and 6 more (compare)
wallento on verilator-infrastructure
Hi all, has anyone faced the following issue in the cocotb-verilator setup
Traceback (most recent call last): File "/usr/local/lib/python3.7/dist-packages/cocotb/log.py", line 198, in _log_from_c logger.handle(record) File "/usr/lib/python3.7/logging/__init__.py", line 1524, in handle self.callHandlers(record) File "/usr/lib/python3.7/logging/__init__.py", line 1586, in callHandlers hdlr.handle(record) File "/usr/lib/python3.7/logging/__init__.py", line 894, in handle self.emit(record) File "/usr/lib/python3.7/logging/__init__.py", line 1025, in emit msg = self.format(record) File "/usr/lib/python3.7/logging/__init__.py", line 869, in format return fmt.format(record) File "/usr/local/lib/python3.7/dist-packages/cocotb/log.py", line 174, in format return self._format(level, record, msg, coloured=True) File "/usr/local/lib/python3.7/dist-packages/cocotb/log.py", line 111, in _format time_ns = get_sim_time('ns') RecursionError: maximum recursion depth exceeded Fatal Python error: Cannot recover from stack overflow.
I am trying to access a memory element in the verilog design
f = dut.rra. It works fine with cocotb-vcs setup.
$ cd adder_arr/tests; make SIM=verilator
Cannot access top level parameters when using verilator. For example, if the top level looks like
module mytop #(parameter MYPARAM=5) ...
with other simulators (at least Icarus, IUS and Modelsim), one could access MYPARAM using
Is the syntax different for verilator?
Edit: This applies to parameters declared within the module as well.
Hi Guys - I am trying to build our existing testbench(es) with verilator and not having much luck. It seems that to start the
Makefile.verilator just doesn't work. This seems odd as some of you are having success, but I have found multiple issues with it - the biggest one being that
$< does not resolve to $(SIM_BUILD)/$(TOPLEVEL), rather it resolves to just $(SIM_BUILD) - which breaks the two main targets. I'm wondering what the difference is if it is working for others. I am on Ubuntu 19.10 with verilator 4.026 and GNU make 4.2.1.
Second, when I work around the makefile issues and disable warnings to get our verilog to build, my tests are unusable as there is a critical missing piece of the design not even present on the dut (which is there when building with icarus or vcs). I'm just wondering if this is working for anyone else yet, or is it still quite early days?
I created a PR to fix the makefile here: cocotb/cocotb#1356
The dut issue will take some more effort, I'm afraid.
Also, there's already two tests (one which intentionally fails) in Verilator's regression suite for this:
$ grep x-initial-edge test_regress/t/*.pl
test_regress/t/t_initial_edge_bad.pl:# fail with Verilator if --x-initial-edge is not specified.
test_regress/t/t_initial_edge.pl: verilator_flags2 => ["--x-initial-edge"]
Those might be useful for reference.