CAPI2: DPI support

[imphil]

CAPI2 is now established, but one thing that's missing from CAPI1-days is the ability to compile DPI libraries. What I'm looking for is:

• Specify a set of C/C++ source files.
• These files are compiled into a shared object. This compilation can happen through a compiler provided by a simulator, or through the system compiler.
• This library is then passed to a simulator to be used there.

This was first discussed in #138 when CAPI2 wasn't ready yet.

It's a slightly tricky problem as there are multiple ways to interact (or not interact) with the simulator(s).

@olofk have you thought about that already and an idea how to approach it?

[olofk]

Thanks for starting this. Yes, it's a tricky problem since it comes with more freedom than VPI allowed. In general I think we should look at what was good and bad with the current VPI support and evolve from there. I would very much like to have input from actual DPI users, as I'm not a heavy user myself. I would like to see some real-world examples to know what users expect. From my perspective we need at least a name, source/header files and compile/link flags. Is that enough to start with? Do we need tool-specific options or should those go together with the other options in the tools section?

[Jbalkind]

What if DPI compilation was a generator core in the standard library?

[olofk]

If think a generator would be a good start. That way we can have some more freedom to iterate on the design without committing to anything. Using generators as a halfway home was actually an intended use case, so let's try it. The obvious drawbacks are that generators have less knowledge of the core and I think we might need to do a generator per EDA tool, but perhaps that's totally ok to begin with

[imphil]

I did experiment with this a bit today, and a generator might not be the solution.

I tried to create a generator that takes input .c and .h files, and compiles them into a .so file.

The problem: most DPI C code includes the "svdpi.h" file. This header file is part of the SV standard and shipped with all simulators. At the time when fusesoc is run, we don't know the simulator yet and even if we'd know it, we wouldn't know where the specific simulator stores its svdpi.h file to pass an appropriate include path to gcc.

To resolve the svdpi.h file issue, we have two options:

1. Require users to ship their own svdpi.h file, or ship one in fusesoc.
2. Do the DPI compilation in edalize in a simulator-specific way. This can mean that the simulator performs the compilation itself (the big-3 simulators bundle GCC for that reason), or that we need to do it ahead of time (probably needed for Verilator in the longer run)

Problem 2: Once you have a .so file, you need to instruct the simulator to (a) link the simulation to the .so file, and (b) link in all other library dependencies into the executable. So we need to pass -lxxx flags to the simulator.

To resolve that we again need edalize support.

Taking those two problems together, I think generators won't do the trick. I'll look into a more declarative solution next, which involves extending fusesoc and edalize.

[olofk]

Do you think a DPI section (like the VPI section) would still work? If so, what options would we need? Loading libraries, I guess. Specifying source file(set)s... what else? Do we also need to set tool-specific custome options to be passed to GCC. In that case, should we add this as tool-specific backend options rather than adding them to the DPI section?

[nbdd0121]

Problem 1 seems to be a non-issue. DPI is meant to be ABI compatible, so a shipping a copy with FuseSoC would just be fine.