-
Notifications
You must be signed in to change notification settings - Fork 388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a single manifest file for synthesis and simulation #239
Comments
Let me add my thoughts on this topic:
First of all I think the manifest format (VCS command list?) you have proposed is insufficient because it does not track dependencies. For example the This is what FuseSoC's core files (example) also try to solve this issue, but unfortunately there is also no way to declare external dependencies, see also this. Lowrisc is using these manfest files succesfully with fusesoc to generate simulation and synthesis scripts. I think you proposed command file list doesn't capture enough information to be useful. |
We use an IP-XACT description of the block. We take the FPU, tech libraries, core and debugger and use Git sub modules to link them together. We then treat that combination as the IP. We could have described each individually in IP-XACT but chose not to. We then add some groups to the file set and use an internal tool to generate the correct file lists/scripts needed (pulling only the files listed for the desired group): <ipxact:fileSet>
<ipxact:name>core</ipxact:name>
<ipxact:description>RI5CY core design files.</ipxact:description>
<ipxact:group>rtl</ipxact:group>
<ipxact:group>synthesis</ipxact:group>
<ipxact:group>fpga</ipxact:group>
<ipxact:file>
<ipxact:name>riscv/rtl/include/apu_core_package.sv</ipxact:name>
<ipxact:fileType>systemVerilogSource</ipxact:fileType>
</ipxact:file>
<ipxact:file>
<ipxact:name>riscv/rtl/include/riscv_defines.sv</ipxact:name>
<ipxact:fileType>systemVerilogSource</ipxact:fileType>
</ipxact:file> |
Hmmm. This discussion is not converging on a solution, and its important that we find one quickly. I would like to suggest a conference call instead. I am not available tomorrow (February 25), but am otherwise available any time. Would sometime in the early afternoon (CET) on Wednesday, February 26 work for everyone? |
During a conference call on 2020-02-27 with @davideschiavone, it was decided to start by creating a manually generated "flist" style manifest. This has been done: see pull-request #245. Having this in place will enable early synthesis trials. As the trials progress I will investigate the use of bender for manifest definitions. |
Our preference would be to use IP-XACT. |
Hi @Silabs-ArjanB, I have no preference one way or another. However, if anyone wants to use a particular solution (IP_XACT, Bender, YAML, etc.), they must also contribute:
They must also 'sell' the idea to the team, but its safe to say that will be easy if the proposal is seen to be workable. We currently have an ugly, manually generated manifest. Unless an AC steps up to provide a better solution, that is what we will use. |
I just stumbled across this and would very much recommend using FuseSoC core description files. FuseSoC is becoming increasingly used in the industry and academia. There are already 500-600 publicly available IP cores (that I'm aware of) and many more within companies. The file format is documented, there is backend support for more than 20 different EDA tools and it has basic IP-XACT integration. In fact, much of FuseSoC's design is inspired by The good, the bad and the outright madness of IP-XACT |
Hi, |
Note: This discussion is continued in https://mattermost.openhwgroup.org/all-users/channels/twg--cores--manifest |
Currently, a YAML file and scriptware is used to generate synthesis scripts for CV32E40P. As far as I am aware, the scripts that process the YAML are not documented, and may not be universally used. In addition, these YAML+scripts are not used for simulation. This can lead to differences between what is begin synthesized and what is being simulated, and this situation must be avoided.
Two possible solutions:
An example manifest file (solution #2) is below:
The text was updated successfully, but these errors were encountered: