Full example of using Clash.Driver.Manifest?

[ge...@erdi.hu]

Hi, 

Is there an end-to-end example of using Clash.Driver.Manifest? I am currently using Clash.Main.main and then reading the file back, which is a really poor state of affairs. However, it works well in the sense of just taking a bunch of input and output directories, a module name, a choice of HDL to generate, and does everything. `mkManifest` looks quite intimidating in comparison.

Thanks,

Gergo

[Christiaan Baaij]

What are you hoping to do with it?

I'm asking because originally the `.manifest` file was only meant to be used by the Clash compiler: it was created to support multiple synthesis entries, also called multiple top entities.

I think the current idea is to use the `.manifest` for other purposes as well: to communicate information about the interface of the HDL that we generate, for consumption of tools processing Clash' generated HDL.

Hopefully Martijn (cc'd) can tell you more.

--
You received this message because you are subscribed to the Google Groups "Clash - Hardware Description Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clash-languag...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clash-language/e3c90053-ca25-4911-b453-f24599b24425n%40googlegroups.com.

[ÉRDI Gergő]

On Thu, 16 Sep 2021, Christiaan Baaij wrote:

> What are you hoping to do with it?

I am using manifest files in `clash-shake` to find all the generated HDL
file names that I need to include in the project I pass to the vendor
toolchain.

[Martijn Bastiaan]

I think the current idea is to use the `.manifest` for other purposes as well: to communicate information about the interface of the HDL that we generate, for consumption of tools processing Clash' generated HDL.

That's correct. For example, I'd like to strip out `-fclash-edalize` and replace it with a Python package reading the manifest file and passing the relevant info to Edalize.

which is a really poor state of affairs

There's a couple of things I'd like to change about the manifest data structure:

• To add ~type LocatedManifest = (FilePath, Manifest)
  
• transitiveDependencies should be :: [LocatedManifest]
• Add a field dependencies which only lists direct dependencies, not the transitive closure

Ideally, main (or rather a function with a more friendly API) would return [LocatedManifest].

What specifically are you missing right now?

Op do 16 sep. 2021 om 15:43 schreef ÉRDI Gergő <ge...@erdi.hu>:

[ÉRDI Gergő]

On Thu, 16 Sep 2021, Martijn Bastiaan wrote:

> What specifically are you missing right now?

I am not missing anything from the manifest files currently. My current
pipeline already uses the manifest files (to e.g. discover all generated
files); but the manifest files are generated by using Clash.Main.main
with the "--verilog" flag, then reading the manifest file back:
https://github.com/gergoerdi/clash-shake/blob/2ba0edd11f37fe516ea2d0f8783e845c615a6d0f/src/Clash/Shake.hs#L79-L89

I would like to replace that with some "real" Clash driver calls that
don't go through the filesystem.

[Alex McKenna]

> I would like to replace that with some "real" Clash driver calls that don't go through the filesystem.

I have something semi-related to this (I want something different, but it would also give you what you want) which I've wanted for a while but haven't had time to look at properly. Unfortunately I don't think I'll have so much time to work on it either in the near future, but I'll start a new discussion on GitHub soon(ish) to at least get the idea out there in the open for comments.

  - Alex