Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Can we access multidimensional reg array using cocotb?

See original GitHub issue

Is there any way to access multidimensional reg array in cocotb? Such as

  reg[63:0] gpr[31:0];

Whenever I access the reg like this,

  handle = dut.gpr

It reports ‘RuntimeError: maximum recursion depth exceeded in cmp’

Issue Analytics

State:
Created 4 years ago
Comments:30 (19 by maintainers)

Top GitHub Comments

2reactions

JaewonHurcommented, Jan 23, 2020

I tried. Still RecursionError, messages are below.

Traceback (most recent call last):
  File "/home/jwhur/.local/lib/python3.6/site-packages/cocotb/log.py", line 201, in _log_from_c
    function_name
  File "/usr/lib/python3.6/logging/__init__.py", line 1413, in makeRecord
    sinfo)
  File "/usr/lib/python3.6/logging/__init__.py", line 286, in __init__
    self.module = os.path.splitext(self.filename)[0]
  File "/usr/lib/python3.6/posixpath.py", line 129, in splitext
    return genericpath._splitext(p, sep, None, extsep)
  File "/usr/lib/python3.6/genericpath.py", line 130, in _splitext
    if dotIndex > sepIndex:
RecursionError: maximum recursion depth exceeded in comparison
Fatal Python error: Cannot recover from stack overflow.

Current thread 0x00007f08a43b9600 (most recent call first):
  File "/usr/lib/python3.6/genericpath.py", line 130 in _splitext
  File "/usr/lib/python3.6/posixpath.py", line 129 in splitext
  File "/usr/lib/python3.6/logging/__init__.py", line 286 in __init__
  File "/usr/lib/python3.6/logging/__init__.py", line 1413 in makeRecord
  File "/home/jwhur/.local/lib/python3.6/site-packages/cocotb/log.py", line 201 in _log_from_c
  File "/home/jwhur/.local/lib/python3.6/site-packages/cocotb/utils.py", line 68 in get_sim_time
  File "/home/jwhur/.local/lib/python3.6/site-packages/cocotb/log.py", line 112 in _format
  File "/home/jwhur/.local/lib/python3.6/site-packages/cocotb/log.py", line 179 in format
  File "/usr/lib/python3.6/logging/__init__.py", line 840 in format
  File "/usr/lib/python3.6/logging/__init__.py", line 994 in emit
  File "/usr/lib/python3.6/logging/__init__.py", line 865 in handle
  File "/usr/lib/python3.6/logging/__init__.py", line 1516 in callHandlers
  File "/usr/lib/python3.6/logging/__init__.py", line 1454 in handle
  File "/home/jwhur/.local/lib/python3.6/site-packages/cocotb/log.py", line 203 in _log_from_c
  File "/home/jwhur/.local/lib/python3.6/site-packages/cocotb/utils.py", line 68 in get_sim_time
  File "/home/jwhur/.local/lib/python3.6/site-packages/cocotb/log.py", line 112 in _format
  File "/home/jwhur/.local/lib/python3.6/site-packages/cocotb/log.py", line 179 in format

1reaction

elgorwicommented, Jun 3, 2020

@JaewonHur , This issue can now be closed. Verilator has just been updated with a PR that addresses array access in cocotb: https://github.com/verilator/verilator/pull/2395 To test this you will need to pull the latest Verilator version from git and compile/install manually or alternatively wait until the next (> v4.034) Verilator package release.