I'm getting a bsc

imperative statement (not BVI context)make[3]: *** [Makefile:25: /build/source/build/bsvlib/PreludeBSV.bo] Error 1

error when building 11f9a729fe5bb301f0899d3497e79e004a047e37 patched with https://patch-diff.githubusercontent.com/raw/B-Lang-org/bsc/pull/18.patch on NixOS

Full Log

/build/source/inst/bin/bsc -stdlib-names -bdir /build/source/build/bsvlib -p . -vsearch /build/source/build/bsvlib -no-use-prelude Prelude.bs
Warning: "Prelude.bs", line 975, column 19: (P0223)
  Definition of `a' is not used.
Warning: "Prelude.bs", line 1026, column 35: (P0102)
  Declaration of `x' shadows previous declaration at "Prelude.bs", line 1022,
  column 8
Warning: "Prelude.bs", line 1026, column 37: (P0223)
  Definition of `xs' is not used.
Warning: "Prelude.bs", line 1033, column 24: (P0102)
  Declaration of `x' shadows previous declaration at "Prelude.bs", line 1031,
  column 14
Warning: "Prelude.bs", line 1051, column 11: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 1153, column 6: (P0223)
  Definition of `n' is not used.
Warning: "Prelude.bs", line 1168, column 5: (P0223)
  Definition of `f' is not used.
Warning: "Prelude.bs", line 1179, column 9: (P0223)
  Definition of `n' is not used.
Warning: "Prelude.bs", line 1266, column 19: (P0223)
  Definition of `a' is not used.
Warning: "Prelude.bs", line 1266, column 21: (P0223)
  Definition of `i' is not used.
Warning: "Prelude.bs", line 1357, column 19: (P0223)
  Definition of `a' is not used.
Warning: "Prelude.bs", line 1357, column 21: (P0223)
  Definition of `i' is not used.
Warning: "Prelude.bs", line 1378, column 8: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 1378, column 10: (P0223)
  Definition of `y' is not used.
Warning: "Prelude.bs", line 1489, column 19: (P0223)
  Definition of `a' is not used.
Warning: "Prelude.bs", line 1532, column 7: (P0223)
  Definition of `s_d' is not used.
Warning: "Prelude.bs", line 1604, column 30: (P0102)
  Declaration of `x' shadows previous declaration at "Prelude.bs", line 1602,
  column 19
Warning: "Prelude.bs", line 1637, column 19: (P0223)
  Definition of `a' is not used.
Warning: "Prelude.bs", line 1657, column 11: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 1694, column 31: (P0102)
  Declaration of `x' shadows previous declaration at "Prelude.bs", line 1692,
  column 20
Warning: "Prelude.bs", line 1820, column 15: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 1855, column 15: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 1868, column 15: (P0102)
  Declaration of `x' shadows previous declaration at "Prelude.bs", line 1862,
  column 6
Warning: "Prelude.bs", line 1891, column 15: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 1904, column 15: (P0102)
  Declaration of `x' shadows previous declaration at "Prelude.bs", line 1898,
  column 6
Warning: "Prelude.bs", line 2058, column 8: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 2058, column 10: (P0223)
  Definition of `y' is not used.
Warning: "Prelude.bs", line 2059, column 11: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 2060, column 8: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 2060, column 10: (P0223)
  Definition of `y' is not used.
Warning: "Prelude.bs", line 2061, column 8: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 2061, column 10: (P0223)
  Definition of `y' is not used.
Warning: "Prelude.bs", line 2062, column 8: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 2062, column 10: (P0223)
  Definition of `y' is not used.
Warning: "Prelude.bs", line 2075, column 16: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 2076, column 19: (P0223)
  Definition of `a' is not used.
Warning: "Prelude.bs", line 2076, column 21: (P0223)
  Definition of `i' is not used.
Warning: "Prelude.bs", line 2275, column 8: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 2275, column 10: (P0223)
  Definition of `y' is not used.
Warning: "Prelude.bs", line 2276, column 11: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 2277, column 8: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 2277, column 10: (P0223)
  Definition of `y' is not used.
Warning: "Prelude.bs", line 2278, column 8: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 2278, column 10: (P0223)
  Definition of `y' is not used.
Warning: "Prelude.bs", line 2279, column 8: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 2279, column 10: (P0223)
  Definition of `y' is not used.
Warning: "Prelude.bs", line 2292, column 16: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 2293, column 19: (P0223)
  Definition of `a' is not used.
Warning: "Prelude.bs", line 2293, column 21: (P0223)
  Definition of `i' is not used.
Warning: "Prelude.bs", line 2659, column 16: (P0223)
  Definition of `p' is not used.
Warning: "Prelude.bs", line 3154, column 16: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 3169, column 9: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 3169, column 11: (P0223)
  Definition of `y' is not used.
Warning: "Prelude.bs", line 3170, column 9: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 3170, column 11: (P0223)
  Definition of `y' is not used.
Warning: "Prelude.bs", line 3171, column 9: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 3172, column 9: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 3407, column 17: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 3411, column 22: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 3411, column 24: (P0223)
  Definition of `xs' is not used.
Warning: "Prelude.bs", line 3425, column 18: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 3439, column 32: (P0102)
  Declaration of `xs' shadows previous declaration at "Prelude.bs", line 3431,
  column 21
Warning: "Prelude.bs", line 3439, column 32: (P0223)
  Definition of `xs' is not used.
Warning: "Prelude.bs", line 3440, column 30: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 3440, column 32: (P0102)
  Declaration of `xs' shadows previous declaration at "Prelude.bs", line 3431,
  column 21
Warning: "Prelude.bs", line 3440, column 36: (P0102)
  Declaration of `n' shadows previous declaration at "Prelude.bs", line 3431,
  column 24
Warning: "Prelude.bs", line 3445, column 37: (P0223)
  Definition of `n' is not used.
Warning: "Prelude.bs", line 3460, column 21: (P0223)
  Definition of `x' is not used.
Warning: "Prelude.bs", line 3487, column 12: (P0223)
  Definition of `f' is not used.
Warning: "Prelude.bs", line 3491, column 14: (P0223)
  Definition of `f' is not used.
Warning: "Prelude.bs", line 3495, column 14: (P0223)
  Definition of `f' is not used.
Warning: "Prelude.bs", line 3580, column 30: (P0102)
  Declaration of `v1' shadows previous declaration at "Prelude.bs", line 3579,
  column 9
Warning: "Prelude.bs", line 3580, column 33: (P0102)
  Declaration of `v2' shadows previous declaration at "Prelude.bs", line 3579,
  column 12
Warning: "Prelude.bs", line 3607, column 19: (P0223)
  Definition of `k' is not used.
Warning: "Prelude.bs", line 3658, column 34: (P0223)
  Definition of `t' is not used.
Warning: "Prelude.bs", line 3711, column 34: (P0223)
  Definition of `a' is not used.
Warning: "Prelude.bs", line 3714, column 21: (P0223)
  Definition of `pos' is not used.
Warning: "Prelude.bs", line 3714, column 25: (P0223)
  Definition of `kind' is not used.
Warning: "Prelude.bs", line 3735, column 25: (P0223)
  Definition of `kind' is not used.
Warning: "Prelude.bs", line 3738, column 25: (P0223)
  Definition of `kind' is not used.
Warning: "Prelude.bs", line 3741, column 25: (P0223)
  Definition of `kind' is not used.
Warning: "Prelude.bs", line 3744, column 25: (P0223)
  Definition of `kind' is not used.
Warning: "Prelude.bs", line 3747, column 25: (P0223)
  Definition of `kind' is not used.
Warning: "Prelude.bs", line 3750, column 25: (P0223)
  Definition of `kind' is not used.
Warning: "Prelude.bs", line 3980, column 8: (P0223)
  Definition of `value' is not used.
/build/source/inst/bin/bsc -stdlib-names -bdir /build/source/build/bsvlib -p . -vsearch /build/source/build/bsvlib -no-use-prelude PreludeBSV.bsv
imperative statement (not BVI context)make[3]: *** [Makefile:25: /build/source/build/bsvlib/PreludeBSV.bo] Error 1
make[3]: Leaving directory '/build/source/src/Libraries/Base1'
make[2]: *** [Makefile:31: build] Error 2
make[2]: Leaving directory '/build/source/src/Libraries'
make[1]: *** [Makefile:16: install] Error 2
make[1]: Leaving directory '/build/source/src'
make: *** [Makefile:24: install] Error 2
builder for '/nix/store/j5m5qb4ibc7c989iq4bsmaqha7slkijq-bsc-unstable-2020.02.05.drv' failed with exit code 2
error: build of '/nix/store/j5m5qb4ibc7c989iq4bsmaqha7slkijq-bsc-unstable-2020.02.05.drv' failed

Reproduction

