-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GateMate SystemVerilog support #3
Comments
Insight from Patrick Urban of Cologne Chip (@pu-cc) : "... from what I have read, you are also trying to implement this on ulx3s with lattice ecp5, right? Are you also using Yosys? You should have noticed this too, as this is not a GateMate-related issue but is due to incomplete SystemVerilog support in Yosys. Another approach is to use |
We understand that as-is Yosys comes with very rudimentary support for SV. However, given that (contrary to LatticeSemi), Yosys is the only synthesis tool for GateMate, would it not make more sense for CologneChip to prepackage their version of Yosys with https://github.com/chipsalliance/synlig plugin for everyone?! While we can also do that, and are doing it, rather than forcing all users into repeating this same work, it seems more beneficial for CologneChip to do it once for all, by making it the standard part of toolkit and install instructions, which currently don't mention it at all: |
Given that the entire Synlig Yosys story is confusing, it is even more important for CologneChip to properly package it and validate at their very source. The problems are multi-fold:
@cliffordwolf for her first-hand Yosys insights on this topic. |
This syntax appears to be supported in Yosys 0.42. |
@gtaylormb have you been able to synthesize your entire OPL3 RTL with this new, fresh-from-the-press Yosys 0.42 ? |
Nope, it still doesn't like package imports :( |
Any luck with package imports when Synlig plugin is also in the play? @tgorochowik |
No, doesn't look like it unfortunately. |
Eh, looks like the Makefile is pretty non-functional.
This was calling the Verilog Makefile target. Imports potentially working, running into some other error saying it can't find the top level module, opl3. Anyway I gotta get to sleep but good luck |
Had a chance to dig a little more into this. Indeed the import issue was because the default Makefile target If I update the Yosys path to the latest version (0.42) that I compiled myself I get the missing top level module Anyway, it appears SystemVerilog support in Yosys/Synlig has a long way to go based on those warnings. |
Yeah, I see what I can do to get For now, I've added it to the smoke-tests in the syntax-checkker/formatter/language-server Verible CI. |
... is it then fair to say that the main part of the problem comes from the fact that the latest synlig comes packaged with older yosys? And, if we were to compile the latest Great that adding OPL3 design to the synlig SV test suite is under consideration. Is the same suite of tests also used for SV2V validation?
BTW, we love Verible -- It's a super-cool tool! |
Yes, currently the thing with synlig is that there is some API changes in Yosys which does not make it compile anymore with the latest Yosys. Getting that fixed up would be great. At least |
@hzeller Re: "sv-test... independent of the tests that the projects do..." and "... Zach probably has other tests as well..." It seems that the ChipsAlliance runs and publishes their own assessment of the level of each tool's SV support. Yosys is apparently also subject to this independent, 3rd-party compliance scrutiny.
While @TarikHamedovic is soon to report the results of his opl3_fpga experiments with SV2V, if both Synlig and SV2V end up as disappointments, is there another path to try? |
I won't discourage anyone from pursing any technical end, but synlig has a number of things working against it. Namely, the solution is split between 4 repos (Surelog, Synlig, UDHM, Yosys) all of which need to be in perfect sync to make things work. Synlig also relies heavily on private Yosys APIs which the upstream Yosys team is under no obligation to support. If it were up to me I would look more heavily into https://github.com/povik/yosys-slang which relies on the slang parser, and is an overall less complicated solution. |
Thank you, great tip, we are in the process of trying opl3_fpga with both
|
I'm of course eager for you to give sv2v a shot, and welcome any bug reports, feature requests, or contributions. Indeed sv2v has hundreds of its own tests, generally focusing on just a few features at a time. I do use the sv-tests dashboard from time to time to check in on its assessment of sv2v. |
... based on @TarikHamedovic and @tarik-ibrahimovic thus-far testing, the SV2V is more mature than Yosys-Slang, and more stable than Synlig.
@zachjs, may we suggest to add both OPL3_FPGA and our openCam-SI SystemVerilog RTL to your personal SV2V test suite. @hzeller please consider adding the latter to both |
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. |
While both
|
You are right and yes! I can't really say more at this point than this: we are currently formulating what exactly we want from a SystemVerilog frontend, likely based on Slang. |
... it sounds like you are considering to integrate If this work on formulating your plans is in the public domain, please share link to the relevant discussion forum... |
SVase uses Slang as its parser library (ie it is built on-top of Slang). What we are currently looking into is to build a Yosys frontend that directly uses Slang as a library. For our current projects like Basilisk we actually use Morty (our own tool) to collect files and pickle them into one single file (this is not super necessary but makes it easier to exchange the RTL with others). Then we use SVase to resolve the sometimes rather complex parameters we have and finally SV2V for the bulk of the code. |
... given @gtaylormb thumbs up for Slang Linter, if anyone knows of comparisons with Verible, please share links... |
@TarikHamedovic if, with @zachjs |
After trying out different available solutions, |
Using the line:
logic [PIPELINE_DELAY:1] [BANK_WIDTH-1:0] bankb_p ;
Gives an error:
ERROR: syntax error, unexpected '[', expecting TOK_ID or '#'
The error can be fixed using an unpacked array, but sometimes we need a packed array.
The text was updated successfully, but these errors were encountered: