Ensuring smooth Yosys-to-Synlig compatability and tracking

[chili-chips-ba]

Feature Description

We understand that Yosys APIs are somewhat fluid, which then makes it difficult for Synlig to keep pace with Yosys updates. That leads to an awkward situation where the latest Yosys cannot be used with the latest Synlig, see this issue.

We also strongly recommend adding @gtaylormb OPL3_FPGA design to the suite of Yosys regression tests.

[whitequark]

That seems like something the Synlig team should be doing.

[chili-chips-ba]

Agreed.

Yet, in the spirit of community and working towards our common goal, Yosys team should do their most not to make Synlig life too difficult. This is to raise awareness about the problems that fluid APIs create downstream.

Interestingly, Yosys that's packaged with GateMate official tools is also very old. It'd be interesting to hear CologneChip folks' take on why it is so, esp. whether it is related to API (in)stability... @DadoCCAG, @pu-cc

[whitequark]

This is to raise awareness about the problems that fluid APIs create downstream.

I think of such issues in terms of a contract. For example, Amaranth has a clearly defined and documented compatibility contract: with very few minor exceptions, every single feature that gets changed or removed has a one release grace period where this change is indicated with a clear warning. This allows downstream code to adapt.

In contrast, Yosys as a whole does not have such a clearly defined contract. (I attempt to provide a comparable contract in the bits I maintain, like CXXRTL.) Unless Yosys maintainers explicitly agree to such a contract it would not be reasonable to hold us to it; and the mere existence of a dependent codebase that would potentially benefit from a contract does not create such a contract, even if the codebase is especially useful or popular. This is the only way to prevent burnout that is so endemic to open source work.

[whitequark]

Ultimately, the first question to be answered here is "what is the contract that Yosys maintainers are willing to create with other projects?" Only after this question is answered can we discuss extending the regression test suite, etc.

In practical terms, the Yosys IR (RTLIL) is considered backwards compatible, arguably with the exception of "sync rules", which are tied to the Yosys Verilog frontend despite being notionally part of the IR. So I would say that RTLIL is de facto a part of a compatibility contract. The C++ API isn't and I don't believe anyone has ever implied that it is or would be.

For this reason, Amaranth interacts with Yosys through the textual RTLIL representation, and it has encountered almost no API breakage over the years. (What breakage we did encounter was due to my own inexperience and a choice to depend on "sync rules" and some other unstable parts of Yosys, like the implementation details of the "proc" pass.)

Today, Synlig already has a choice: to interact with Yosys via the C++ API, or to do so via the textual RTLIL representation. The latter would be a one time cost that will have little to no ongoing maintenance burden. The former will have a maintenance burden placed either on Yosys developers or Synlig developers. For this reason the former choice seems inferior to me as an OSS developer interacting with Yosys.

[chili-chips-ba]

Thank you, very informative indeed!

And, while this API compatibility contract might be one of the reasons why Amaranth is growing and gaining on popularity, it sounds like the Synlig folks chose the wrong approach for interfacing with Yosys, and should have used RTLIL instead.

BTW, we are thumbs up for Amaranth and, as this sorry story with Yosys and SV keeps limping along, are considering to migrate more and more of new design creation to Python...

[whitequark]

@chili-chips-ba FWIW, regarding the constraint file issue, my Cologne Chip board arrives on Monday and once it arrives I might look at the issue more closer. It may be that there's a workaround for it that we're currently missing.

[chili-chips-ba]

... 2 cents, if it help, @pu-cc is working on integrating GateMate to LiteX

[povik]

Yet, in the spirit of community and working towards our common goal, Yosys team should do their most not to make https://github.com/chipsalliance/synlig/pull/2431 life too difficult.

The specifics here seem to be that we are touching the Yosys AST code (which despite its location at frontends/ast belongs to the Verilog frontend), and Synlig depends on this code out of tree. For the long term health of the project we can't stop making those changes as the Verilog frontend has a lot of technical debt for us to address.

Absent any formal contract around the C++ API we still try our best not to introduce breaking changes for plugins, but that applies more to the core kernel/*.h APIs that operate on netlists than e.g. the code in question here which we consider internal to the Verilog frontend.

Here's what I think we can do moving forward:

• the Synlig side copies out a frozen version of the part of the frontend they depend on, or

• in one way or another we make sure Synlig maintainers are notified of PRs touching the Verilog frontend so they can plan ahead. Usually it takes a while for frontend PRs to get merged after they first show up

[chili-chips-ba]

Does Yosys have an established working coordination group with Synlig developers? Is there a formal channel in place for the communication of this nature?

[povik]

There's no communication as far as I know

[chili-chips-ba]

@rowanG077 @kamilrakoczy @hzeller -- Who would be in the best position to comment on the Synlig project state and plans, including the creation of a communication channel with Yosys dev community?! After all, this plugin is Yosys :-)

[widlarizer]

You can find a link to the public Yosys Slack at https://yosyshq.net/yosys/

[chili-chips-ba]

... we found @zachjs SV2V do remarkably well compared to both Synlig and Yosys-Slang.

While that's moving our focus away from Synlig and onto SV2V, we recommend making our openeye-CamSI and opl3_fpga RTL part of Yosys regression tests for validation of the subset of SV that's supported natively.