1. Install nix ( https://nixos.org/nix/ )
2. Fetch https://github.com/NinjaTrappeur/nixpkgs/tree/bluespec-bsc
3. Run nix-build -A bluespec-bsc

The installation layout under $PREFIX/lib is a bit crowded and strange:

$ ls result/lib
Bluesim  exec  Libraries  SAT  tcllib  Verilog  Verilog.Quartus  Verilog.Vivado  VPI

This doesn't really follow the traditional layout of the Linux FHS and what a package manager might expect. In particular:

• Weird mix of upper/lower case
• lib should really only contain libraries or "compiled things" like .bo files, not the Verilog stuff. We should use something like $PREFIX/share for that.
• SAT just has shared objects. This should be fixed to namespace it for now, with a better name.
• exec isn't well named and contains a bunch of build scripts for various simulators
• Bluesim contains headers and libraries! These should go in include and the top-level lib dir.
• VPI contains libbdpi.so, but this should also go in the top level. And probably have a better name like libbluedpi.so.

Some of the Verilog primitives that are used by bsc-emitted code have rather unfortunate names. For example, taking the name TriState or Counter seems rather rude in the scope of a global project. Unfortunately, Verilog has no mechanism for controlling visibility of symbols, or doing namespaced/hygenic imports, so we're left with few options other than just renaming them to be as unique as possible. This is basically the same problem encountered in C++ headers which is why __they_use_lots__of_underscored_names_you_wont_choose.

While I don't think we need to go so far, perhaps just renaming all the modules to have the prefix __BLUESPEC_ would be enough? So FIFO0 becomes __BLUESPEC_FIFO0.

I also think that to be "future compatible", we should encourage tools interfacing with bsc to:

1. Scan the Verilog directory, and track that every .v filename will map to a single Verilog module name (e.g. __BLUESPEC_FIFO1.v contains module __BLUESPEC_FIFO1(...).) This could be made part of the bsc UI as well or something -- perhaps bsc -prim-to-file __BLUESPEC_FIFO1 could print out the filename for use in automation, or you could just use Tcl.
2. Assume any __BLUESPEC_ entities that appear as "blackboxes" in a design can have the blackbox "filled" with one of these modules. This is what tools like yosys-bluespec do: they assume any missing entities in the module hierarchy that match the files in the Verilog/ directory are to be "filled" by those modules.
3. Users can also just add all the files to their project and let the synthesizer figure it out, like they currently do.

This should mean that users, provided they automate their tooling correctly, should be mostly oblivious to adding/changing/renaming Verilog primitives.

On a side note, lib/Libraries/main.v, which provides a tool-neutral harness for "one-click" simulation compiles, should probably be renamed and moved out of this directory, since it's not meant to be used in simulation, and confuses the above logic.

Steps to repro:

This repro will use Ninja, not because Ninja is related -- it's not -- but because it's the easiest way to make a fast concurrent build to reproduce the race condition I'm hitting.

Obtain a machine with 2+ CPU cores, just to be safe.

Install Ninja. (Ubuntu package is ninja-build.)

Check out the tutorials, specifically Tutorials/Bluespec_Classic_Training/Example/Eg06a_Mergesort -- the mergesort isn't special, it's just the one I'm hacking on.

Place the following build.ninja file in the tutorial directory:

bsc_flags = -vdir verilog_RTL_ -bdir build_ -info-dir build_ -keep-fires -aggressive-conditions -no-warn-action-shadowing -check-assert -cpp +RTS -K128M -RTS -show-range-con
flict -p src:../Resources:%/Libraries

rule bsc_o
  command = bsc $bsc_flags -o $out $in

build build_/Req_Rsp.bo: bsc_o ../Resources/Req_Rsp.bs
build build_/Fabric_Req_Rsp.bo: bsc_o ../Resources/Fabric_Req_Rsp.bs | build_/Req_Rsp.bo build_/Fabric_Defs.bo

build build_/Fabric_Defs.bo: bsc_o src/Fabric_Defs.bs

Run: ninja build_/Fabric_Req_Rsp.bo

Now run: ninja -t clean && ninja -j1 build_/Fabric_Req_Rsp.bo

Expected results: the parallel build produces results equivalent to the serial build.

Actual results:

On the initial, parallel build:

[1/3] bsc -vdir verilog_RTL_ -bdir buil...uild_/Fabric_Defs.bo src/Fabric_Defs.b
FAILED: build_/Fabric_Defs.bo 
bsc -vdir verilog_RTL_ -bdir build_ -info-dir build_ -keep-fires -aggressive-conditions -no-warn-action-shadowing -check-assert -cpp +RTS -K128M -RTS -show-range-conflict -p src:../Resources:%/Libraries -o build_/Fabric_Defs.bo src/Fabric_Defs.bs
Error: Unknown position: (S0084)
  Could not remove the file `_t_o_p.c':
    does not exist
[2/3] bsc -vdir verilog_RTL_ -bdir buil...ild_/Req_Rsp.bo ../Resources/Req_Rsp.b
ninja: build stopped: subcommand failed.

Using -j1: works fine.

Is it possible that every bsc invocation is assuming it can generate a file called _t_o_p.c in the build directory, regardless of source/destination filenames? This makes it difficult to drive bsc from high-concurrency build systems. (I can arrange for every bsc invocation to get a separate build directory, but that's kind of messy.)

Edit: Yes, it is possible, the code is here. The same routine uses tmpNam just one line up, but for a different purpose. A second use of tmpNam might just fix it... it's a bit late in the evening for me to rebuild the compiler again, but I'll take a look in the morning.

...and make it an optional dependency of Bluespec.

NB stp's build system is based on CMake, and currently there aren't packages for Debian/Ubuntu or Homebrew for Mac OS X. I'm working on the latter at the moment.

Currently, bsc emits Verilog files that are named after modules defined within a source file, rather than the name of the source file. This complicates its use in build systems, which need to be able to precisely determine which artifacts are from which inputs in order to support correct incremental/parallel builds.

For build systems that support dynamic dependencies (e.g. make, or things built atop ninja), there are two features that would help with this.

1. The ability to generate lists of inputs to compiling a module, a la gcc -MF.
2. The ability to generate lists of outputs from compiling a module.

Ideally, these could be done without compiling the module, but if that's hard, doing both would be okay.

(Perhaps this can be done today with bluetcl -- the bluetcl docs are ungoogleable if they exist, and there's no Docs link on the Bluespec site. Edit: managed to find a copy of an old user guide posted on the UCSB website which includes docs on Bluetcl toward the end -- I see no facilities that seem relevant to this, but I may not be thinking creatively enough.)

For build systems that mandate static dependencies -- such as Bazel -- an option to control naming of Verilog outputs based on a pattern, or even concatenate all the outputs from Foo.bs into Foo.v, would help. I personally am not using such build systems, so this is lower on my priority list.

Other suggestions welcome!

@arjenroodselaar @bpfoley

log_V.txt
log.txt

Hello All,
I was facing some issue while using connectal for some lab excercises for MIT course 6.375. I was facing some error when i was playing around with the Lab5 of the course. I installed Connectal and while compiling different processors( make build_bluesim VPROC=MULTICYCLE) as suggested in the Lab5_PDF, I was facing some issues. The Error Files (Verbose and Silent) are attached.
I want to understand the issue and possibly fix it. Is the problem with Bluespec or Connectal?

Need some help from the community.

The dependencies for the Bluespec package should be very minimal at runtime, but because there's a hard dependency on Tk (from what I can tell), you need to pull in other things like font-config, X11, etc. This percolates into a lot of unneeded things. I think all we should really need is libc.so, libstdc++.so, libgmp.so, and perhaps one or two others...

My use case is that I have a tool that can create distro-agnostic binary tarballs, similar to the way Bluespec was packaged when it was proprietary (but with a much more fancy usage mechanism so it works anywhere.) Right now adding Bluespec would be a pretty big overhead -- other tools like NextPNR also have this problem when packaging them (they use Qt5, not Tk, however.)

Since the bluespec.com relaunch, links from http://wiki.bluespec.com/Home/BSV-Documentation linking to various downloads at http://www.bluespec.com/forum/download.php?id=xxx locations are not reachable anymore.

I'd be very helpful if those could be recovered, to help newcomers and users that want to use Bluespec.

Depending on how the docs are generated, those could probably be hosted through GitHub pages, readthedocs.io, or be part of a GitHub Wiki.

My build environment doesn't provide neither the git executable nor the .git folder, so I can only set NOGIT=1, but miss all version information, as this falls back to a bunch of zeroes.

It'd be much more convenient if the version string could be passed in via make flags.

A reminder to myself to come back and clean these up.
For example:

• unwordsWith is Data.List.intercalate
• makePairs is zip
• pair is uncurry
• isLeft, isRight are already in Data.Either

For time to time, building bsc with a huge number of jobs -j48 fails.

I managed to get a log output for one of these failures:
bluespec-bsc-parallel-build-failure.txt

The interesting lines:

[  4 of 149] Compiling EitherUtil       ( EitherUtil.hs, /build/source/src/comp/../../build/EitherUtil.o )
[  4 of 149] Compiling EitherUtil       ( EitherUtil.hs, /build/source/src/comp/../../build/EitherUtil.o )
[  5 of 149] Compiling ErrorTCompat     ( ErrorTCompat.hs, /build/source/src/comp/../../build/ErrorTCompat.o )
[  5 of 149] Compiling ErrorTCompat     ( ErrorTCompat.hs, /build/source/src/comp/../../build/ErrorTCompat.o )
[  1 of 224] Compiling BDD              ( BDD.hs, /build/source/src/comp/../../build/BDD.o )
/build/source/src/comp/../../build/ErrorTCompat.o: getModificationTime:getFileStatus: does not exist (No such file or directory)
[  6 of 149] Compiling Eval             ( Eval.hs, /build/source/src/comp/../../build/Eval.o )
make[2]: *** [Makefile:403: bluetcl] Error 1
make[2]: *** Waiting for unfinished jobs....

It seems there's at least two builds ghc builds going on in parallel (one with 149 targets, and one with 224 targets), and they both manage to stumble over each others feets trying to read/write to/from ErrorTCompat.

We should probably run only one of these builds at once, have intermediate build artifacts in separate scratch dirs, or further split things into libraries (as suggested by @NinjaTrappeur in #22)

If the repo had tags, update-build-version.sh could be changed to just call git describe --tags, and we'd get nice version strings for free.

TmpNam's file handling isn't secure, isn't atomic, isn't portable (it assumes /tmp exists), and doesn't obey $TMPDIR.

http://hackage.haskell.org/package/temporary

I remember to use a nice GUI when I used BSV earlier. I have just compiled this open source version. But I could not find any way to launch the GUI. I guess that it is not available any more. But I would like to suggest to make that GUI available again so that people like me can use the compiler and simulator in a comfortable manner.

Please reply if you are going to make it available.

I'm trying to write a Bluespec module parameterized by a numeric type specifying the number of input and output ports of a module, such that the names chosen for the ports have the format "foo1", "foo2", "foo3", ...

If there were an underscore between "foo" and the number and it started at index 0, I could use vectors to achieve this. For example:

interface Foo = foo :: Action {-# enable "", always_ready #-}

interface MyModule n = foo :: Vector n Foo {- # prefixs = "foo" #-}

Which generates ports named "foo_0", "foo_1", "foo_2", ...

How can I have this generate ports named "foo1", "foo2", "foo3" instead? I don't see a way to do this in section 13.2.1 "Renaming attributes" of the bluespec reference guide.

I can write out all of the individual ports by hand for a given N, but then I can't reuse MyModule in places where N may be different.

Trying to install open source bsv on Ubuntu 19.10. live usb. Couldn't find the package tk-itcl4-dev. While making its showing error "Cannot find -litk4.1.2". Worked fine on Ubuntu 16.04. How to proceed.

Steps to repro:
bsc -p dir1 -p dir2 Top.bs

Expected result, ideal world: search path is composed of dir1:dir2 (by analogy to how -L / -I work on gcc, for example). (Note: this option would substantially simplify build system integration.)

Expected result, less ideal world: compiler notes that -p was given twice and that was almost certainly a mistake, compile fails.

Actual result: final -p on the command line silently erases all knowledge of previous occurrences.

Steps to repro:

bsc -verilog -o Top.v Top.bs

Expected result: output goes into Top.v

Expected result, slightly darker timeline: -o flag is rejected as incompatible with Verilog output, compile fails.

Actual result: -o flag silently ignored, output goes into mkTop.v (as that is the name of the module in Top.bs).

I can't build with success on master and it seems that after commit 501cf77 everything is broken.
typical error

Linking bsc ...
/usr/bin/ld: cannot find -litcl3.4
/usr/bin/ld: cannot find -litclstub3.4
collect2: error: ld returned 1 exit status
compiler-script.sh' failed in phase Linker'. (Exit code: 1)
Makefile:376: recipe for target 'bsc' failed
make[2]: *** [bsc] Error 1
make[2]: Leaving directory '/home/slava/projects/bluespec/bsc/src/comp'
Makefile:11: recipe for target 'install' failed
make[1]: *** [install] Error 2
make[1]: Leaving directory '/home/slava/projects/bluespec/bsc/src'
Makefile:24: recipe for target 'install' failed
make: *** [install] Error 2

Compiling files in parallel is an opportunity for a productivity boost in large BSV designs. But is it best to achieve this inside the compiler (e.g. using Haskell's Control.Concurrent library) or outside (e.g. using a bluetcl script to extract depdendencies and generate a parallel Makefile)?

Doing it inside the compiler would certainly be simpler for users, but how hard would it be to get right?

I've had a quick scan of the code, and my first impression is that maybe it is not difficult. I propose a high-level strategy below. Probably though, I've missed important corner cases or complications. So I'd like to solict feedback (if anyone has time) before looking much further.

The strategy has three main parts.

1. Identifying dependencies. Looks like this is done by the transClose function, which returns a list of (package, [import]) pairs, i.e. the import graph.

2. Topological sort. Currently, the import graph is topologically sorted and reversed to give a flat list of files to compile sequentially, in order. I propose to keep the existing topological sort just to check for cycles, but to have chkDeps return a richer structure: the original import graph. We will still perform a topological sort, but to maximise parallelism, this will be done dynamically during the parallel build process (because we don't know in advance how long it will take to build each individual file).

3. Parallel build. Currently, the files are compiled sequentially by a foldM comp in compile_with_deps. I propose to replace this call to foldM with a new parallel build function, which operates as follows.

   • First, find all leaves of the import graph, and add them to a work queue.

   • Second, create a pool of worker threads to consume from the work queue and call the comp function.

   • Third, when a worker finishes compiling a file, remove all the incoming edges to that file from the import graph. If this exposes any new leaves, add them to the work queue. (This is the dynamic reverse topological sort.)

   • Repeat the third step until the work queue is empty and all workers are idle.

This is all probably obvious, but it looks like it could work. Am I missing anything important or perhaps even a show-stopper? If not, we may have time to prototype the idea, and report back our findings.

There's currently src/comp/wrapper.sh, which is copied for every binary in $(PREFIX)/bin. It does some relative path lookup to determine $BLUESPECDIR, then adds $BLUESPECDIR/SAT to LD_LIBRARY_PATH, exports $BLUESPECDIR and then invokes the real binary (which lives in $(PREFIX)/bin/core).

However, as we know the prefix during make install it should be possible to just set the binary RPATHs appropriately. cmake has automated tooling for that, but even without cmake it should be possible.
Grepping through the source, we already do that for $BLUESPECDIR/VPI.

I didn't fully skim through bsc and all usages of BLUESPECDIR in there, but this seems to be mostly there to know how to invoketk and tcl. As --prefix should be known during compile time, what about baking in those paths?

I did:

brew install cabal-install fontconfig gperf icarus-verilog pkg-config && \
    cabal update && \
    cabal v1-install old-time regex-compat split syb
make -j2 GHCJOBS=2 GHCRTSFLAGS='+RTS -M4500M -A128m -RTS' MACOSX_DEPLOYMENT_TARGET=10.13

Which is what is used in the GitHub CI runner and get the following error:

		-O2 -hide-all-packages -fasm -Wall -fno-warn-orphans -fno-warn-name-shadowing -fno-warn-unused-matches -package base -package containers -package array -package mtl -package unix -package regex-compat -package bytestring -package directory -package process -package filepath -package time -package old-time -package old-locale -package split -package syb -package integer-gmp -iGHC -iGHC/posix -iLibs -i../Parsec -i../vendor/stp/include_hs -i../vendor/yices/include_hs -i../vendor/htcl '-tmpdir /tmp' -L../vendor/htcl -I/usr/include/tcl -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Tk.framework/Headers -I../vendor/stp/include -L../vendor/stp/lib -I../vendor/yices/include -L../vendor/yices/lib '-pgma ./compiler-script.sh' '-pgmc ./compiler-script.sh' '-pgml ./compiler-script.sh' -rtsopts --make bsc -j2 +RTS -M4500M -A128m -RTS -ltcl8.6 -ltk8.6 -litcl4 -lhtcl -L"" -lstp -lyices  rts_hooks.o
ghc: on the commandline: missing argument for flag: -L
Usage: For basic information, try the `--help' option.
make[2]: *** [bsc] Error 1
make[1]: *** [install] Error 2
make: *** [install] Error 2

During build, /build/source/inst/bin/bsc -stdlib-names -bdir /build/source/build/bsvlib -p . -vsearch /build/source/build/bsvlib -no-use-prelude Prelude.bs is invoked.

It fails

terminate called after throwing an instance of 'Minisat::OutOfMemoryException'
make[3]: *** [Makefile:22: /build/source/build/bsvlib/Prelude.bo] Aborted (core dumped)
make[3]: Leaving directory '/build/source/src/Libraries/Base1'
make[2]: *** [Makefile:31: build] Error 2
make[2]: Leaving directory '/build/source/src/Libraries'
make[1]: *** [Makefile:16: install] Error 2
make[1]: Leaving directory '/build/source/src'
make: *** [Makefile:24: install] Error 2

Full Log: https://termbin.com/0nb3

Note the machine has ~60GiB of RAM, so I hope it's not really not enough memory ;-)

Every time I start the make file, the program aborts after about 10 minutes and I don't understand why. Here's the extract from my terminal:

...
[220 of 229] Compiling LambdaCalcUtil   ( LambdaCalcUtil.hs, /var/tmp/pamac-build-max/bluespec-git/src/bsc/src/comp/../../build/LambdaCalcUtil.o )
[221 of 229] Compiling SAL              ( SAL.hs, /var/tmp/pamac-build-max/bluespec-git/src/bsc/src/comp/../../build/SAL.o )
[222 of 229] Compiling LambdaCalc       ( LambdaCalc.hs, /var/tmp/pamac-build-max/bluespec-git/src/bsc/src/comp/../../build/LambdaCalc.o )
[223 of 229] Compiling ADumpSchedule    ( ADumpSchedule.hs, /var/tmp/pamac-build-max/bluespec-git/src/bsc/src/comp/../../build/ADumpSchedule.o )
[224 of 229] Compiling DisjointTest     ( DisjointTest.hs, /var/tmp/pamac-build-max/bluespec-git/src/bsc/src/comp/../../build/DisjointTest.o )
[225 of 229] Compiling ASchedule        ( ASchedule.hs, /var/tmp/pamac-build-max/bluespec-git/src/bsc/src/comp/../../build/ASchedule.o )
[226 of 229] Compiling AState           ( AState.hs, /var/tmp/pamac-build-max/bluespec-git/src/bsc/src/comp/../../build/AState.o )
[227 of 229] Compiling AAddSchedAssumps ( AAddSchedAssumps.hs, /var/tmp/pamac-build-max/bluespec-git/src/bsc/src/comp/../../build/AAddSchedAssumps.o )
[228 of 229] Compiling ACleanup         ( ACleanup.hs, /var/tmp/pamac-build-max/bluespec-git/src/bsc/src/comp/../../build/ACleanup.o )
[229 of 229] Compiling Main_bsc         ( bsc.hs, /var/tmp/pamac-build-max/bluespec-git/src/bsc/src/comp/../../build/Main_bsc.o )
Linking bsc ...
Using flags:  @/tmp/ghc5165_0/ghc_839.rsp
Using flags:  @/tmp/ghc5165_0/ghc_842.rsp
bsc done Do 6. Feb 14:03:16 CET 2020

make[2]: Verzeichnis „/var/tmp/pamac-build-max/bluespec-git/src/bsc/src/comp“ wird verlassen
make[1]: *** [Makefile:15: install] Fehler 2
make[1]: Verzeichnis „/var/tmp/pamac-build-max/bluespec-git/src/bsc/src“ wird verlassen
make: *** [Makefile:24: install] Fehler 2
==> FEHLER: Ein Fehler geschah in build().
    Breche ab...

...

The german text says: "... ==> ERROR: an error occured in build(). Aborting... "

After tcl/tk was removed, I am able to build bsc on MacOS (10.13) with Apple's compiler (Apple LLVM 10.0.0). There were a few hiccups which needed manual intervention and I could not build STP, bluesim and bluetcl. These are my steps:

1. Get cabal-install, tcl-tk, autoconf, icarus-verilog from Homebrew
2. cabal v1-install the three packages instead of cabal install
3. tcl-tk is at /usr/local/opt/tcl-tk so edit PATH and PKG_CONFIG_PATH. comp/Makefile hardcodes the paths and version number of itcl. I just manually changed them. Also, itk is not available so remove bluetcl and bluewish from build targets
4. make STP_STUB=1 -j all

At this point bsc is built but it cannot build Libraries as it seems to need libbdpi. To see the libs it needs, run otool -L inst/bin/core/bsc which shows:

inst/bin/core/bsc:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
        libbdpi.so (compatibility version 0.0.0, current version 0.0.0)
        /Users/mtikekar/src/bsc/src/yices/v2.6/yices2-inst/lib/libyices.2.dylib (compatibility version 2.6.0, current version 2.6.2)
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)

