Plans for Version 2022.01

[quark17]

The next planned release for BSC will be version 2022.01 to be finalized in January 2022, as the name suggests. Please comment here with your opinions on what should (or should not) be included in that release.

Features will only make it in if a PR is submitted and merged, so also consider volunteering to implement any of the items mentioned here.

[quark17]

At the top of my priorities would be:

• Supporting Verilator linking with bsc -vsim verilator, which is covered by two issues:

  • Issue Add automated linking for Verilator #170
  • Issue Optionally generate DPI instead of VPI #169

• Cleanups to the generated Verilog and Verilog libraries

  • As mentioned in various issues and PRs:
    • PR Slightly modernize compiler Verilog output  #294
    • Issue Bluespec-emitted Verilog makes Yosys unhappy #118
    • PR prims: do some cleanups #295
    • Issue Verilog primitives should probably be renamed #139
  • Specifcally, the following points:
    • Use (* parallel_case *) instead of // synopsys parallel_case and the same for full_case
    • Change the synopsys translate pragmas into ifndef of SYNTHESIS (or BSV_SYNTHESIS); but, for initial blocks, just leave them off (as they are guarded with BSV_NO_INITIAL_BLOCKS)
    • Use @* for the sensitivity list of combinational always blocks
    • Rename all the BSV_ macros to start with BSC_
    • Rename the Verilog primitives to start with __ or __BSC_ or similar
    • Combine the different versions of each Verilog primitive into one file, using new macros like VIVADO to select for the specific version for a tool, rather than having separate files
    • Remove the -v95 flag

• Cleanup the conflation of Gnu vs BSD, ELF vs Mach-O, Darwin vs Linux, etc as brought up by PR Enable building on FreeBSD. #260

• I would also really love to see Use SMT to resolve numeric provisos where substitions are learned #318 implemented -- removing the last difficulty in using numeric provisos -- but I don't have hope that anyone will have time to finish it by January

[quark17]

I would also add:

• Eliminate the need for setting LD_LIBRARY_PATH in the tool wrappers
  • There is a PR for this (Load SAT libs from dir relative to exe using linker flags #163) but in the discussion there, we figured that a better way to address it would be by using dlopen to load a specific libray. That approach would have the benefit of eliminating the need for a stub; would mean that the install of the library need only create one file (not multiple copies or links with/without the version number); and would not introduce a new location in the source where BLUESPECDIR's relative path is hardcoded.
  • See also this comment for other related PRs and issues, such unvendoring Yices/STP and using SMT-lib as the API