Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 01 2019 04:40

    wallento on bug1469

    VPI: Support for vpiModule Add… (compare)

  • Sep 29 2019 15:06

    wallento on vpi-module

    Add --public-flat-rw switch, bu… Internals: AstComment optional … Fix mis-indenting AstComments w… and 6 more (compare)

  • Sep 19 2019 06:38
    wallento commented #7
  • Sep 18 2019 08:17

    wallento on verilator-infrastructure

    (compare)

Tomasz Hemperek
@themperek
BTW: One could probbbly make a cocotb module that would replay any VCD (or other) on any simulator.
matthuszagh
@matthuszagh
sounds good, thanks for the response. Looking forward to trying this out, thanks for all the work you've put into it!
Stefan Wallentowitz
@wallento
@themperek thats a great idea
waveform to signal
Colin Marquardt
@cmarqu
Tomasz Hemperek
@themperek
@cmarqu exactly
gretzteam
@gretzteam
My experience with cocotb is that it's quite a bit slower than a pure verilog testbench. You can try it by simply toggling a clock forever. The difference it quite large. Now I don't understand the CS side of this, if it has to do with python and/or the VPI, but is it possible that cocotb+verilator is much faster than cocotb+standard simulator, just because of the way the VPI was implemented in verilator?
Tomasz Hemperek
@themperek
@gretzteam As I understand it is probably way time is used. Some solution for me was to use a clock period of 2 Clock(dut.Clk, 2) [or play with COCOTB_HDL_TIMEPRECISION/DVL_TIME_PRECISION]
gretzteam
@gretzteam
@themperek Are you saying that different clock period yield different execution time (assuming everything else being equal?)
Tomasz Hemperek
@themperek
yes
as I understand how ventilator works yes "it will tick every delta cycle if nothing happens in the design it will be wasting time" <- I am not expert so I may be saying something wrong
gretzteam
@gretzteam
Does that apply to other simulator like vcs or ncsim? I'm asking cause I saw a big speed difference there too...
Tomasz Hemperek
@themperek
@gretzteam This I do not know. Just by feeling, there was not much difference in other simulators.
Todd Strader
@toddstrader
Verilator doesn't have delta cycles. It only does work when eval() is called. Which in the case of cocotb integration is controlled by verilator.cpp. I'd have to dig into how the callbacks work wrt cocotb, but assuming a constant number of eval()s per cycle, Verilator could care less what your simulated period is.
Stefan Wallentowitz
@wallento
yeah, it pretty much depends on your design activity, I have this todo item to evaluate how to couple the design clock and the eval() call directly
otherwise it is a huge impact that will make verilator significantly slower
the only open item are asynchronous resets then
Tomasz Hemperek
@themperek
@wallento would it make sense for now to define some parameter that will set how often eval is called by user/lowest clock period (can try some automatic in future)?
Matthew Ballance
@mballance
By the way, I mentioned this on the regular cocotb Gitter channel, but thought I'd mention it here as well. Cocotb works with stock (4.022) Verilator when task-based BFMs (PR #1217) are used to interface with the design. Task-based BFMs interface with Python/Cocotb via DPI calls, and consequently don't require signal-level access via VPI.
Stefan Wallentowitz
@wallento
@mballance yeah, this is preferable for Verilator and much faster than VPI
@themperek yes, it currently is defined by the timespec
I am working on being more like an event driven, essentially advancing time up to the next timed callback
Lavanya Jagan
@lavanyajagan_gitlab

Hi all, has anyone faced the following issue in the cocotb-verilator setup

  • cocotb-config: 1.3.0rc2
  • Verilator 4.025 devel rev v4.024-70-gf23fe8fd
  • Python 3.7
    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[1]. It works fine with cocotb-vcs setup.

Stefan Wallentowitz
@wallento
@lavanyajagan_gitlab Hi. This sounds strange. Can you give a more complete code example that produces the error?
Lavanya Jagan
@lavanyajagan_gitlab
Yes
To reproduce: $ cd adder_arr/tests; make SIM=verilator
Lavanya Jagan
@lavanyajagan_gitlab
@wallento Hi Stefan.. were you able to see the same issue that I reported
gretzteam
@gretzteam

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

dut.MYPARAM

Is the syntax different for verilator?

Edit: This applies to parameters declared within the module as well.

gretzteam
@gretzteam
Trying to get a VCD output from a cocotb/verilator sim...From the Makefile it seems like adding VERILATOR_TRACE=1 would work but I don't see any VCD being created. I tried with the adder and dff example as well.
gretzteam
@gretzteam
Edit: VERILATOR_TRACE=1 actually works fine to get a VCD. Not sure what was wrong before.
Colin Marquardt
@cmarqu
Would you care to make a PR for the docs? Probably best in this section: https://github.com/cocotb/cocotb/blob/master/documentation/source/simulator_support.rst#verilator
Stefan Wallentowitz
@wallento
@gretzteam I think that parameters do not work
but it should be simple to add them, read-only of course
There are plenty of things missing in Verilator VPI
I will add it to the list, but it will take some time I fear
Mark Melvin
@mark_melvin_twitter

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?

Stefan Wallentowitz
@wallento
@mark_melvin_twitter this doesn't sound right
can we try to get it to a minimum working example
this stuff is pretty much just how I got it to work
it is early days, but what you describe "should work"
so, where do we start? I pretty much have the same setup
Mark Melvin
@mark_melvin_twitter

I created a PR to fix the makefile here: cocotb/cocotb#1356

The dut issue will take some more effort, I'm afraid.

gretzteam
@gretzteam
I have noticed that my registers with async reset do not reset with verilator! One need a falling edge on the resetb pin for the flops to take the reset value (I have to pulse reset high, then low).
gretzteam
@gretzteam
I will prepare a minimal example.
Todd Strader
@toddstrader
@gretzteam see --x-initial-edge in the Verilator manual. That may resolve your issue.
gretzteam
@gretzteam
@toddstrader Per the description in the manual this looks like exactly what I need. However, I added the switch and it doesn't work. I'll play more with it, could be the way the Makefile is built and passes PLUSARGS around. I'll report back.
Todd Strader
@toddstrader
OK, great. If you think there's a problem with that switch (I'm just aware of it, I don't use it) the best way to report it would be via a Verilator issue (preferably modulo cocotb).

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.

gretzteam
@gretzteam
Reading a bit more about it, it might make sense to actually have a 1->0 negative edge part of my testbenches on resetb. It costs nothing to do, avoids needing this switch, and is more general...