(absolute path to yices should probably be fixed)

So I built VPI manually and pointed bsc to libbdpi.so with

install_name_tool -change libbdpi.so $(pwd)/src/VPI/libbdpi.so inst/bin/core/bsc

Then manually built the remaining steps. (Some of my commands above are reconstructed from memory and might be different).

Capturing this as a separate issue suggested by @thotypous in #147

It would be superb if you could set up automated builds on Docker Hub using the Dockerfile.

An official image on Docker Hub would be very useful for setting up automated CI builds on Bluespec designs. It would also help to attract more newcomers (as an alternative or complement to ordinary binary releases).

Moving these parts facilitates the isolation of these parts as they are not integral to the Bluespec compiler itself. It would also help in getting bsv-mode to MELPA, for example.

Building src/comp takes about 20 minutes on my beefy machine.

This long build time is mostly due to the fact GHC builds the whole 229 targets in a single core, hence not leveraging parallel nature of modern CPUs.

One way to improve this situation would be to divide this massive 229 targets package into several smaller independent libs, allowing a potential Haskell-specific build tool (cabal? stack?) to parallelize a bit more the overall build.

The solution to this will mostly depend on the build system you're (ie. ppl working full-time on this) envisioning.

Do you plan to keep this makefile + bare ghc custom build system or move to a Haskell-specific build tool for the Haskell bits?

