Channels
#openlane
Title
d
donn
01/28/2022, 12:03 AMMy 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
Olof Kindgren
01/28/2022, 2:05 PMCoudl 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
donn
01/28/2022, 2:06 PMI would like to know what you mean by "an edalize backend" first
o
Olof Kindgren
01/28/2022, 2:08 PMRight. 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
donn
01/28/2022, 2:08 PMI'm aware. The thing is, I'm not sure what building OpenLane as an "edalize backend" entails.
o
Olof Kindgren
01/28/2022, 2:08 PMRight
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
donn
01/28/2022, 2:10 PMSo 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
Olof Kindgren
01/28/2022, 2:11 PMWhat I want to do is to let Edalize take over the responsibility of flow.tcl basically
d
donn
01/28/2022, 2:12 PMThat depends on your answer to my last message
o
Olof Kindgren
01/28/2022, 2:12 PMI 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
donn
01/28/2022, 2:16 PMAlright, 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
Olof Kindgren
01/28/2022, 2:21 PMI 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