https://open-source-silicon.dev logo
Join Slack
Powered by
My idea is, long-term, we'd keep the Tcl API intac...
# openlane
d
My idea is, long-term, we'd keep the Tcl API intact for all the scripts and stuff, but we'll slowly rewrite parts of OpenLane in Python.
o
Coudl we please do this as an Edalize backend? That way we have most of the external interfaces and a lot of support infrastructure in place. It has been my plan to slowly lift out piece by piece from the OpenLane TCL (starting with yosys) and call the individual tools directly from Edalize. It would kill me if a separate incompatible project was started on this
The current OpenLane Edalize backend is intentionally opaque to allow for piecewise internal restructuring
d
I would like to know what you mean by "an edalize backend" first
o
Right. So Edalize is a Python library that provides an abstraction interface for EDA tools. We currently support ~30 different tools and flows such as Quartus, Vivado, Icestorm, ModelSim, VCS, Verilator, SymbiFlow, spyglass and since last year OpenLane
d
I'm aware. The thing is, I'm not sure what building OpenLane as an "edalize backend" entails.
o
Right
So. There is already an Edalize OpenLane backend that looks like this https://github.com/olofk/edalize/blob/master/edalize/openlane.py
This creates some TCL files that sets up the design files, TCL files to be sources, parameters, defines etc and then calls into flow.tcl
d
So writing it as an Edalize backend would entail the OpenLane flow elements themselves being a Python module that this python file can simply import?
o
What I want to do is to let Edalize take over the responsibility of flow.tcl basically
d
That depends on your answer to my last message
o
I think, not necessarily. But I'm not totally sure I understand
Generally, I try to avoid doing too many things at once, so my intended plan of attack would be to first of all break out yosys because Edalize already has a fancy API for calling into yosys. The results of the first yosys step could then be fed back into the current tcl flow
d
Alright, so to be perfectly clear- I'm not opposed to ensuring that the Python modules that will be gradually rewritten are somehow designed in a manner that would easily integrate with Edalize. However, the idea of making edalize the "standard" way of utilizing OpenLane is a decision far above my pay grade. The yosys thing for example is a no-go: we'd keep the yosys part of the flow, but what we can do is expose other steps and elements to Edalize provided that you're willing to assist with the process.
Keep in mind though: this is very long term. I have bigger fish to fry at the present moment.
o
I see. We probably have very different needs here. Still, give me a ping if you're moving towards some kind of Python interface. I will likely split out yosys in the current Edalize backend eventually anyway. Mainly because that gives mes access to some missing features that are available in the other Edalize backends that utilize yosys
Open in Slack
PreviousNext
Powered by