Support SystemVerilog DPI

[imphil]

I'm trying to switch OpTiMSoC back to upstream fusesoc, and there are still a couple features we're missing. So I'll go through them and open issues and PRs one by one in the coming days -- brace yourself @olofk :-)

First is support for SystemVerilog DPI.

What we use right now (e.g. in https://github.com/optimsoc/sources/blob/master/external/extra_cores/cores/uartdpi/uartdpi.core) is the "section syntax" proposed by @wallento in https://github.com/olofk/fusesoc/pull/119/commits/539f123d0830cbe391f50f1bcedb7ad8ebc5e45d)

[dpi]
libs = util
src_files =
 src/uartdpi.c

Olof, in your review you said you'd prefer using filesets for this. I'm not sure what you actually meant. So before I update the patch for this, let's agree on a syntax.

Things we need:

• Ability to build multiple DPI libraries
• Each library consists of
  • a name
  • a set of files which should get compiled (c/c++ and headers)
  • a couple of additional options which get passed to the compiler (libraries, warning flags, etc.). This essentially ends up in the --additional-options flag in xsim.
  • optional: a work library

@wallento anything I forgot?

[olofk]

I was planning to clean up some things in CAPI1, but actually, I've been working on CAPI2 as a replacement and will do the big cleanup there, so I'm actually more ok now with adding the DPI section as is to CAPI1. I'm not sure exactly which degree of freedom we need for the DPI libraries, but I would expect that we need source files (with support for marking include files), libraries to link and a name just as you say. I'm wondering however if we should just pass optional options as they are, or if we should split them up into cflags and ldflags. I did some experiments with modelsim a while ago. I should dig them up. Not sure why we would need a work library. That should only be for VHDL, right?

[Fatsie]

Any WIP info on CAPI2 ? I may propose an idea or two myself. I'm thinking of the open source mantra: "Release early, release often" ;)

[Fatsie]

Actually I had an idea for a general solution which may solve this problem. It would be to attach a generator to a fileset. I was inspired by the coregen provider. As far as I can see this provider conflicts with the git provider for example so coregen cores can't be put on git. What I thought about is to change the following:

[fileset rom]
files =
 syn/xilinx/coregen/ROM80.vhd
 syn/xilinx/coregen/ROM80.mif[file_type=user]
file_type = vhdlSource

[provider]
name = coregen
script_file = syn/xilinx/coregen/ROM80.xco
project_file = syn/xilinx/coregen/Atlys.cgp
extra_files = bench/asm/TestBench.coe

to

[fileset rom]
files =
 syn/xilinx/coregen/ROM80.vhd
 syn/xilinx/coregen/ROM80.mif[file_type=user]
file_type = vhdlSource
generator = coregen
script_file = syn/xilinx/coregen/ROM80.xco
project_file = syn/xilinx/coregen/Atlys.cgp
extra_files = bench/asm/TestBench.coe

This way several coregen files can be combined in one core; or several DPI libraries. In this case the output files would not be stored next to the core; the coregen generator would ask the provider for syn/xilinx/coregen/ROM80.xco, syn/xilinx/coregen/Atlys.cgp, bench/asm/TestBench.coe and generate the files from it.

Default generator would be copy which copies the files retrieved from the provider.

What I did not think through yet is wether or how to connect output files from one generator as input to another generator.

[olofk]

@imphil Yes, I have plenty ideas for CAPI2 that I'm happy to share and get feedback on. The plan is also to release early and often, just as you say. I've already taken the first steps towards a refactoring so that CAPI1 and CAPI2 cores can live side by side. Next step after that is to make CAPI2 a subset of CAPI1 and add on features, while communicating that it's not stable yet.

[olofk]

@Fatsie Yes. You're actually spot on here. This is an idea that I have had for many years actually, but never gotten around to finish. Using the provider interface was an idea that was contributed as a user, and I see it as a stop-gap measure until generator support is properly implemented. You can read some of my original ideas here https://github.com/olofk/fusesoc/issues/75

[olofk]

Oh, the first comment was for @Fatsie as well. I'll bring you into the CAPI2 discussion

[Fatsie]

@olofk What do you think about a capi2 branch on github ? You could even announce this branch may be rebased on master at will

[olofk]

@Fatsie Absolutely. Want to do some preliminary refactoring first though, to bring down the amount of rebasing slightly. Progress is currently slowed down a bit as I decided to add unit tests now before changing any code

[imphil]

@olofk good to know you're working on CAPI2, I think it's a good time to apply the lessons learned. I think for now I'll go the following route:

• Just fix the optimsoc-bundled fusesoc version, and not upstream the remaining changes. It works for us at the moment.
• Let us know if you're ready with an early preview version of fusesoc with CAPI2. I'll then take a look and see if we can port our existing core files to it, testing all the new stuff on a larger real-world example.