Integration with SVase?!

[chili-chips-ba]

@phsauter, taken from here:

"... we also had a good amount of problems dealing with our (PULP) SystemVerilog, especially around properly resolving parameters. For this reason we made SVase it is also based on Slang, just like Yosys-Slang but we only use it as a source-to-source pre-elaborator. Specifically we propagate all parameters to the scope where they are used and we uniquify all unique parametrizations of modules and unroll all generate statements..."

While both SV2V and SVase preprocessing steps can be incorporated into a build flow, there is still advantage in the organic integration of these two preprocessors. Is that on the radar screen?

[zachjs]

Can you help me understand the specifics of your proposal here? If there is some bug in sv2v that requires additional preprocessing, shouldn't we try to fix sv2v itself?

[chili-chips-ba]

From our initial experience with SV2V, which is at this point undoubtedly rather limited, SV2V is a robust SV preprocessor. However, the sv-tests results are still showing red for some of the essential RTL constructs:

And the following 3 important cores are also in red:

They have been in red for quite a while. Therefore, just as an idea, if it's quick and easy to turn them into green by integrating SVase, even if temporarily, would that not relieve the pressure and open more time to "fix issues within sv2v itself" the proper way?!

We are sure that @phsauter is in the position to provide more datapoints and reasons that made ETH Zürich create SVase preprocessor addition to the sv2v, such as: "... specially around properly resolving parameters..." possibly even related to their recent Occamy tapeout...

[zachjs]

I haven't used SVAse, and so don't know how many of the sv-tests failures would actually be fixed if it were "integrated" into sv2v. If there is "pressure" from some user to resolve an issue that SVase addresses, why shouldn't I just tell them to use SVase as a temporary workaround?

As far as I can tell, users already have a choice whether or not to incorporate SVase into their flow. Do they not? What do you envision this "integration" entailing? How specifically will users benefit? Certainly it could not be enabled by default without disrupting the usage of existing users. Then, what it will it take to accomplish this integration? What will be the ongoing maintenance overhead? Will the installation of sv2v be made more complex through this integration? What if users come to depend on this integration, and then the SVase project moves in another direction? What breakage risk would I assume by incorporating SVase and all of its dependencies? Will I need to maintain a fork of SVase? Of Synlig?

As it stands now, I am not inclined to integrate such an external project into sv2v. This would effectively require that I maintain another Verilog frontend. I already maintain 2 of them!

[phsauter]

I think there may have been a misunderstanding from what I said in another issue.

SVase is intended as a standalone tool. It is fundamentally a SystemVerilog pre-elaborator built around Slang.
The original idea behind SVase is that if you encounter some construct a certain tool can't parse, you can simplify it by writing some comparably simple code.

We ended up using it to propagate parameters (and to do so, unroll and uniquify the hierarchy) since we saw some problems around that in our codebase. Then we use SV2V to convert to Verilog, which it does rather well.

I don' think there is any merit to integrating it into SV2V.

[zachjs]

@phsauter That makes sense to me. Would you mind sharing examples of inputs that don't convert correctly when passed directly to sv2v, but do work when pre-elaborated with SVase? This would help me improve sv2v, of course. I know that #265 can likely be worked around with pre-elaboration, but I'm interested in other potential areas for improvement!

[phsauter]

Next week I am short on time as I will be at FSiC and then I om on vacation but I will try my best to compile them. We really need (and want to) give proper feedback for the different tools with reasonable example designs but as I said, it has been a bit hectic.

There are two unrelated mentions of patches aimed at SV2V here.