While we work to integrate the Bluespec compiler into Nixpkgs, I'd like to see the Bluespec build move away from vendoring dependencies, and I think TCL/Tk is the best starting point for this kind of work. TCL/Tk are widely distributed and easily obtainable on almost any modern machine, so I think just requiring it to be installed is pretty reasonable. This will both improve build times and generally make the overall compile process simpler.

It would appear that there is a binding for bluetcl that binds the Haskell runtime to Tcl (which is impressive and very neat!) I'd suggest leaving that here, and just moving out the actual tcl build itself, of course.

Bluespec currently uses TCL 8.5, but the latest version is 8.6. My understanding is that many distros support both of these versions of Tcl, and so does Nixpkgs -- so supporting new tcl versions and de-coupling the current vendored build can both be done independently. (itcl supports 8.6, so it might only be the Haskell bindings that need updating to support 8.5/8.6 concurrently.)

I believe this will make the build system simpler, and also allow us to more easily create "non-GUI" builds of the Bluespec compiler later on that do not rely on X11, etc being available. (These are useful to make builds faster e.g. for CI systems, where you don't want to run the "install bluespec compiler" phase and pull in a bunch of GUI dependencies for mesa, etc in.)

I was just following along with the build instructions in README.md and I it complained that it couldn't find regex-compat.

[...]
make[2]: Entering directory '/home/leon/devel/bluespec/src/comp'
----- Normal build options -----
can't find package Itcl
bsc start di 10 mrt 2020 17:05:52 CET
./update-build-version.sh
BuildVersion.hs up-to-date
./update-build-system.sh
BuildSystem.hs up-to-date
ghc -fmax-pmcheck-iterations=6000000 -Wtabs -hidir /home/leon/devel/bluespec/src/comp/../../build -odir /home/leon/devel/bluespec/src/comp/../../build -stubdir /home/leon/devel/bluespec/src/comp/../../build -main-is Main_bsc \
	-O2 -hide-all-packages -fasm -Wall -fno-warn-orphans -fno-warn-name-shadowing -fno-warn-unused-matches -package base -package containers -package array -package mtl -package unix -package regex-compat -package bytestring -package directory -package process -package filepath -package time -package old-time -package old-locale -package split -package syb -package integer-gmp -iGHC -iGHC/posix -iLibs -i../Parsec -i../vendor/stp/include_hs -i../vendor/yices/include_hs -i../vendor/htcl '-tmpdir /tmp' -L../vendor/htcl -I/usr/include/tcl -I../vendor/stp/include -L../vendor/stp/lib -I../vendor/yices/include -L../vendor/yices/lib '-pgma ./compiler-script.sh' '-pgmc ./compiler-script.sh' '-pgml ./compiler-script.sh' -rtsopts --make bsc -j1 +RTS -M3G -A128m -RTS -ltcl8.6 -ltk8.6 -litcl -lhtcl -lstp -lyices  rts_hooks.o
<command line>: cannot satisfy -package regex-compat
    (use -v for more information)
Makefile:326: recipe for target 'bsc' failed
make[2]: *** [bsc] Error 1
make[2]: Leaving directory '/home/leon/devel/bluespec/src/comp'
Makefile:11: recipe for target 'install' failed
make[1]: *** [install] Error 2
make[1]: Leaving directory '/home/leon/devel/bluespec/src'
Makefile:24: recipe for target 'install' failed
make: *** [install] Error 2

I had to change $ cabal install regex-compat syb old-time
to $ cabal v1-install regex-compat syb old-time split
Because cabal >=3 defaults to v2-install.
And also split was missing.

ghc version: 8.0.2

`[181 of 226] Compiling Depend ( Depend.hs, /imec/other/nmorph/bhatta53/private/software/bsc/src/comp/../../build/Depend.o )

Depend.hs:78:46: error:
* Couldn't match expected type time-1.10:Data.Time.Clock.Internal.UTCTime.UTCTime' with actual type time-1.6.0.1:Data.Time.Clock.UTC.UTCTime'
NB: time-1.6.0.1:Data.Time.Clock.UTC.UTCTime' is defined in Data.Time.Clock.UTC' in package time-1.6.0.1' time-1.10:Data.Time.Clock.Internal.UTCTime.UTCTime'
is defined in Data.Time.Clock.Internal.UTCTime' in package time-1.10'
* In the first argument of floor . utcTimeToPOSIXSeconds', namely utcTime'
In the expression: (floor . utcTimeToPOSIXSeconds) utcTime
In an equation for s': s = (floor . utcTimeToPOSIXSeconds) utcTime make[2]: *** [bsc] Error 1 make[2]: Leaving directory /imec/other/nmorph/bhatta53/private/software/bsc/src/comp'
make[1]: *** [install] Error 2
make[1]: Leaving directory /imec/other/nmorph/bhatta53/private/software/bsc/src' make: *** [install] Error 2

I'm packaging bsc for home-brew linux/Mac.
Homebrew requires a tarball to target which is usually implemented with a GitHub release.
I have a release here on my fork.
I can pull-request on releases upstream, so can we start doing bsc releases?

How do we version? Right now, running bsc shows the version as the first 7 digits of the git commit sha. Maybe we should consider version number with the major incrementing every year, and the minor number every month?

I am more than willing to maintain versioning and packaging for homebrew and possibly apt.

I am getting following problem:

(cd yices2 ;
autoconf ;
./configure --prefix=/net/home/merchantf/Downloads/bsc/src/yices/v2.6/yices2-inst ;
make;
make install
)
autoconf: error: no input file
/bin/sh: line 2: ./configure: No such file or directory
make[1]: Entering directory /net/home/merchantf/Downloads/bsc/src/yices/v2.6/yices2' make[1]: *** No targets specified and no makefile found. Stop. make[1]: Leaving directory /net/home/merchantf/Downloads/bsc/src/yices/v2.6/yices2'
make[1]: Entering directory /net/home/merchantf/Downloads/bsc/src/yices/v2.6/yices2' make[1]: *** No rule to make target install'. Stop.
make[1]: Leaving directory `/net/home/merchantf/Downloads/bsc/src/yices/v2.6/yices2'
make: *** [install] Error 2

Any solution?

I'm working on making debian packages so I do not have to recompile on all the machines on which I use bsc.

It has been an interesting and interesting process.

To install in the usual place, PREFIX=/usr. This gets exciting at the end of dpkg-buildpackage when it does a make clean which does rm -fr $PREFIX. I can see why that was in the code before, but I would like to match packager expectations.

Also, all the installs should be relative to $DESTDIR, which is used so that the packaging scripts can install to a staging area and copy the files into the package.

Setup

Right now, Bluespec links directly into Yices or STP for doing solving of various bitvector-like constraints. Or something like that. The default for now is Yices, and STP is optional, and we link to their object files, and that's really what matters.

However, doing this has a number of downsides:

• We must vendor yices and possibly other packages like step. We should be moving away from this. It requires tooling like submodules, makes build integration more complicated, and ultimately third party systems already package things like this.

• More substantially, linking to the Yices API means the Bluespec compiler is a derived work under the GPLv3, and also, any codebase derived from bsc will be, too. It's important to note that the code of bsc itself can fully be BSD2, but it is the linking part that actually produces the derived work (and implies a requirement to the source code, for resulting binaries, under the derivative/GPL clause). IANAL, but this is my understanding.

The first is problematic for a number of technical reasons (submodules, etc) but the second really hurts. People are also prone to get strange about licensing issues and may find this "deceptive" (because you advertise the codebase as BSD3, but some results are under the GPLv3 by law.)

Proposed solution

I think it should be possible to avoid all this by doing something else instead: most modern SMT solvers (including Yices, Z3, STP from what I can tell, Boolector, and more) support formats like SMT-Lib. This is a project-neutral standard format you can feed a solver and have it produce answers for you.

The most prominent library for this is sbv in my opinion:

• It's well-maintained, and Levent is very responsive.
• It's seen successful, widespread use (in both commercial and open source projects, such as Cryptol, and others I can't speak much about.)
• It doesn't require ANY FFI integration or libraries. Rather, it does the tricky work of portably launching the solver programs (yices.exe, z3.exe) in a cross platform manner, feeding them problem sets, and returning the results encoded as Haskell values.

