Roadmap for Yosys verilog frontend?

[MikePopoloski]

Is there a plan or a roadmap for moving yosys-slang into the upstream Yosys repo and getting rid of the old Verilog parser? I've seen PRs like this one going by and it seems kind of a shame for people to be doing lots of work on something like this when they could instead be focusing on synthesis logic or whatever. Is there anything I should be adding to slang to increase compatibility to make it easier to achieve this?

[povik]

Is there a plan or a roadmap for moving yosys-slang into the upstream Yosys repo and getting rid of the old Verilog parser?

There's no concrete plan. I agree it would make sense to fold yosys-slang into Yosys. I think it'd need an amount of rework of Yosys and a bit of will to break user workflows in order to retire the existing frontend.

I'm also interested in expanding the code in yosys-slang to be a generic netlist elaboration component usable beyond Yosys, e.g. with https://github.com/prjunnamed/prjunnamed or a different project. I'd say this is orthogonal to integration into Yosys. If it grows into a generic component this component can be a submodule of the Yosys repository.

Is there anything I should be adding to slang to increase compatibility to make it easier to achieve this?

Thanks for reaching out on this. I can think of this module header syntax with omitted port list accepted by Yosys. I think it's non-standard, and is used throughout the Yosys technology library. I can do more testing on the technology library to find potential incompatibilities.

Cc @nakengelhardt @KrystalDelusion @Ravenslofty @widlarizer and the rest of the Yosys team. Please leave thoughts regarding non-standard Yosys syntax and the prospect of integrating yosys-slang.

[KrystalDelusion]

Hopefully all of the non-standard features are documented, but if there are any that aren't then they should be 😛

[nakengelhardt]

It would be nice to be able to get rid of read_verilog, but it's unfortunately baked pretty deep into Yosys currently. More so than small non-standard syntax features like the omitted headers (which would be a bunch of busywork to modify and makes a few scripts that autogenerate them a bit more complex, but is ultimately not a difficult change), I think the biggest roadblock right now is the ability to request to re-derive a module for new parameter values from anywhere in the flow. I guess @povik this is mostly a question for you, can yosys-slang provide something that works like module->derive() the way it's used currently in Yosys?

On an adjacent topic, I've had a chat with Tristan from GHDL at a conference recently about how to support mixed-language desgins, and since then I have this vague half-baked idea that we should really all sit down sometime and figure out an API that all frontends could implement that would let them work together...

[povik]

I'm mentioning the omitted headers as they are user-facing and potentially used in out-of-tree libraries.

I guess @povik this is mostly a question for you, can yosys-slang provide something that works like module->derive() the way it's used currently in Yosys?

That can be implemented on top of slang though I think it should be a different API, i.e. yosys-slang shouldn't be required to use RTLIL::Module to represent modules before they are derived for concrete value of parameters.

[whitequark]

On an adjacent topic, I've had a chat with Tristan from GHDL at a conference recently about how to support mixed-language desgins, and since then I have this vague half-baked idea that we should really all sit down sometime and figure out an API that all frontends could implement that would let them work together...

The RPC frontend has a sketch of such an API. Whatever the implementation is, I will assert that it needs to support out-of-process use cases.

[povik]

@MikePopoloski an interesting case of non-standard Yosys feature are the (* force_downto *) (* force_upto *) attributes put on ports with parametric width: https://github.com/YosysHQ/yosys/blob/9334a5c2757e67a9e692e42126f50b2acb018d6d/techlibs/sf2/cells_map.v#L30

If you write

(* force_downto *)
input [WIDTH-1:0] A;

the attribute is meant to ensure the port has zero width when WIDTH = 0. Adding compatibility for this might open slang to the existence of zero-length vectors which I'm not sure can occur otherwise.

[MikePopoloski]

Where a zero length signal essentially disappears from the design after elaboration? slang doesn't have a way to represent such a type right now but it could very easily resolve to the ErrorType, which ensures that it silently invalidates all dependent expressions involving it.

[povik]

I think the Yosys treatment is that the signal exists but has zero length so you can still query it e.g. with $bits.

[Ravenslofty]

I think a lot of the Yosys-specific language quirks have evolved from needing to handle transitive situations like a zero-width cell that (I assume, because Verilog is Verilog) can't happen in input Verilog.

[povik]

Right, to give more background to Mike: this comes about because the Yosys internal cell library can have zero-width ports as an edge case, and then Verilog rules are used to describe mapping of internal cells to other internal cells or technology primitives.

We would need to vet the rules but the ErrorType resolution and a small fixup when importing the elaborated result into Yosys might be enough to support the existing rules. It's unlikely they actually apply $bits to the port.

[MikePopoloski]

Of course anything is possible with enough work. Probably it's not super hard to support zero width types in the slang type system in fully supported fashion, you just have to hit every possible use of it, think about how it works in constant expressions and functions, etc.