Release cocotb 1.4.0 #1942

imphil · 2020-06-23T13:11:40Z

Milestone: https://github.com/cocotb/cocotb/milestone/11

Release process checklist:

Close all issues blocking the milestone
Prepare release announcement email
Tag a release
Test release build on PyPi
Send out announcement to mailing list

cmarqu · 2020-06-23T13:23:49Z

As a reminder, you once created https://github.com/cocotb/cocotb/wiki/Release-Process :)

ktbarrett · 2020-06-23T13:53:20Z

Task list for myself related to this

Test with Questa 10.5a (earliest version that runs on RHEL7)
Test with Questa 10.7c
Test with Questa 2019.2 (has had issues recently)
Test with Questa 2020.1 (has had issues recently)
Compare GHDL results between 1.3 and 1.4rc1 for additional regressions
Check tarball
- packaged examples run
- essential non-runnable files exist

Results

Looks like GHDL did regress between 1.3.1 and 1.4. I will look into it more later.
Running the packaged examples works with Icarus, Questa, GHDL (almost, the mean example is broken), Verilator (almost, dff example hangs, mean example won't compile).

elgorwi · 2020-06-24T07:08:35Z

Task list for myself related to this
* [x]  Test with Questa 10.5a (earliest version that runs on RHEL7)

* [x]  Test with Questa 10.7c

* [x]  Test with Questa 2019.2 (has had issues recently)

* [x]  Test with Questa 2020.1 (has had issues recently)

* [x]  Compare GHDL results between 1.3 and 1.4rc1 for additional regressions

* [x]  Check tarball
  
  * packaged examples run
  * essential non-runnable files exist
Results

Looks like GHDL did regress between 1.3.1 and 1.4. I will look into it more later.
Running the packaged examples works with Icarus, Questa, GHDL (almost, the mean example is broken), Verilator (almost, dff example hangs, mean example won't compile).

Running the DFF example with Verilator is very slow (48s on my system). Changing the clock frequency from us to ns or alternatively changing the time precision to ns in dff.v will speed this up considerably.
Running the mean example with Verilator is only matter of merging #1901.
Support for arrays is required (ghdl/ghdl#1249) to run the mean example with GHDL.

eric-wieser · 2020-06-24T09:18:52Z

I note that the PyPI build of 1.4.0 does not contain a wheel. I assume this is a deliberate choice?

ktbarrett · 2020-06-24T13:25:33Z

@elgorwi The failure for the mean example with GHDL I'm seeing isn't related to arrays sim.log.

eric-wieser · 2020-06-24T13:34:35Z

Looks like it's about support for accessing parameters?

AttributeError: mean contains no object named DATA_WIDTH

ktbarrett · 2020-06-24T13:54:19Z

AFAIK GHDL doesn't have issues accessing constants that aren't complex records or arrays.

mciepluc · 2020-06-24T17:50:42Z

Great work guys, I tested quite advanced stuff (+cocotb-test and GUI mode ):

tested with Questa 2020.2
tested with Xcelium 19.09.10
tested with Icarus (bare installation from sources)

marlonjames · 2020-06-24T17:53:56Z

@ktbarrett Accessing constants in GHDL wasn't added until ghdl/ghdl#1297, which isn't in any released version.

ktbarrett · 2020-06-24T19:09:29Z

It would be awful nice to start tracking the limitations of all these simulators and what's missing for full support.

ktbarrett · 2020-06-25T00:06:02Z

@garmin-mjames So I updated my ghdl install and still no luck, it fails for the same reasons.

marlonjames · 2020-06-25T16:28:49Z

@ktbarrett can you run GHDL with --vpi-trace? That should give some better information.

cmarqu · 2020-06-25T16:41:20Z

@ktbarrett can you run GHDL with --vpi-trace? That should give some better information.

Maybe also use --trace-signals as in
#875 (comment)

ktbarrett · 2020-06-26T04:45:48Z

> ghdl --version
GHDL 1.0-dev (v0.37.0-769-g18a71a43) [Dunoon edition]
 Compiled with GNAT Version: 9.3.0
 mcode code generator
Written by Tristan Gingold.

Copyright (C) 2003 - 2020 Tristan Gingold.
GHDL is free software, covered by the GNU General Public License.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> env SIM_ARGS="--trace-signals --vpi-trace" make SIM=ghdl TOPLEVEL_LANG=vhdl
...

sim.log

marlonjames · 2020-06-29T17:00:57Z

@ktbarrett
Line 63 in the log calls vpi_free_object on the DATA_WIDTH handle. BUS_WIDTH is not freed. Running with COCOTB_LOG_LEVEL=DEBUG should give more relevant log messages from GPI code.

ktbarrett · 2020-06-30T01:04:08Z

@garmin-mjames Nice catch. With COCOTB_LOG_LEVEL=DEBUG.

The relevant bit:

     0.00ns DEBUG    cocotb.gpi                                GpiCommon.cpp:301  in __gpi_get_handle_by_name        Searching for DATA_WIDTH
 vpi_get_time (0000000000000000, {mtype=vpiSimTime}) = 0ms
     0.00ns DEBUG    cocotb.gpi                                GpiCommon.cpp:312  in __gpi_get_handle_by_name        Checking if DATA_WIDTH is native through implementation VPI
 vpi_handle_by_name ("mean.DATA_WIDTH", 0000000000000000) = 0000557BA17CC850
 vpi_get (vpiType, 0000557BA17CC850) = 7
 vpi_get (vpiType, 0000557BA17CC850) = 7
 vpi_get_str (vpiType, 0000557BA17CC850) = "???"
 vpi_get_time (0000000000000000, {mtype=vpiSimTime}) = 0ms
     0.00ns DEBUG    cocotb.gpi                                  VpiImpl.cpp:235  in create_gpi_obj_from_handle      VPI: Not able to map type ???(7) to object.
 vpi_free_object (0000557BA17CC850)
 vpi_get_time (0000000000000000, {mtype=vpiSimTime}) = 0ms
     0.00ns DEBUG    cocotb.gpi                                  VpiImpl.cpp:307  in native_check_create             Unable to fetch object mean.DATA_WIDTH
 vpi_get_time (0000000000000000, {mtype=vpiSimTime}) = 0ms
     0.00ns DEBUG    cocotb.gpi                                GpiCommon.cpp:371  in gpi_get_handle_by_name          Failed to find a handle named DATA_WIDTH via any registered implementation

VPI type 7 is vpiConstant ("numerical constant or literal string"). Seemingly, you are then supposed to obtain the type of the constant by another call: vpi_get(vpiConstType, handle). So this is our bug.

marlonjames · 2020-06-30T01:19:52Z

Interesting that BUS_WIDTH is vpiParameter but DATA_WIDTH is vpiConstant.

Edit: Nevermind, I was looking at the SystemVerilog file. GHDL uses VPI to access the VHDL design.

ktbarrett · 2020-06-30T01:37:54Z

It might have to do with DATA_WIDTH being constant folded and being stored in another part of the binary and accessed in another way. No one may have checked for consistency. I'll bring it up, but I have a PR. I'm not sure if it belongs in 1.4 or not since we are in rc.

marlonjames · 2020-06-30T19:24:12Z

Tested with Active-HDL.

Active-HDL 11.1

Verilog failures:

test_array.test_discover_all - needs expected count specified

These tests are marked as expect fail or skip for Riviera, probably for the same underlying reasons:
test_discovery.access_integer
test_discovery.access_const_string_verilog

VHDL failures:

issue_1279.test_sim_failure_a - same as #1859
test_array.test_discover_all - needs expected count specified
test_timing_triggers.test_readwrite_in_readonly - passes but test expects error (Riviera does this as well, see #1877)
several tests in test_endian_swapper - (#1498 fixes these)
example dff test - same as #1880

Active-HDL 10.1

Various tests fail beyond those listed above. Many verilog tests crash due to #1834.

imphil · 2020-07-07T22:47:48Z

Thanks all for your testing. We do not have any more issues blocking the 1.4 milestone. I therefore just created the 1.4rc2 tag. If nothing blocking comes up by tomorrow I intend to release this version without further changes as 1.4.0 final.

imphil · 2020-07-08T20:50:32Z

The release is now done and master is open for feature development again. Thanks everyone!

imphil added this to the 1.4 milestone Jun 23, 2020

imphil self-assigned this Jun 23, 2020

ktbarrett mentioned this issue Jun 30, 2020

Support vpiConstant, which is used by GHDL #1949

Closed

imphil closed this as completed Jul 8, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Release cocotb 1.4.0 #1942

Release cocotb 1.4.0 #1942

imphil commented Jun 23, 2020 •

edited

cmarqu commented Jun 23, 2020

ktbarrett commented Jun 23, 2020 •

edited

elgorwi commented Jun 24, 2020

Results

eric-wieser commented Jun 24, 2020

ktbarrett commented Jun 24, 2020 •

edited

eric-wieser commented Jun 24, 2020

ktbarrett commented Jun 24, 2020

mciepluc commented Jun 24, 2020

marlonjames commented Jun 24, 2020

ktbarrett commented Jun 24, 2020

ktbarrett commented Jun 25, 2020

marlonjames commented Jun 25, 2020

cmarqu commented Jun 25, 2020

ktbarrett commented Jun 26, 2020

marlonjames commented Jun 29, 2020

ktbarrett commented Jun 30, 2020 •

edited

marlonjames commented Jun 30, 2020 •

edited

ktbarrett commented Jun 30, 2020

marlonjames commented Jun 30, 2020

imphil commented Jul 7, 2020

imphil commented Jul 8, 2020

Release cocotb 1.4.0 #1942

Release cocotb 1.4.0 #1942

Comments

imphil commented Jun 23, 2020 • edited

cmarqu commented Jun 23, 2020

ktbarrett commented Jun 23, 2020 • edited

Results

elgorwi commented Jun 24, 2020

Results

eric-wieser commented Jun 24, 2020

ktbarrett commented Jun 24, 2020 • edited

eric-wieser commented Jun 24, 2020

ktbarrett commented Jun 24, 2020

mciepluc commented Jun 24, 2020

marlonjames commented Jun 24, 2020

ktbarrett commented Jun 24, 2020

ktbarrett commented Jun 25, 2020

marlonjames commented Jun 25, 2020

cmarqu commented Jun 25, 2020

ktbarrett commented Jun 26, 2020

marlonjames commented Jun 29, 2020

ktbarrett commented Jun 30, 2020 • edited

marlonjames commented Jun 30, 2020 • edited

ktbarrett commented Jun 30, 2020

marlonjames commented Jun 30, 2020

Active-HDL 11.1

Verilog failures:

VHDL failures:

Active-HDL 10.1

imphil commented Jul 7, 2020

imphil commented Jul 8, 2020

imphil commented Jun 23, 2020 •

edited

ktbarrett commented Jun 23, 2020 •

edited

ktbarrett commented Jun 24, 2020 •

edited

ktbarrett commented Jun 30, 2020 •

edited

marlonjames commented Jun 30, 2020 •

edited