Is CIRCT able to analyze Verilog

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?

There isn’t currently a verilog parser. It will certainly come at some point, but it hasn’t been on anyone’s critical path.

1 Like

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


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 :thinking:

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, 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?

It seems there is memory leak, thanks for your advice. I will try to figure it out.

1 Like

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
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.