Vexriscv BRAM support

[apond308]

Motivate of the pull request

• To address an existing issue. If so, please provide a link to the issue:
• Breaking new feature. If so, please describe details in the description part.

Describe the technical details

What is currently done? (Provide issue link if applicable)

What does this pull request change?

• Added Vexriscv and Picorv32 benchmarks to OpenFPGA
• Added 1K bram/dff/dsp arch file
• Added 18 bit multiplier (before only had 36 bit)
• Added pmux to mux techmap to yosys bram_dsp_flow, avoids pmux errors

Which part of the code base require a change

• VPR
• Tileable routing architecture generator
• OpenFPGA libraries
• FPGA-Verilog
• FPGA-Bitstream
• FPGA-SDC
• FPGA-SPICE
• Flow scripts
• Architecture library
• Cell library
• Documentation
• Regression tests
• Continous Integration (CI) scripts

Impact of the pull request

• Require a change on Quality of Results (QoR)
• Break back-compatibility. If so, please list who may be influenced.

[tangxifan]

@apond308 In general, looks good. Just need to enhance testing.

[tangxifan]

Each file in this directory is binded to a specific architecture, so that for each architecture, we can customize the synthesis options to the most. Please avoid a generic naming. Suggest to rename this file to k4_frac_N8_tileable_adder_chain_dpram1K_dsp18_fracff_40nm_dsp_map.v

[apond308]

Wouln't that lead to redundancy though? If I have two architectures like this:

k4_frac_N8_tileable_adder_chain_dpram1K_dsp18_fracff_40nm_dsp_map.v
vs
k4_frac_N8_tileable_adder_chain_dsp18_fracff_40nm_dsp_map.v (no BRAM)

Wouldn't that lead to duplicate multiplier map code? Couldn't those two architectures just use a single dsp18 map since they both have the same multiplier design?

[tangxifan]

You are right. I believe it is time to rework this directory and create rules when adding new technology libraries for yosys.
My current plan is

• Each architecture has an independent set of technology library files, such as <arch_nam>_dsp_map.v, <arch_name>_bram_map.v etc. As such, it is easy for users to pick technology libraries because the rules are simple.
• To avoid duplicated codes, you may try to use symbolic links. For example, k4_frac_N8_tileable_adder_chain_dpram1K_dsp18_fracff_40nm_dsp_map.v contains the actual codes, while k4_frac_N8_tileable_adder_chain_dsp18_fracff_40nm_dsp_map.v is a symbolic link.
• We need to create separated directory for each architecture, and classify the files into different directories. As a result, it is easy to maintain. Otherwise, later on, when we 10+ architectures in the openfpga_yosys_techlib directory, it may become a mess.

Let me know what you think.

[apond308]

Oh so you are planning on having a directory (for example, k4_frac_N8_tileable_adder_chain_dpram1K_dsp18_fracff_40nm) with the openfpga arch, vpr arch, dsp_map, bram_map, etc all in that directory?

[tangxifan]

We do not put skywater task run in OpenFPGA repo. They are covered in the SOFA repository.
I see you have added new benchmarks. Can you create dedicated task-run for the picorv benchmarks?
The micro-benchmark regression test is a proper place to add these test cases.

OpenFPGA/openfpga_flow/regression_test_scripts/micro_benchmark_reg_test.sh

Line 19 in 223e06d

run-task benchmark_sweep/signal_gen --debug --show_thread_logs

[apond308]

Yes, I thought I deleted the skywater_openfpga_task symlink; I'll delete it.
And yes, I will create a task-run for the picorv.