Add cocotb framework

[rw1nkler]

This PR adds the Cocotb framework and simple driver and monitor classes to handle XLS channels in the cocotb simulation. A simple example is also given to verify the added functionality.

CC @proppy

[proppy]

I'm curious if you took a look at the existing iverilog integration ? https://github.com/google/xls/blob/835f742a20fc0a2e82aa1b57e9c3923ab3786dbf/xls/simulation/simulators/iverilog_simulator.cc#L45

[rw1nkler]

I'm curious if you took a look at the existing iverilog integration ?

https://github.com/google/xls/blob/835f742a20fc0a2e82aa1b57e9c3923ab3786dbf/xls/simulation/simulators/iverilog_simulator.cc#L45

@proppy Do you have something specific in mind? We moved the cocotb integration almost entirely to Bazel HDL rules so that we don't have to add (too much) code to XLS.

[proppy]

Do you have something specific in mind? We moved the cocotb integration almost entirely to Bazel HDL rules so that we don't have to add (too much) code to XLS.

I was wondering if it would make sense to expose a similar functionality to drive cocotb from the XLS simulator interface https://github.com/google/xls/blob/835f742a20fc0a2e82aa1b57e9c3923ab3786dbf/xls/simulation/verilog_simulator.h#L40 and the C++ test framework integration https://github.com/google/xls/blob/835f742a20fc0a2e82aa1b57e9c3923ab3786dbf/xls/simulation/verilog_test_base.h#L9 but that would be challenging as I'm not sure cocotb expose any external facing API (and that would be redundant with the cocotb testbench itself).

I'm also curious however if the IR interpreter/JIT could fit with the https://docs.cocotb.org/en/stable/library_reference_c.html?highlight=GPI interface, so that you could drive DSLX/IR testbenches from cocotb.

[rw1nkler]

I'm also curious however if the IR interpreter/JIT could fit with the https://docs.cocotb.org/en/stable/library_reference_c.html?highlight=GPI interface, so that you could drive DSLX/IR testbenches from cocotb.

Cocotb is designed to interact directly with the RTL simulators and because of that, it relies on concepts like clock cycles which are not available in the XLS. I wonder whether this kind of integration is possible for DSLX/IR and if it would be beneficial.

[proppy]

Cocotb is designed to interact directly with the RTL simulators and because of that, it relies on concepts like clock cycles which are not available in the XLS. I wonder whether this kind of integration is possible for DSLX/IR and if it would be beneficial.

https://github.com/google/xls/issues/724 mentioned the ability to produce a schedule proto independently of running codegen, with that information it might be possible to run multiple concurrent IR JIT execution for each pipeline stage and produce a clock-aware and timing accurate simulation?

[rw1nkler]

Converted to draft while waiting for https://github.com/hdl/bazel_rules_hdl/pull/175. If I manage to merge that PR I will update the git SHA of Bazel HDL Rules in this PR and mark it as "ready for review".

[rw1nkler]

@proppy Can you take another look? I have changed the link to Bazel HDL Rules to a forked repository, but I will update the PR with a proper link once the corresponding PR in Bazel HDL Rules is merged.

[proppy]

can we remove the draft label if it's ready for review?

[proppy]

@rw1nkler did you have a chance to take a look at my last round of comments?

[rw1nkler]

I looked at your comments and applied them to this PR. Also, I asked the Cocotb maintainers for more details regarding the Cocotb-pytest integration.

[proppy]

I asked the Cocotb maintainers for more details regarding the Cocotb-pytest integration.

do you have a pointer to the conversation?

[rw1nkler]

Sure, here is the link: https://github.com/cocotb/cocotb/issues/3369

Unfortunately, it turned out that the release didn't include my changes to cocotb. They will probably be added to the next release

[proppy]

Was there a new release including those change? If not, maybe showing that integration in a separate repo similar to https://github.com/antmicro/xls-cosimulation-demonstrator would be easier? wdyt?

[rw1nkler]

The integration already worked on the previous version of the Bazel environment, which allowed reusing the non-hermetic clang toolchain for building cocotb. To make things right in a hermetic environment, we have to either wait for the official release, build our version separately and expose it as an artifact, or provide rules for building the cocotb package inside the Bazel workspace.

[proppy]

Should we close this in favor of #1616?

[rw1nkler]

Should we close this in favor of https://github.com/google/xls/pull/1616?

A more detailed answer has been provided in https://github.com/google/xls/pull/1616#issuecomment-2376025234

[rw1nkler]

Closing in favor of #1616, as requested in https://github.com/google/xls/pull/1616#issuecomment-2387273360