Hi all, I would like to ask what is the status of CIRCT’s support for Verilog dialects.
I see that with Moore we are able to convert Verilog to MIR and thus further processed by CIRCT, but now it seems upstream LLVM has broken the Moore build.
Is there an alternative in CIRCT for parsing Verilog?
2 Likes
There isn’t currently a verilog parser. It will certainly come at some point, but it hasn’t been on anyone’s critical path.
2 Likes
I’ve been toying with adding slang as a SystemVerilog frontend to CIRCT a while back, but I haven’t gotten all that far beyond pulling the library in as a dependency, resolving the exception usage issues, and doing some first coarse parser calls: GitHub - fabianschuiki/circt at slang-frontend
3 Likes
Very happy to see that CIRCT will be capable of getting slang as SystemVerilog frontend, and I plan to do the same thing that utilize slang to handle Verilog / SV.
nice job!
But when I build the project, it seems the -fno-exceptions -fno-rtti flags make the slang build fail?
If anyone know how to solve it?
Yeah LLVM enforces no exceptions, but Slang uses them internally for a few things. Is this a build based on the slang-frontend branch in fabianschuiki/circt? I did some work there to get around the limitation by having Slang compiled with exception support separately and having a wrapper that intercepts exceptions before they can escape into LLVM land. But the unified build there might still be broken 
Yes, I cherry-pick commits in fabianschuiki/circt to the latest master branch and build.
It seems that we also need to add -fexceptions and -frtti flag to the slang::slang target.
Another thing we need to do is to add the -DFMT_HEADER_ONLY to slang::slang target.
With the above changes, I can build the circt-translate binary. But when I run circt-translate --import-verilog basic.sv, the program coredump.
After build success, I run the circt-translateand the program coredump:
It seems something wrong when the LineDirectiveInfo destroy.
Weird that this comes up in the destructor. I’d suspect that this isn’t a slang bug, but probably something else going on. Smells like a use-after-free issue somehow. Have you tried running your command through Valgrind to see if there are any dubious memory accesses?
By using gdb step by step, I finally find the g++ Debug build did not initialize all members in slang struct：slang::SourceManager::FileInfo::FileInfo()，but the Release build don’t have the problem.
I don’t known the reason, is there anyone has idea?
That’s very suspicious! I’d suspect the slang folks to notice any uninitialized members during testing. Could this be some memory corruption, where some code accidentally writes over the memory of the FileInfo, making it look like the struct wasn’t initialized properly? Grasping at straws…
I use gdb step by step, it jumps the initilize process of some private members in FileInfo.
I have push my change to https://github.com/hunterzju/circt/tree/slang-frontend.
It is really confusion. And if you have time, maybe you can check if it can be reproduced in your env.
And my compiler is, I am not sure this can be reproduced in clang++:
g++ (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
The reason has been found:
slang need -DDEBUG definition while the circt gives the -D_DEBUG defination.
1 Like
I have build the branch - “slang-frontend” successfully. Is there a way to build it using same installed llvm instead of giving “build” folder path?
From the README.md, below command works -
-DMLIR_DIR=$PWD/../llvm/build/lib/cmake/mlir \
-DLLVM_DIR=$PWD/../llvm/build/lib/cmake/llvm```
but when I use installed folder, cmake configure step fails -
-DMLIR_DIR=$PWD/../llvm/install/lib/cmake/mlir \
-DLLVM_DIR=$PWD/../llvm/install/lib/cmake/llvm```
Note - Above “install” is obtained from “make install” in build directory.
I get below errors if I build circt using installed binaries -
dependency target not of target "check-circt" does not exist
dependency target FileCheck of target "check-circt-capi-makefiles does not exist....
Last time I checked, MLIR and CIRCT can’t be built from an installed version of LLVM. They need a few files from the source tree to build. Not sure if this has changed in the meantime, but your experiment with install suggests that you still need a source tree for the build.
@fabianschuiki - I noticed that you have added a test “test/Conversion/ImportVerilog”. I have a query regarding it.
Do you know why multidimensional packed array code is being generated first before single dimension array even though it is written before it?
module PackedRangeDim;
logic [2:0] do;
logic [0:2] d1;
endmodule
module MultiPackedRangeDim;
logic [5:0][2:0] vo;
logic [0: 5][2:0] v1;
endmodule
Below code is getting generated -
moore.module @MultiPackedRangeDim {
%v0 = moore.variable : !moore.packed<range<range<logic, 2:0>, 5:0>>
%V1 = moore.variable: !moore.packed<range<range<logic, 2:0>, 0:5>>
}
moore.module @PackedRangeDim {
%d0 = moore.variable: !moore.packed<range<logic, 2:0>>
%d1 = moore.variable: !moore.packed<range<logic, 0:2>>
}
which makes it difficult to put in LIT test as it expects single dimension packed array first.
1 Like
Yeah you raise a great point. I think the problem is that we have to do some form of depth-first traversal of the Verilog module graph to convert them into MLIR moore.modules. This is not strictly necessary from MLIR’s point of view, but necessary on the slang side to collect all the concrete parametrizations of a module. One thing we could do is traverse the slang AST first, collect all modules to be emitted, and then do another traversal to try and emit the different parametrizations of a module in the same order as the modules were defined in the input file.
I tried to build based on the slang-fronted branch in fabianschuiki/circt and I turn off CIRCT_SLANG_BUILD_FROM_SOURCE option in order to use my local newest slang. After some option was set it was successfully built. However when I run the circt-translate --import-verilog to test basic.sv the program coredump:
1 Like
That’s an interesting crash @albertethon! It’s weird that it crashes at ImportVerilog.cpp:155… that’s just adding a client to the Slang diagnostic engine. There shouldn’t be anything fancy going on. The slang-frontend branch was originally built against slang v2.0. What version are you building against? Might be worthwhile updating the branch to just whatever is the newest version!