Skip to content

fasm2bels: max recursion depth exceeded, make_routes.py, xc7a100t, soc/litex/base #1546

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
tcal-x opened this issue Jun 24, 2020 · 6 comments
Closed

fasm2bels: max recursion depth exceeded, make_routes.py, xc7a100t, soc/litex/base #1546

tcal-x opened this issue Jun 24, 2020 · 6 comments
Assignees
@tcal-x

Comments

@tcal-x
Copy link
Contributor

tcal-x commented Jun 24, 2020

Error seen:

[100%] Generating baselitex_arty100t/artix7_100t-xc7a100t-virt-xc7a100t-test/top_bit.v
Traceback (most recent call last):
  File "/home/tcal/2nd-tcal-x/symbiflow-arch-defs/build/env/conda/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/tcal/2nd-tcal-x/symbiflow-arch-defs/build/env/conda/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/tcal/2nd-tcal-x/symbiflow-arch-defs/xc/xc7/fasm2bels/__main__.py", line 4, in <module>
    main()
  File "/home/tcal/2nd-tcal-x/symbiflow-arch-defs/xc/xc7/fasm2bels/fasm2bels.py", line 403, in main
    top.make_routes(allow_orphan_sinks=args.allow_orphan_sinks)
  File "/home/tcal/2nd-tcal-x/symbiflow-arch-defs/xc/xc7/fasm2bels/verilog_modeling.py", line 1502, in make_routes
    net_map=self.net_map,
  File "/home/tcal/2nd-tcal-x/symbiflow-arch-defs/xc/xc7/fasm2bels/make_routes.py", line 709, in make_routes
    allow_orphan_sinks=allow_orphan_sinks
  File "/home/tcal/2nd-tcal-x/symbiflow-arch-defs/xc/xc7/fasm2bels/make_routes.py", line 583, in expand_sink
    allow_orphan_sinks=allow_orphan_sinks
  File "/home/tcal/2nd-tcal-x/symbiflow-arch-defs/xc/xc7/fasm2bels/make_routes.py", line 453, in expand_sink
    allow_orphan_sinks=allow_orphan_sinks
  File "/home/tcal/2nd-tcal-x/symbiflow-arch-defs/xc/xc7/fasm2bels/make_routes.py", line 583, in expand_sink
    allow_orphan_sinks=allow_orphan_sinks
...
  File "/home/tcal/2nd-tcal-x/symbiflow-arch-defs/xc/xc7/fasm2bels/make_routes.py", line 453, in expand_sink
    allow_orphan_sinks=allow_orphan_sinks
  [Previous line repeated 457 more times]
  File "/home/tcal/2nd-tcal-x/symbiflow-arch-defs/xc/xc7/fasm2bels/make_routes.py", line 436, in expand_sink
    sink_node_pkey = get_node_pkey(conn, sink_wire_pkey)
  File "/home/tcal/2nd-tcal-x/symbiflow-arch-defs/xc/xc7/fasm2bels/connection_db_utils.py", line 60, in get_node_pkey
    c = conn.cursor()
RecursionError: maximum recursion depth exceeded while calling a Python object
xc/xc7/tests/soc/litex/base/CMakeFiles/file_xc_xc7_tests_soc_litex_base_baselitex_arty100t_artix7_100t-xc7a100t-virt-xc7a100t-test_top_bit.v.dir/build.make:82: recipe for target 'xc/xc7/tests/soc/litex/base/baselitex_arty100t/artix7_100t-xc7a100t-virt-xc7a100t-test/top_bit.v' failed

This test was rebased on top of current master (a8c60d9).
@tcal-x tcal-x self-assigned this Jun 24, 2020
@litghost
Copy link
Contributor

litghost commented Jun 24, 2020 •
edited
Loading

Is this a case of an infinite loop or a net that was long enough to block to stack?

You can attempt to increase the Python stack to quickly check.

@tcal-x
Copy link
Contributor Author

tcal-x commented Jun 25, 2020

Is this a case of an infinite loop or a net that was long enough to block to stack?

You can attempt to increase the Python stack to quickly check.

Thanks Keith, yep, if I do sys.setrecursionlimit(1250), it finishes without error. The exact value needed is somewhere between 1200 and 1250. Should I add it to this script, or is there a different preferred method?

@litghost
Copy link
Contributor

Should I add it to this script, or is there a different preferred method?

We should convert from a recursive algorithm, to an explicit stack. Larger graphs will have longer paths, and limiting the path length based on the stack limit of threads is a bad plan.

@mithro
Copy link
Contributor

mithro commented Jun 25, 2020

@litghost / @tcal-x -- It seems like we should just set sys.setrecursionlimit(5000) and then put converting the recursive algorithm to an explicit stack on the TODO list?

@litghost
Copy link
Contributor

@litghost / @tcal-x -- It seems like we should just set sys.setrecursionlimit(5000) and then put converting the recursive algorithm to an explicit stack on the TODO list?

This runs the risk of hitting the underlying thread stack. When that blows, it will cause a SIGSEGV, rather than a python exception. So that solution is not a good one.

This was referenced Jun 30, 2020
Open
Closed
@tcal-x
Copy link
Contributor Author

tcal-x commented Jun 30, 2020

@litghost yeah there must have been something very wrong with vpr. After rebasing, the error went away on its own, so I added code to check the max recursion depth, and the max that it hit was just 44.

So I'll close this and not make any code changes.

@tcal-x tcal-x closed this as completed Jun 30, 2020
@tcal-x tcal-x mentioned this issue Jul 1, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@tcal-x tcal-x

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mithro @litghost @tcal-x