Bluespec Connectal Issue

[rajat-agarwal-]

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.

[quark17]

I suspect that Connectal needs to be improved to work with the open BSC release. You might try contacting the Connectal community.

For one, the flag -wait-for-license no longer exists, so you will need to remove it from wherever it's being specified.

Two, the Connectal system might be assuming that some libraries (like Vector) are found in a directory called Prelude alongside Libraries. That directory has been removed and all the core libraries are in Libraries now. And/or Connectal might be expecting that the variable BLUESPECDIR is set in your environment; this is no longer required by BSC but you may need to set it for Connectal (to point to the installation directory for BSC).

There is currently an IRC channel (#bluespec on Freenode) where you can ask questions. We don't yet have any mailing lists, but hopefully we can set that up soon, where users and developers can ask questions.

[bpfoley]

I wonder, simply for backwards compatibility's sake, would it be worth adding a no-op -wait-for-license flag?

[jameyhicks]

I need some way to know whether the compiler needs a license. I suppose I can just run a test invocation of bsc with -wait-for-license and see if it prints an error.

However, I think it would be cleaner to check bsc -version, but it doesn't seem to have a version flag.

Any thoughts on a good way to distinguish open source bsv vs licensed bsc in a script?

[quark17]

There's a bluetcl command version that returns a triple of the version name (from Version.hs), version date (from Version.hs), and build version (from the autogenerated BuildVersion.hs, where its usually the git hash).

These are also reported in the first line of bsc -v, which you could parse. For Bluespec releases, it looked like this:
Bluespec Compiler, version 2019.05.beta2 (build a88bf40db, 2019-05-24)
The source code that's checked in has an empty string for the version name and build date. When either of those is empty, it's left out from the bsc -v output. So if you built the code that's currently here, you'd see this:
Bluespec Compiler (build 7d0b6cf)
I think there may already be an open ticket for allowing the name to be specified on the make command-line; and we may want to auto-insert the date as well.

Anyway, I think there's probably no way to tell from the version whether this is pre-open-source or not. Adding a no-op -wait-for-license flag wouldn't be unreasonable.

[quark17]

I guess you could differentiate licensed from unlicensed by look for whether the version name matches "YYYY.MM.TAG" with a year that's 2019 or earlier. In that case, it's a licensed release, otherwise it's not.

[bpfoley]

Or... perhaps you could just do something like

if bsc -help | grep -q -- -wait-for-license; then
    BSC_ARGS+=-wait-for-license
fi

[hanw]

Will the device-specific Prelude files be released as part of the open-source repo? For instance, there were quite a few Xilinx....bo files that used to be in Prelude, but no longer present in the open-source version. Connectal needs these device libraries.

[quark17]

We do plan to release those libraries, but I didn't feel that they belonged in the core BSC. At least not until we have some better system for libraries, even just hierarchical naming or something. My thought was to create a separate repo (called bsc-contrib? or blibs-contrib?) where these existing libraries can be put, for those who need it, and where others can contribute useful libraries that don't belong in the core but might still be useful.

I'll go ahead and create that repo shortly (name suggestions welcome!). I'm also open to listening to arguments why particular libraries might belong in the core.

[hanw]

Thanks @quark17. It is greatly appreciated if you could release the contrib library sooner than later. I am kinda stuck porting connectal to use the open-source bsc and I need connectal for a project that I am working on.

[quark17]

These libraries have been made public in a separate repo, B-Lang-org/bsc-contrib

[hanw]

👍 thanks!

[jameyhicks]

I think we can close this issue because the corresponding issue in the Connectal repo has been closed. cambridgehackers/connectal#157

Thanks for the suggestions and for publishing the bsc-contrib repo!