These combination of features, IMO, make it the most worthy route to investigate, and feature 3 in particular not only breaks the GPLv3-by-linking problem, but opens the door to other solvers (z3, boolector) etc as well.

For anyone who wants to tackle this, I suggest looking for uses of Yices in the compiler codebase. The actual amount of uses of the Yices FFI library are small, so I'd suggest trying to surgically replace what we have with SBV, to the extent possible. We can then just fix the SBV solve function to use Yices for now.

Upsides

• Fixes the GPLv3 issue. This is good for everyone and sets proper exectations.
• Makes solver choice more flexible. This means we don't have to worry if users want STP, Z3, Yices, whatever.
• Will reduce build time. No need to build Yices (mandatory) or STP (optional), which will help build time a lot.

Problems and risks

• Problem: This is a potentially behavior-inducing change, and requires testing.
  Solution: We MUST have the testsuite available, and have it working in CI. This I feel is really important and can't be worked around.
  Note: Perhaps if the change is small and easy enough, Julie could run tests for us to let it go through.

• Problem: SBV has many several dependencies. These aren't too bad, but in general comp has a very spartan set of dependencies right now. Going forward, though, it seems unlikely to continue to the same degree (~10 years of GHC support is a bit much. :)
  Solution: Doing this will probably require us to move to a new mechanism for integrating Haskell dependencies, for example, using cabal new-build with Cabal 3.0 to build packages, and this will probably have impacts on the CI and build process as a result. We'll need to actually pick a supported compiler range, and show people how to install it and the tools. This can be done pretty easily for Debian with Herbert's PPA, though RHEL needs some review since I'm not familiar with it. (This will pave the way to producing .rpm and .deb packages, and so it should happen before doing that.)

• Problem: We probably should test solvers a bit. Joe Schmo's random SMT solver from GitHub probably isn't worth doing QA or testing for. Yices, Z3, etc all seem reasonable.
  Solution: The CI could reasonably test multiple solvers if it's fast enough, but who knows about this. Solver edge cases can definitely be supported as regression tests. We should pick a minimum set of solvers and tell users to stick with them.

