Mixed-languages multi-libraries not working as expected about cocotb HOT 6 OPEN

The Python runner is experimental and targeted to cocotb regression tests. You are free to copy and modify for your use, or integrate cocotb to your build / simulate workflow.

from cocotb.

I tried the python runner because I could not figure out how to do it with the standard Makefile flow. I updated my example with a cocotb Makefile ( https://github.com/oliverbm67/cocotb/blob/63ecde3f9527a8d2374e349a651ea82e1724d2a8/examples/mixed_language_multi_libraries/cocotb/Makefile ), but it still has compilation order and library management issue.

In the presented use case, should a user expect that cocotb will be able to handle it out-of-the-box or should the user resort to extending the build flow as you suggest ?

from cocotb.

FWIW, #1707 is a relevant issue regarding the Makefiles.

from cocotb.

I don't see the problem? work is not a legal library name as of VHDL 2002, we aren't going to default to that. The build of the reg_b sources is not associated with a library and is called out in top as being in cell_lib, so of course it won't compile correctly.

You've pasted a bunch of stuff and said "it doesn't work", but you haven't explained what you expect the behavior to be, why, and what needs to be changed to make it work.

Based on your post, I can reason that you think that not specifying a library name when building a library should put the entities into a default library. IMO, this argument should instead be required. Building libraries are different than building a top-level design. I wanted them to be different methods originally, but that isn't what ended up happening. Instead, we need to force the two distinct methods into one and reject invalid calls.

from cocotb.

Nothing prevents us from separating the methods though, we always declared the Python runner as experimental.

from cocotb.

Sorry for being unclear with the initial question. I was expecting cocotb compilation to successfully compile the initial code as it was possible to do so with what I thought was an equivalent modelsim compilation script. I think in this case Modelsim is too permissive and/or too forgiving.

I have updated my example according to your feedback to give explicit libraries in all cases except the top level. Using the python runner works in this latest example, but there is still an issue with the Makefile flow.

There seem to be 2 issues at play :

1. All VHDL code is compiled first, including top level. Thus the needed Verilog are not compiled in the correct order
2. It does not seem possible to specify a compilation library for verilog files ( I would expect VERILOG_SOURCES_mylib to work ?)

from cocotb.