Slang compiler relies on the third-party libraries like unordered_dense and fmt
library. The fmt library provides two ways to integrated it:
1.Headers-only
2.Seperately compiled
The main purpose of this commit is to avoid installation failure of CIRCT project due
to finding fmt header file in wrong path which is in circt `include` directory when
CMake_slang_Frontend_enabled is turned on. We hope to not install header files coming
from fmt library.
Add a `circt-capi` target that depends on all C API libraries. Introduce
a new `add_circt_public_c_api_library` CMake function that wraps around
the MLIR equivalent, but also adds a dependency from `circt-capi`. Make
at least the short integration tests CI job build the `circt-capi`
target to ensure it has a bit of CI coverage.
This PR adds a JIT runtime for arcilator, backed by MLIR's ExecutionEngine. This JIT allows executing `arc.sim` operations directly from the arcilator binary.
These targets are useful for downstream projects that want to install
all CIRCT libraries. The CMake commands follow how similar targets are
set up in upstream MLIR.
This is the first PR in a longer chain that adds basic SV support to
CIRCT.
Add the Slang Verilog frontend as a CIRCT dependency. This will be the
foundation for CIRCT's Verilog parsing, elaboration, type checking, and
lowering to the core dialects. By default, Slang is built as a static
library from scratch, which is then linked into the new `ImportVerilog`
conversion. Alternatively, CIRCT can also be linked against a local
Slang installation provided by the system.
Add the `ImportVerilog` conversion library. This library statically
links in the Slang dependency and wraps it in an exception-safe,
LLVM-style API. Currently this only consists of the `getSlangVersion`
function and the necessary linking flags to get it to link statically
against Slang.
Add the `circt-verilog` tool, which will provide a fully-flegded
interface to the new `ImportVerilog` library. Later on we'll also add an
MLIR translation library for single-file SV import. But in general, SV
builds take a lot of command line options (macros, search paths, etc.)
and multiple input files, which is why we have a dedicated tool. All the
tool does at the moment is print the linked Slang version. More to come.
Note that this intentionally links against **version 3** of Slang. Newer
versions are available -- 4 and 5 as of this commit -- but they rely on
fairly new C++ compiler features that didn't work out of the box in our
CI images. We'll eventually want to upgrade, but for now Slang 3 is
sufficient to get the ball rolling.
See https://github.com/MikePopoloski/slang for details on Slang.
Co-authored-by: ShiZuoye <albertethon@163.com>
Co-authored-by: hunterzju <hunter_ht@zju.edu.cn>
Co-authored-by: 孙海龙 <hailong.sun@terapines.com>
This turned out to be a bad idea. We're still using Cap'nProto for Cosim, just with the message being a blob which is already encoded by the client. This is nearly identical to what happens in hardware, just Cap'nProto/DPI as the transport layer.
Goodbye old frenemy.
Upstream now has option for installing these components for use in downstream standalone builds:
llvm/llvm-project@0807986 .
Look for (and prefer) this approach, and update our LLVM builds that we install to use this.
Some of our CMake code which is only used in Capnp builds uses newer CMake
features. Since most compilations are not capnp builds, only require the new
version for those builds.
Add the z3 include directories as system includes, not normal includes, to the
circt-lec tool. Including the z3 headers this way will prevent clang from
putting out warnings on code in the z3 headers.
A logical equivalence checking tool for CIRCT. As of now it covers some
basic `hw` operations and the whole `comb` dialect. Z3 acts as the
logical backend and has been introduced as a build dependency for the
tool. Furthermore, regression tests for part of the implemented
operations and features have been written.
Co-authored-by: Hideto Ueno <uenoku.tokotoko@gmail.com>
This doesn't seem to be working, drop for now.
There should be a way to leverage the unittest CMakeLists.txt
instead of having these rules for them ourselves.
This reverts commit 21220aadb6.
PR #4409 disabled this for our unittests themselves, but
these warnings are still emitted when building llvm_gtest_main
in the non-unified build scenario where we have our own build rule.
Would be nice to remove all this.
When we build CIRCT as a standalone project (not a unified build), we
build gtest from scratch for our unit tests. This is currently
hard-coded to link against pthreads, which does not work on Windows. We
can use the built in `Threads::Threads` cmake library which is more
portable. This fixes the unit test linking on Windows.
1. test: tweak test discovery to enable unittests, fix deps var.
Discovery will find the generated lit.site.cfg.py, which
knows how to load the lit.cfg.py.
This could be gated on whether we're building "standalone",
as flang does, but that still doesn't work as we are not part
of the config mapping.
cc #2750.
Also fixup typo in variable name, .._DEPS -> .._DEPENDS.
2. cmake: gtest is available if built with LLVM, set accordingly.
We only include the unittests directory if we think the GTEST bits
are available, which we were not indicating in the non-standalone case.
Fix this, and FWIW this is also done in flang's CMakeLists.txt .
3. [CI] Add check-circt-unit to testing.
This commit introduces the base classes and utilities to implement
emission patterns and an emission printer which takes the role of a
driver that can be called in a circt-translate pass. Also includes
emission patterns for the builtin module and SCModule operations to
(1) allow to implement some basic unit and integration tests
(2) show the reviewer how emission patterns look like using this
infrastructure.
Icarus verilog v11, released in 2020, adds support for important constructs such as `always_ff, always_comb` in SV. Since virtually all non-trivial circuits will leverage these constructs during SV emission, it seems sensible to require an `iverilog` version that actually is able to simulate the circuits we generate.
This PR adds a functionality to include build information in output files.
The format of the version string is `<releases tag name>-
<how many commits since the tag>-g(means git)<current commit hash>[-dirty]`
Two cmake flags are added to control version strings,
`CIRCT_RELEASE_TAG_ENABLED` (default is On) and
`CIRCT_RELEASE_TAG` (default is `circtorg`).
If `CIRCT_RELEASE_TAG_ENABLED` is false, the version string becomes
"unknown" and cmake script is ran only at the first cmake configuration. Example,
```
$ cmake .. -DCIRCT_RELEASE_TAG=pycde
// Generated by CIRCT pycde-0.0.5-28-ge846cf26e
module Bar(
$ cmake .. -DCIRCT_RELEASE_TAG=sifive
// Generated by CIRCT sifive/0/9/0-31-ge846cf26e
module Bar(
$ cmake .. -DCIRCT_RELEASE_TAG_ENABLED=Off
// Generated by CIRCT unknown git version
```
Co-authored-by: Hideto Ueno <uenoku.tokotoko@gmail.com>
CMake 3.20 will result in many warnings on this policy.
This commit silence it with the use of 'old' behaviour.
And CMake 3.23 does warn it and simple use 'old' behaviour.
Probably we can remove this when minimal cmake version up to 3.23.
If questa or vivado are not found, `iverilog` is used to run supported tests. Tests which cannot be executed using this simulator can be disabled by adding `// DISABLED: ieee-sim-iverilog` or `// DISABLED: iverilog`.
Icarus verilog tests can be disabled altogether by passing `-DIVERILOG_DISABLE=ON` to cmake, similarly to other simulators.
resolvesllvm/circt#879
Add an implementation of the SystemVerilog type system to the Moore
dialect, modeled after the one in Moore's Rust codebase:
https://github.com/fabianschuiki/moore/blob/master/src/svlog/ty.rs
This is the first step towards migrating a larger chunk of the Moore
codebase into CIRCT, as it allows Moore's codegen to start emitting
higher-level operations (e.g., `moore.mir.concat`, to be added later)
instead of directly dropping to LLHD/HW. Doing so will allow us to
eventually move the codegen over into CIRCT, and start work on
implementing the type checking and type inference on the higher-level
operations.
My hope is that we might eventually be able to reconcile the Moore types
and some of the higher-level operations with the SV dialect, since both
work with SystemVerilog, albeit for two diametrically opposed purposes.
The types are designed to very clearly distinguish between packed and
unpacked types, and provide a certain level of guarantees about the
structure of nested types through C++ types. For example, struct
aggregate types and typedefs/decltype constructs come in a packed and
unpacked flavor to enforce proper nesting of these types.
Where user-defined types are involved, for example through structs and
typedefs/decltype, the MLIR types aim to capture enough information to
faithfully reconstruct the type as it was originally formulated by the
user. This helps provide good and understandable diagnostics. As a
concrete example, integer types capture whether their sign was provided
explicitly by the user, in order to distinguish `int` and `int signed`,
despite those two types being semantically identical.
This commit also adds a `unittests` directory as seen in LLVM and MLIR,
to test the human-readable serialization of the Moore types and other
type attributes.
Update the `cmake/modules/CMakeLists.txt` file and friends such that the
config file also includes the `CIRCT_TOOLS_BINARY_DIR` variable, and the
generation of that file resembles that in MLIR more closely. This should
make it easier in the future to use some of LLVM's cmake utilities.
Update the `install` commands concerned with the CIRCT header files to
match the MLIR style: one for `circt` and `circt-c` in the source tree,
and one for `circt` and `circt-c` in the build tree.
This only affects out-of-tree users of CIRCT and in the worst case
provide additional header files than what they have seen so far.
Not sure if this is from cmake changing the file name, or being more pendantic, but we now match the actual capitalization of the file distributed by cmake.
After CMake 3.18, we are able to limit the scope of the search to just
Development.Module. Searching for Development will fail in situations
where the Python libraries are not available. When possible, limit to
just Development.Module. See:
https://pybind11.readthedocs.io/en/stable/compiling.html#findpython-mode
The verbatim op can be used for macro substitution with values. This PR adds
support for macro substitution with symbols.
For example,
```mlir
sv.verbatim "MACRO({{0}}, {{1}} reg={{4}}, {{3}})"
(%add, %xor) : i8,i8
{symbols= [@reg1, @module1, @instance1]}
```
In the above operation, `0` and `1` will be replaced by `%add` and `%xor` ,
`4` with the verilog name of the symbol `@instance1` and `3` with the
verilog name of the symbol `@module1`.
Changes in this commit:
1. Add the optional array of symbols as an attribute to the `VerbatimOp`
2. Add a type constraint for an array of `FlatSymbolRefAttr`, this can be pushed to `mlir`.
3. Update `ExportVerilog` to get the verilog name for any symbol. Most of the changes
in `ExportVerilog` is just to ensure the final symbol names can be tracked.
4. Update docs and test cases.
`equiv-rtl.sh` is a utility script used to test formal equivalence in
our integration tests. This change adds it as a tool which Lit knows
how to find instead of using a relative path to invoke the script.
cepheus