tclIndex.sh tries to invoke tclsh, however, the tclsh binary gets installed into a wrong location,

source/src/tcltk/tcltk8.5.4/tcl8.5.4/unix/../../../inst/bin/tclsh8.5, which means source/src/tcltk/inst/bin/tclsh8.5.

I assume this wasn't caught, because there's another tclsh in $PATH.

The binaries for$(UTILEXES) $(SHOWRULESEXES) consume a substantial amount of disc space on top of $(BSCEXES) even though they mostly just re-use the functionality implemented in modules also used by bsc itself.

On my Mac, stripped -O2 builds have the following sizes

$du -sh
38M	bsc
5.6M	bsc2bsv
 12M	bsv2bsc
3.3M	dumpbo
3.6M	dumpba
2.6M	vcdcheck
6.2M	showrules

Note that bsc is 38MB and all the other binaries sum to 33.3MB.

This disc space usage can be a (minor) efficiency concern in continuous integration environments, and also matters if you want to build minimal docker images and the like.

It also slows down the complete tool build by causing an individual (large) link to occur for each binary.

We could replace all these tools with a single binary; use symlinks to link all the old binary names to our single binary; determine which command we're actually running based on argv[0]; and dispatch to the correct Main based on that.

While doing labs from 6.375 course(MIT), there was a mention of the build command as a part of the bluespec package, which i didn't find in the bin folder. Can anyone please help?

In PR #146, the issue was raised that itcl/itk libraries may not be available in the same place as tcl/tk (since itcl/itk is intended to be dynamically loaded in tcl). The issue was deferred from that PR, so I'm opening this ticket to record it.

The tcl interpreter has a search path where index files (pkgIndex.tcl) can be found, that declare the available packages, and give arbitrary code for how to load them. For example, as @bpfoley pointed out in the PR thread:

$ tclsh
% package require Itcl
3.4
% package ifneeded Itcl 3.4
load /usr/lib/x86_64-linux-gnu/libitcl3.4.so.1 Itcl

And here is the search path on that same system:

% puts $auto_path
/usr/share/tcltk/tcl8.6 /usr/share/tcltk /usr/lib /usr/local/lib/tcltk /usr/local/share/tcltk /usr/lib/tcltk/x86_64-linux-gnu /usr/lib/tcltk /usr/lib/tcltk/tcl8.6

On this system, under /usr/lib/tcltk/x86_64-linux-gnu/ are itcl3.4 and itk3.4 directories that contain pkgIndex.tcl files declaring Itcl and Itk:

if {![package vsatisfies [package provide Tcl] 8.6]} {return}
package ifneeded Itcl 3.4 [list load [file join /usr lib x86_64-linux-gnu "libitcl3.4.so.1"] Itcl]

(I would guess that the search of auto_path must recurse into subdirectories?)

