CocoTB and SystemVerilog's Interfaces

[kirill-bessonov]

cocotb == 1.5.0 operating system == Linux x64 simulator == QuestaSim 64 10.7f Python == python3 RTL language == SystemVerilog

Hello,

Top-level of project contains AXI Interface (by Interface I mean SystemVerilog's Interface feature). When I try to compile the project in Questa, I get the following error: "Fatal: (vsim-3695) The interface port 'AXI' must be passed an actual interface." If I expose all signals as separate wires - everything works just fine. I would like to know if there is a better solution?

[ktbarrett]

Are you sure this is a cocotb issue and not a Questa issue?

[kirill-bessonov]

It's more like "Usage of cocotb with QuestaSim" issue.

[ktbarrett]

It's more like "Usage of cocotb with QuestaSim" issue.

I'm not sure what you mean. Is there something the makefile's build process should be doing to account for this? If it's an issue with Questa not liking your code there is nothing we can do.

[kirill-bessonov]

What I am asking is: Can cocoTB handle Interfaces in the top level of the design or not? All cocoTB examples expose only "Verilog-style" buses and separate signals. There is no examples that utilize Interfaces in top level of the design.

[ktbarrett]

Cocotb is a VPI/VHPI/FLI module that is loaded during simulation. It has nothing to do with compilation. If your code is failing to compile the problem is with your simulator or your code.

[kirill-bessonov]

Yes. And this VPI/VHPI/FLI module drives stimuluses to DUT. But how it can drive Interface that hasn't been connected to anything? I mean top-level of conventional SystemVerilog testbench has an instance of particular Interface that connects driver and DUT. CocoTB creates connections while executing ".py" script. But how can PY script create Interface instance? There is "vsim-3695" error without it.

[marlonjames]

Check with Questa support about interfaces as top-level ports. It may not be supported.

[kirill-bessonov]

How one of the main SV's feature could not be supported?) It is just a matter of scale. I need to test a small part of the project that has only AXI interface. With conventional SV testbench there is no problem because TOP of testbench has no ports at all. All Interface's instances are inside. However, DUT itself has it. TOP file just connects Driver and DUT via Interface instance. The problem with CocoTB is that "TOP" file isn't something that one can change manually. It changed via PY script i.e. all connection are made in PY script.

[imphil]

@kirill-bessonov Just for my understanding: you have a top-level file that uses SystemVerilog interfaces as ports? And your simulator (Questa) complains when compiling this code? Things to check:

• Check if Questa supports interfaces at the toplevel. Simply compile the SystemVerilog file as toplevel in Questa directly, without cocotb. I suspect you'll get the same error as you mentioned with cocotb.
• If Questa does not support SV Interfaces at the toplevel, you'll need to use a wrapper to convert the SV Interfaces into a supported set of ports. Most likely, that's either a struct or a plain set of vectors.
• Alternatively, you can use a toplevel wrapper with no toplevel ports at all and access the interfaces a level below that. I'm not quite sure, however, how Questa maps accesses to interfaces from cocotb (through VPI).

As @ktbarrett said, if your simulator cannot compile the source file, there's nothing cocotb can do. But you can easily wrap the code to create "normal" signals from the interface; that's guaranteed to work.

[marlonjames]

How one of the main SV's feature could not be supported?

Top-level module ports may not be allowed to be interfaces.

The problem with CocoTB is that "TOP" file isn't something that one can change manually.

This is not correct. cocotb can put values on top level ports as most simulators support that feature. This allows the user to not have to create a separate top-level for the testbench, but it is not mandatory.

You can create a separate top-level wrapper with plain signals broken out. cocotb may not support interfaces through VPI, but I'm not certain either way.

[kirill-bessonov]

Just checked - Questa is capable of compiling DUT with Interfaces separately. The error occurs when trying compile with CocoTB attached. May be problem lies in generated TOP of whole testbench? Indeed, there is no instantiated Interfaces. If I could manually instantiate "dummy" interface of appropriate type inside this TOP-of-testbench file, problem would be probably gone. But I have no idea where to look. And I doubt that this is implementable idea. @marlonjames , The wrapper-idea is the only thing that is working right now, but it is kinda ruin whole idea of SV Interfaces.

[kirill-bessonov]

@imphil , May be third solution will do, I need to try...

[ktbarrett]

generated TOP

There is no generated top, I'm not sure what you talking about. I think you may be mistaken as to how cocotb works. cocotb can only deposit values onto existing signals and connections, it cannot create new connections or instantiate new entities. For cocotb to talk to a SV interface, the end of the interface needs to be instantiated in a top.

The wrapper-idea is the only thing that is working right now

This is the only solution to your problem.

[marlonjames]

So even if Questa compiles the DUT with an interface, are you able to start a normal simulation with that as the top-level? I'm not sure how you would provide stimulus in that case.

In general cocotb allows placing stimulus on the top-level input ports. In my mind these are the outstanding questions:

1. Does Questa support starting a simulation with a top-level containing an interface port?
2. Does cocotb support SystemVerilog interfaces? A. vpiInterface support was added in https://github.com/cocotb/cocotb/pull/2683