Create a single manifest file for synthesis and simulation

[MikeOpenHWGroup]

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:

1. Standardize and document the YAML and scripts and enforce their use for all synthesis, simulation, etc. manifests.
2. Create a single manifest file and enforce its usage for all synthesis, simulation, etc.

An example manifest file (solution #2) is below:

//`define SYNTHESIS

+incdir+${DESIGN_RTL_DIR}/include

${DESIGN_RTL_DIR}/include/apu_core_package.sv
${DESIGN_RTL_DIR}/include/fpnew_pkg.sv
${DESIGN_RTL_DIR}/include/riscv_defines.sv
${DESIGN_RTL_DIR}/include/riscv_tracer_defines.sv
${DESIGN_RTL_DIR}/riscv_if_stage.sv
//${DESIGN_RTL_DIR}/riscv_tracer.sv
${DESIGN_RTL_DIR}/cluster_clock_gating.sv
${DESIGN_RTL_DIR}/riscv_cs_registers.sv
${DESIGN_RTL_DIR}/riscv_register_file.sv
${DESIGN_RTL_DIR}/riscv_load_store_unit.sv
${DESIGN_RTL_DIR}/riscv_id_stage.sv
${DESIGN_RTL_DIR}/riscv_decoder.sv
${DESIGN_RTL_DIR}/riscv_compressed_decoder.sv
${DESIGN_RTL_DIR}/riscv_fetch_fifo.sv
${DESIGN_RTL_DIR}/riscv_prefetch_buffer.sv
${DESIGN_RTL_DIR}/riscv_prefetch_L0_buffer.sv
${DESIGN_RTL_DIR}/riscv_L0_buffer.sv
${DESIGN_RTL_DIR}/riscv_hwloop_regs.sv
${DESIGN_RTL_DIR}/riscv_hwloop_controller.sv
${DESIGN_RTL_DIR}/riscv_mult.sv
${DESIGN_RTL_DIR}/register_file_test_wrap.sv
${DESIGN_RTL_DIR}/riscv_int_controller.sv
${DESIGN_RTL_DIR}/riscv_ex_stage.sv
${DESIGN_RTL_DIR}/riscv_alu_basic.sv
${DESIGN_RTL_DIR}/riscv_alu_div.sv
${DESIGN_RTL_DIR}/riscv_alu.sv

${DESIGN_RTL_DIR}/riscv_pmp.sv
${DESIGN_RTL_DIR}/riscv_apu_disp.sv
${DESIGN_RTL_DIR}/riscv_controller.sv

${DESIGN_RTL_DIR}/riscv_core.sv

[bluewww]

Let me add my thoughts on this topic: I'm currently aware of several manifest formats that are going around:

• fusesoc's core files (by OlofK, used by lowrisc)
• src_files.yml and ips_list.yml by IPapproX (ETH)
• bender.yml by bender (ETH, kinda a successor to IPapproX)
• others like IP-XACT. I don't have much experience with those maybe some can chime in.

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 ${DESIGN_RTL_DIR}/include/fpnew_pkg.sv is not part of the cv32e40p and is available in https://github.com/pulp-platform/fpnew.git.

This is what bender.yml and src_files.yml/ips_list.yml solve: they describe the IPs this IP depends on and where they can be fetched, though as you have noted there is no formal description as of today (rather implied by the parsers of these tools). bender.yml and src_files.yml/ips_list.yml also allow you to define file groups such as e.g. FPGA/RTL simulation/Synthesis/TB specific files. TB specific files are obviously not of interest in this project due to the strict separation of verification and RTL environment (which by the way, is opposite to how lowrisc does it where mono repos are king). Both bender and IPapproX generate synthesis and simulation scripts from these manifest files, though IPapproX is really specific to the PULP project and not generally ususable.

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.

[jm4rtin]

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>

[MikeOpenHWGroup]

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?

[MikeOpenHWGroup]

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 https://github.com/openhwgroup/cv32e40p/pull/245.

Having this in place will enable early synthesis trials.

As the trials progress I will investigate the use of bender for manifest definitions.

[Silabs-ArjanB]

Our preference would be to use IP-XACT.

[MikeOpenHWGroup]

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:

• configuration files to define the manifest;
• scriptware to process them into something that synthesis and simulation can use;
• documentation (a README.md will suffice) to allow others to use the above to create manifests for other purposes e.g. linting, formal methods, etc.)

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.

[olofk]

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

[MikeOpenHWGroup]

Thanks for this @olofk. I like your suggestion so much that I have taken the liberty of assigning this issue back to myself.

@all, I won't be able to investigate this until next week, but will update this issue before end of the day 2020-05-29.

[wallento]

Hi, I have it mostly done for the verilator simulation, because I am using it in another context (along with ibex and ariane) and fusesoc streamlines the usage fortuantely. There is an issue with FuseSoC (handling of incdirs) that I already addressed to @olofk and he promised to come up with a fix soon, will coordinate with him and create the PR. Actually, those are PRs, because in the ideal world fpnew and its own dependencies would provide their own core file (like in IP-XACT), so I will need to land the dependency core files before. Will link to my branches here soon. Cheers, Stefan

[Silabs-ArjanB]

Note: This discussion is continued in https://mattermost.openhwgroup.org/all-users/channels/twg--cores--manifest