In addition to this kind of searching, the tcl interpreter can also declare that some packages are statically available. (This is from the point of view of the interpreter; the library might be dynamically loaded by the executable when run, but that's still considered "static" because the library is already loaded by the time the interpreter executable is running.) In bluetcl_Main.hsc (and bluewish_Main.hsc), we declare that itcl (or itk) is available:

// Itcl startup
if (Itcl_Init(interp) != TCL_OK) {
  fprintf(stderr,"Unable to start itcl -- %s\n", Tcl_GetStringResult(interp));
  exit (-1);
}
Tcl_StaticPackage(interp, "Itcl", Itcl_Init, Itcl_SafeInit);

NOTE: At some point (maybe when we unvendored tcl/tk and itcl/itk?) we seem to have also changed the linking of those libraries to be dynamic instead of static. So we are now requiring that itcl/itk be available in the user's environment, not just the build environment!

I think we need to go in one of two directions: (A) Fix the linking to be static linking (with .a files), so that we are not requiring that Itcl/Itk be installed in the user's environment (for the right version of tcl/tk) and further that we're not requiring that tcl/tk (of the right version) be installed in the user's environment either. Or (B) we go all-in on using the system version of tcl/tk and itcl/itk.

If we want to go all in, is it sufficient to just remove the static declaration from the .hsc files? We'd still be producing bluetcl and bluewish binaries that expect to dynamically link with tcl/tk on the system. Would it be any more portable if we eliminated bluetcl and bluewish binaries, and just made the bluespec commands into library that gets loaded into tclsh the same way that itcl/itk does? Or would that library still be tied to a specific tcl/tk, in which case it doesn't hurt to keep bluetcl and bluewish binaries (since either way we'd be requiring the user's system to have a specific version of tcl/tk installed)?

FYI, I notice that no code in the bsc repo has package require Itcl. This seems to only exist in the Workstation GUI (which is not yet open source, but will come, probably in its own repo).

Anyway, I'm leaning towards eliminating mentions of Itcl/Itk from the Makefile and .hsc -- keeping the -l linking of tcl/tk for the bluetcl and bluewish binaries, but no mention of itcl/itk -- and relying on the auto_path to load itcl/itk where needed. I would also be OK with going back to statically linking both tcl/tk and itcl/itk. What do folks think?

The Bluespec compiler emits Verilog which makes Yosys somewhat unhappy:

1.3. Executing Verilog-2005 frontend: /tmp/yosys-bsv-v-QxaOnJ/keccak.v
Parsing Verilog input from `/tmp/yosys-bsv-v-QxaOnJ/keccak.v' to AST representation.
Warning: Found one of those horrible `(synopsys|synthesis) parallel_case' comments.
Yosys does support them but it is recommended to use Verilog `parallel_case' attributes instead!
Warning: Found one of those horrible `(synopsys|synthesis) translate_off' comments.
Yosys does support them but it is recommended to use `ifdef constructs instead!
Generating RTLIL representation for module `\keccak'.
Note: Assuming pure combinatorial block at /tmp/yosys-bsv-v-QxaOnJ/keccak.v:554 in
compliance with IEC 62142(E):2005 / IEEE Std. 1364.1(E):2002. Recommending
use of @* instead of @(...) for better match of synthesis and simulation.
Note: Assuming pure combinatorial block at /tmp/yosys-bsv-v-QxaOnJ/keccak.v:568 in
compliance with IEC 62142(E):2005 / IEEE Std. 1364.1(E):2002. Recommending
use of @* instead of @(...) for better match of synthesis and simulation.
Note: Assuming pure combinatorial block at /tmp/yosys-bsv-v-QxaOnJ/keccak.v:590 in
compliance with IEC 62142(E):2005 / IEEE Std. 1364.1(E):2002. Recommending
use of @* instead of @(...) for better match of synthesis and simulation.
Note: Assuming pure combinatorial block at /tmp/yosys-bsv-v-QxaOnJ/keccak.v:1357 in
compliance with IEC 62142(E):2005 / IEEE Std. 1364.1(E):2002. Recommending
use of @* instead of @(...) for better match of synthesis and simulation.
Note: Assuming pure combinatorial block at /tmp/yosys-bsv-v-QxaOnJ/keccak.v:1366 in
compliance with IEC 62142(E):2005 / IEEE Std. 1364.1(E):2002. Recommending
use of @* instead of @(...) for better match of synthesis and simulation.
Note: Assuming pure combinatorial block at /tmp/yosys-bsv-v-QxaOnJ/keccak.v:1440 in
compliance with IEC 62142(E):2005 / IEEE Std. 1364.1(E):2002. Recommending
use of @* instead of @(...) for better match of synthesis and simulation.
Successfully finished Verilog frontend.

The first warning is triggered by this (parallel_case):

  begin
    case (1'b1) // synopsys parallel_case
      WILL_FIRE_RL_permute: first_block$D_IN = counter_block == 6'd32;
      init_enable: first_block$D_IN = 1'd0;
      WILL_FIRE_RL_do_go: first_block$D_IN = 1'd1;
      default: first_block$D_IN = 1'bx /* unspecified value */ ;
    endcase
  end

Fix: use Verilog-standard (* parallel_case *) instead:

  begin
    (* parallel_case *)
    case (1'b1)
      WILL_FIRE_RL_permute: first_block$D_IN = counter_block == 6'd32;
      init_enable: first_block$D_IN = 1'd0;
      WILL_FIRE_RL_do_go: first_block$D_IN = 1'd1;
      default: first_block$D_IN = 1'bx /* unspecified value */ ;
    endcase
  end

Second (translate_off):

  // synopsys translate_off
  `ifdef BSV_NO_INITIAL_BLOCKS
  `else // not BSV_NO_INITIAL_BLOCKS
  initial
  begin
    counter_block = 6'h2A;
    counter_nr_rounds = 5'h0A;
    first_block = 1'h0;
    first_round = 1'h0;
    permutation_computed = 1'h0;
    reg_data =
        1600'hAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;
    theta_parity_reg = 5'h0A;
  end
  `endif // BSV_NO_INITIAL_BLOCKS
  // synopsys translate_on

Fix: add ifdef YOSYS to chain and scope properly. This helps scope the translation to simulators.

  `ifdef BSV_NO_INITIAL_BLOCKS
  `elsif YOSYS
  `else // not BSV_NO_INITIAL_BLOCKS
  // synopsys translate_off
  ...
  // synopsys translate_on
  `endif // BSV_NO_INITIAL_BLOCKS

Third (combinatorial block):

  // register first_block
  always@(WILL_FIRE_RL_permute or
          counter_block or init_enable or WILL_FIRE_RL_do_go)
  begin
    case (1'b1) // synopsys parallel_case
      WILL_FIRE_RL_permute: first_block$D_IN = counter_block == 6'd32;
      init_enable: first_block$D_IN = 1'd0;
      WILL_FIRE_RL_do_go: first_block$D_IN = 1'd1;
      default: first_block$D_IN = 1'bx /* unspecified value */ ;
    endcase
  end
  assign first_block$EN =
             WILL_FIRE_RL_permute || init_enable || WILL_FIRE_RL_do_go ;

Fix: just use always @* for combinational blocks, since there aren't any clock edges used in the sensitivity list:

  // register first_block
  always @*
  begin
    ...
  end

I suspect it would be more efficient to use elem x xs in these cases. At the very least it saves you allocating a Just to return.

From personal communications, I heard that bluespec.com used to do their compiler builds in a Debian 3.1 VM with GHC 6.12 so that the resulting glibc and shared library dependencies were old enough that a bunch of older versions of OSes such as RedHat Enterprise Linux would be able to run them.

Going forward, I think should explicitly say what OSes and compiler versions we want to support are.

Related to this, we should possibly consider other ways of providing backwards compatibility without tying ourselves to old libraries and toolchains, such as by using statically linked libraries for bsc/bluesim.

From what I can tell, at the moment there is no test suite for the compiler -- which makes me extremely anxious to make any changes. For example, #16 suggests that STP can be removed, except for one niggling case in SATPred.hs, which could be replaced with Yices. The thing is, how do I even test that change? Why was STP used in the first place? Are there cases it succeeds where Yices fails?

Perhaps for now the right thing to do is test changes by doing full compilation flows e.g. against Piccolo or Flute, and ensuring the end-to-end simulation runs turn out the same, or something.

In the long run, I think there would be a significant amount of value to be had by simply adding tests that can be run using some "golden testing" infrastructure, that simply test typechecking/compiling/etc all work as expected, on very small and minimal examples. (Most compilers do something like this, of course.)

This is made a bit more tricky by the fact that Parsec 3 has a new and different API, and the vendored Parsec 2 has been patched fairly extensively

The patches include:

• GenParser's state function returns an IO.
• ParseError has been replaced with [EMsg] (== [(Position, ErrMsg)])
• A Position struct is used instead of SourcePos
• Error handling has several new functions, failWithErr, mergeErrors etc

Parsec 3 has its own Parsec 2 compatibility shim and we can probably add our own version of this in src/comp/Parsec.hs.

...eventually, at a time where it's suitable for us.

Yices have

• formulas suitable for use with Homebrew on MacOS X,
• PPA packages suitable for use on Debian/Ubuntu
• Binary releases statically linked against the necessary libraries for other x86 Linuxes.

https://yices.csl.sri.com/doc/install-binaries.html

Un-vendoring means we won't have to maintain yices's dependencies, and probably makes bsc more suitable for packaging on Debian/Homebrew. We may have to do some legwork to get yices made into non-third party packages on Debian/Homebrew.

It'd help if every commit on the master branch, and every PR would trigger CI, which would try to build the current source, and run the smoke test.

This rules out some basic errors, and once the test suite has been added, we could run it as well.

I'd be happy to help setting this up, but I'd need somebody with admin permissions in the repo to press the right buttons for me.

this is actually step zero in the sequence of blockers to cabalizing the whole build process

Hi All,

I am a newbie to Bluespec and playing with the open sourced compiler to compile an open source processor here. The warnings/errors are as following:

Warning: Command line: (S0091)
  Removing a directory from the path specified with the -p flag, because it
  could not be opened.
  Directory:
    /root/lab/cheri/beri/bsc/bsc/inst/lib/Libraries/Axi
  System message:
    does not exist
Warning: Command line: (S0091)
  Removing a directory from the path specified with the -p flag, because it
  could not be opened.
  Directory:
    /root/lab/cheri/beri/bsc/bsc/inst/lib/Libraries/Contrib/NonPipelinedMath
  System message:
    does not exist
Warning: Command line: (S0091)
  Removing a directory from the path specified with the -p flag, because it
  could not be opened.
  Directory:
    /root/lab/cheri/beri/bsc/bsc/inst/lib/Libraries/TLM3
  System message:
    does not exist
checking package dependencies
Error: "../../cherilibs/trunk/CheriAxi.bsv", line 55, column 1: (S0034)
  Cannot find the file `TLM.defines' to be included
Makefile:514: recipe for target 'build_fpu_sim/sim' failed
make: *** [build_fpu_sim/sim] Error 1

It seems there are some missing libraries compared to the licensed version of the compiler, such as TLM3, Axi, NonPiplelineMach, etc. Is there anybody trying to add them? Or is there any legal issue preventing them to be open sourced? If these libraries are allowed to be open sourced, is it possible for me to contribute to this repository by simply moving the libraries from the licensed version to this open sourced version?

Thanks.
Lele Ma