Support a Vivado IP-packaging flow about edalize HOT 2 OPEN

Appreciate you reaching out. I think this does need some planning and scoping. E.g., is the intention to create RTL from a bd file or are you looking at some kind of automatic packaging as well? It's been a while since I last used this flow myself so my memory of the details are a bit rusty, but I think some people are using FuseSoC/Edalize with their own bd files and adding some custom tcl to do the RTL generation on the fly. Let's iterate on this so that I understand the use case a bit better.

from edalize.

Our use-case doesn't involve BDs specifically, but rather automatically packaging our IPs so users can generate XCIs.

As a specific example: we have a device we communicate with over a high-speed serial link, and we have the top-level for this device and the IP to communicate with it. Both managed by FuseSoC. Workflow-wise:

• For the top-level, the workflow is good—FuseSoC can automatically produce the bitstream for us and flash it
• For the IP, to produce an archived packaged IP, we have to get FuseSoC to produce its scratch directory containing all the RTL, manually update the component.xml using the Vivado GUI, enable the option to produce an archive, then click the right buttons in the GUI to produce the archive

The IP itself consists of a number of our internal FuseSoC cores. Ideally this is the form we'd package them in, but there are two obstacles to this: (1) our users don't use FuseSoC, and (2) our internal cores are generically named, so we can't easily make sure there won't be a conflict between module names.

By default, FuseSoC has most of the information we copy over into the IP packager. Adding the rest as extra properties in the .core file isn't a hassle. But what it doesn't nicely support at the moment is a flow that feeds this information into Vivado. I'll be honest at this point and say I haven't yet figured out the exact details, but I imagine most of it is driven through the (mildly undocumented) ipx::* Tcl commands. Maybe there'll be some XML generation in there.

Once we have the archive, our users can put its contents in their IP repo and specialise our parameterised IP using create_ip as they would for anything out of the Vivado IP catalogue.

So my rough thinking on how this breaks down is:

• Edalize:
  • Expose places to put all the metadata (VLNV, compatibility, IP categories, etc.)
  • Interpret tags on files to produce the correct directory structure for synth vs. sim filesets
  • Drive Vivado to produce the component.xml that describes the package + the archived package
• FuseSoC:
  • Do its usual thing of sourcing all the files/dependencies for the cores
  • Support this packaging flow, with a mix of automatic (e.g. VLNV) and user-defined data (tags, etc.) passed in Edalize
  • Poke Edalize in the right way to run its packaging flow

Is there anything I've left unclear there?

from edalize.