Project

General

Profile

[logo] 
 
Home
News
Activity
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  BugVise
  CovVise
  Force-Gate-Sim
  Gspice
  IPC::Locker
  Rsvn
  SVN::S4
  Voneline
  WFH
General Info
  Papers

Issue #1489

Python support for Verilated designs

Added by Maarten De Braekeleer about 1 month ago. Updated 23 days ago.

Status:
Feature
Priority:
Normal
Category:
Configure/Make/Compiling
% Done:

80%


Description

I've improved the patchset by Patrick Stewart (proposed in bug1663) to add Python support for Verilated designs. It has support for both make and cmake as make system. It includes examples and a regression test. The Python support has a hard dependency on pybind11. The examples and test will be skipped when the environment variable PYBIND11_ROOT is not set.

The patches are based on the cmake patches in bug1663 and can be found at: https://github.com/madebr/verilator/tree/python

I've got some questions:
  • the Python compile definition is VL_PYTHON. Is this ok? Because some variables have a VM_ prefix and some VL_.
  • the Python bindings allow users to set and read ports. It is currently not possible to fetch metadata of modules. Would that be useful? I know how to get the width of ports but is it possible to get parameters of modules?
  • After importing a Verilated Python module with threads support, when the python interpreter is idle, the cpu usage rises to the number of threads that was passed to verilator. I think this behavior is rather undesirable. The cpu usage should only rise when the computations start and lower again when it is finished.
  • Python does not have ani VPI/DPI support, is that needed? Or is that SystemC only?
  • Would support for verilator_coverage be useful?

History

#1 Updated by Wilson Snyder 23 days ago

  • Status changed from New to Feature

the Python compile definition is VL_PYTHON. Is this ok? Because some variables have a VM_ prefix and some VL_.

VM_ means the variable is defined in the Makefile. VL_ means defined elsewhere.

the Python bindings allow users to set and read ports. It is currently not possible to fetch metadata of modules. Would that be useful? I know how to get the width of ports but is it possible to get parameters of modules?

I can see that this might be useful but expect it would rarely be used so would delay implementing this. Note parameter information is passed only if the parameter was marked verilator public.

The cpu usage should only rise when the computations start and lower again when it is finished.

Agreed, this should be fixed.

Python does not have ani VPI/DPI support, is that needed? Or is that SystemC only?

The VPI probably isn't that useful. Allowing DPI calls from Verilog into python, or python into Verilog seems useful but might be a lot of work to implement.

Would support for verilator_coverage be useful?

I assume you mean the calls needed to save coverage. I would think so.

Also available in: Atom