search

olofk / fusesoc

Package manager and build abstraction tool for FPGA/ASIC development
BSD 2-Clause "Simplified" License
1.2k stars 244 forks source link

Provide generators more information and allow them to modify core data #359

Open GCHQDeveloper560 opened 4 years ago

GCHQDeveloper560 commented 4 years ago

Generators are currently provided very little information, primarily their own parameters and files_root for their core. As discussed in fusesoc/fusesoc-generators#2 generators could benefit from having access to and potentially modifying much more information about the target. There appear to be several other similar issues including #250, #251, and lowRISC/opentitan#79.

Given the diverse use cases and the potential of generators to change the core data (e.g. changing toplevel for the #250 use case) it seems difficult to just add a few items to the YAML passed to the generator. Does it make sense to just present generators with the (current) full set of data being developed for passing to Edalize, or is this too much? Is there a simpler approach? Are generators being used outside FuseSoC where this close connection would be a problem?

imphil commented 4 years ago

Please have a look at https://github.com/lowRISC/fusesoc/commits/generators. There's a commit in there that passes the full list of cores and files to a generator. I'm currently trying to use that to generate cores depending on other cores found by fusesoc (I can link to a code example once I've pushed it in the coming days).

GCHQDeveloper560 commented 4 years ago

I'll look forward to the example. It sounds like this is a more complex case than I had considered where a generator is playing a role in libraries and dependency resolution rather than just modifying the resulting EDAM.

For the case in fusesoc/fusesoc-generators/pull/2 I think what you've added would let the generator find the files for the current core, but I don't see any information about the top. I think you could repeat work and parse the core file to find that, but that seems unfortunate. Then you could parse all of the core files and see which one contains the top and do the virtual pin generation. You could obviously add more data about each core like toplevel to the dict you're generating, but would it make sense to pass the whole Core object rather than the bits you've picked off?

Are you planning to change ttptttg_data to include more information or the entire EDAM state? Any need to change the data, like a wrapper generator that might want to change top to top_wrapped?