How to force usage of python 3 in cocotb?

How to force usage of python 3 in cocotb?

I'm using CocoTB to test my HDL design, but as I understand, it's possible to use it with python2.7 or python3.

In setup.py config file I can see that both are supported :

    [...]
    "Programming Language :: Python :: 2.7",
    "Programming Language :: Python :: 3",
    [...]

In endian_swapper test (examples/endian_swapper/tests/test_endian_swapper.py), if I modify a test script to see which version is used :

@cocotb.test()
def wavedrom_test(dut):
    """
    Generate a JSON wavedrom diagram of a trace and save it to wavedrom.json
    """
    print("Python version used {}".format(sys.version_info))

I can see that python2.7 is used when I launch test with «make» command :

Python version used sys.version_info(major=2, minor=7, micro=9, releaselevel='final', serial=0)

My python3 executable is named ... python3 in fact (debian). Is there a canonical way to force cocotb to use python3 instead of python2 ?


try updating the PATH variable. worked for me. when cocotb looks for python, it looks for it at the folders that are listed at the PATH variable. let say that your python3 full path is at/usr/bin/python3 (you can find python3 full path by which python3) i also added here link to new place in case both python2 and python3 are at the same folder...

> python -V
Python 2.7.17
> ln -s /usr/bin/python3 /home/$USER/python
> export PATH="/home/$USER:$PATH"
> python -V
Python 3.6.9

How to use cocotb with python3 ? · Issue #888 · cocotb/cocotb · GitHub, I found a proper way to do it. First download the last version of python on the official website : $ wget https://www.python.org/ftp/python/3.7.4/Python-3.7.4.tar.​xz. Many thanks everyone for the constructive review yesterday. Today I was able to check the patch also compiles in a Python 3.6.8 environment and the testcase correctly works for Cadence Xcelium and Incisive. On my other machine (Python 3.8) I can test against iverilog (works fine) and ghdl (runs, but force/release is not implemented).


I found a proper way to do it.

First download the last version of python on the official website :

$ wget https://www.python.org/ftp/python/3.7.4/Python-3.7.4.tar.xz

Then unflat it and configure it with the option --enable-shared

$ tar -Jxvf Python-3.7.4.tar.xz
$ cd Python-3.7.4
$ ./configure --enable-shared
$ make
$ sudo make install

Once installed go to your cocotb test directory then install virtual environment :

$ export LD_LIBRARY_PATH=/usr/local/lib
$ virtualenv --python=/usr/local/bin/python3.7 envp37
$ source envp37/bin/activate
$ python -m pip install cocotb

Then you can launch your cocotb test environment with traditional make :

$ make

Dectivate the python environment with :

$ deactivate

Quickstart Guide, But to launch cocotb tests I don't launch python directly, I'm using the Makefile. And it's always python2.7 that be used. What is the good way to force cocotb to  IN NO EVENT SHALL POTENTIAL VENTURES LTD BE LIABLE FOR ANY # DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES # (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; # LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND # ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT


I found solutions on linuxconfig.org, thanks to themperek. But it's not exactly what I want.

The alias solution doesn't work for me. The update-alternative works but only with «official» python3 installed on debian. I can't use an alternative (3.7) manually installed.

$ sudo update-alternatives --config python
There are 3 choices for the alternative python (providing /usr/bin/python).

  Selection    Path                Priority   Status
------------------------------------------------------------
  0            /usr/bin/python3.7   2         auto mode
  1            /usr/bin/python2.7   0         manual mode
  2            /usr/bin/python3.4   1         manual mode
* 3            /usr/bin/python3.7   2         manual mode

Press enter to keep the current choice[*], or type selection number: 3
$ make clean;make
0.00ns INFO     Running on Icarus Verilog version 11.0 (devel)
0.00ns INFO     Python interpreter initialised and cocotb loaded!
0.00ns INFO     Running tests with Cocotb v1.0.1 from /opt/cocotb
0.00ns INFO     Seeding Python random module with 1554105931
0.00ns INFO     Found test test_ttl.ttl_test
0.00ns INFO     Running test 1/1: ttl_test
0.00ns INFO     Starting test: "ttl_test"
                Description:  simple ttl test function 
[...]
3.4.2 (default, Feb  7 2019, 06:11:23) 
[...]

[PDF] cocotb Documentation, If a 32-bit simulator is being used then additional steps are needed, please see our Wiki. Debian/Ubuntu-based¶. sudo apt-get install git make gcc g++ swig python  cocotb is now built as Python package and installable through pip. (#517, #799, #800, #803, #805) Support for async functions and generators was added (Python 3 only). Please have a look at Coroutines for an example how to use this new feature. VHDL block statements can be traversed. Support for Python 3.7 was added.


cocotb/Lobby, With cocotb, VHDL/Verilog/SystemVerilog are normally only used for the design itself, not the testbench. cocotb has Python has a huge library of existing code to re-use like packet generation libraries. vhpi1 3 /* forcing 1 */. Once Python 2 is dropped, this should be inlined into `abort` below, and the call in `unschedule` replaced with `abort(outcome.error)`. """ assert self. _outcome is None if _debug: self. log. debug ("outcome forced to {} ". format (outcome)) self. _outcome = outcome cocotb. scheduler. unschedule (self) # like RunningCoroutine.kill(), but with a


cocotb · PyPI, I vaguely recall having to use @cocotb.function to do this in the past for some argument inside generator can alternatively be fixed by upgrading to python 3,  cocotb, a coroutine based cosimulation library for writing VHDL and Verilog testbenches in Python https://docs.cocotb.org python vhdl verilog uvm verification test 2,811 commits


Porting Python 2 Code to Python 3, To be exact, I'm implementing a kind of mem_load() function that will be used to Python paths listed there match the Python you are using for running cocotb? Pros: No need to change internals of cocotb, backward compatibility, cocotb just needs to expose some API to become callable from Python runtime. FuseSoc users can define cocotb target. Cons: No reuse of edalize knowledge on how to run different EDA tools.