Add support for import EDAM files

[olofk]

FuseSoC and some newer languages like Silice and CLaSH as well as the TerosHDL IDE can export EDAM (EDA metadata) files to describe a design. If SiliconCompiler could read these files it would make it very easy for existing designs to alternatively use SiliconCompiler instead of Edalize for the tool flow

[aolofsson]

It's good to finally be out in the open! Great input. I started looking at creating readers/writers for different formats including fusesoc, but I think it would be better if we could eventually agree to merge on one format if we are all passing the same information around. It's just day one for us, so first we want to get an understanding for how far off the mark we are with the schema. Converting json to json is not a big deal, so I am sure we can create the readers/writers if needed.

[olofk]

Very much agree and I believe EDAM is just the kind of format for interoperability. As mentioned, it is used to pass information into Edalize, but I am also just about to land a reachitectured Edalize (which I drafted here last year) which has a clear separation between tools and the overarching flow, which is what SiliconCompiler looks like after a first look too. The advantage of passing EDAM like that is that it makes it easier to create arbitrary tool flows. A typical example being netlist simulations where you first want to run a half FPGA/ASIC flow followed by a simulator. I think it could save us both a lot of work if we had a common tool interface. I see we are already implementing slightly different subsets of tools which is unfortunate not least for the overlap where it would be nice to spend more time on higher level functionality instead

[umarcor]

but I think it would be better if we could eventually agree to merge on one format if we are all passing the same information around

Let me drop a reference to pyEDAA.ProjectModel (part of EDA²), a set of reusable Python classes to pass project information around. We expect to be able to read .core (YAML) and EDAM files (dictionaries) into ProjectModel. Currently supported readers are .pro (OSVVM) and .xpr (Vivado).

implementing slightly different subsets of tools which is unfortunate not least for the overlap where it would be nice to spend more time on higher level functionality instead

In January, we expect the CLIAbstraction and CLITool layers of EDA² to be ready to use, so we can reshape the "workflow focused projects" to focus on the high level functionality. See EDA² Conceptual Model and OSVB: Tool.

By the way, there are some Gource videos in umarcor/umarcor/releases/tag/gource-videos showing the history of multiple repos in the open source EDA ecosystems. Video EDAA-Workflows includes multiple Python based tools: CoCoTb, FuseSoC, Edalize, fsva, PyFPGA, pyIPCMI, SiliconCompiler, tsfpga, VUnit, Xeda and OSVVM-Scripts,

[aolofsson]

@umarcor Thanks for sharing the links. Cool stuff! Any comments on the issue, compilation configuration?

[umarcor]

Any comments on the issue, compilation configuration?

@aolofsson I'm not sure I understand the question. Can you please reword it?

[olofk]

I made a PoC here with FuseSoC creating an EDAM which is then read and turned into the SiliconCompiler schema. Perhaps an enhanced version of the EDAM reading logic could be turned into a read_edam function in SiliconCompiler analogous to read_manifest

[nmoroze]

I think adding a read_edam() importer would be a nice addition! I haven't had a chance to take a particularly close look, but is the idea that the parameter this function takes in would be whatever is in edam at this point in the ZeroSoC PoC?

# Create EDAM contents
edalizer.create_eda_api_struct()

edam = edalizer.edalize

I guess origin of this question is: to what extent is code above that point in the ZeroSoC example boilerplate that we could abstract away vs project-specific setup?

[mithro]

FYI - @proppy