Hello Paul. My notes below. On 04/28/2018 06:01 AM, p4w5 wrote:

Before dealing with this I would opt to have some common core dealing with lefdef reading and writing. Is there maybe already some tool doing this? In the last week I started going through the lefdef ref manual 5.8 and to manually parse lef files into some c++ structs, see[1] to have a look yourself. From quite some big lef files it already can parse >90% the mayor chunck. Being quite uncommented and not tougth through to much, but before wasting more time on this I wanted to get some feedback.

Is the general lefdef-lib thing a idea worth spending more energy on? Is there already another attempt to do so in progress?

Yes, you are right, the tools mostly dealing with LEF/DEF formats somehow. But for me, LEF/DEF is nothing more than an export format. Let's look at the dataflow for the ASIC design to describe why I think so. First, someone is writing the RTL [0] code, mostly in Verilog [1], VHDL [2] or any other Hardware Description Language which is useful for that. Than a Synthesizer tool [3] translates this behavioral description into a so called netlist [4]. While the netlist is nothing more than a list of dedicated primitives like gates, Latches and other cells, this Synthesis tool already needs a bunch of information (even the timing/delays) about the primitives which are should used later in the layout. Yosys [5] as an FOSS synthesis tools uses the so called BLIF format [6] for that. Additionaly, someone want to add the stuff for testability here. Now, the netlist represents somehow the RTL design with primitives from the Standard Cell Library (BTW, I am developing the Standard Cell Library here [7]). Second, the designer now starts the layout by assigning the values for size of the die, doing all the floor planning stuff. [8] Here the physical sizes / layer of the primitives / Standard Cells are very useful to calculate the space, that is the point where LEF [9] and DEF [10] cames in. Both formates are just layer informations - they are not suitable for the synthesis step before. Third, the Place and Routing step needs the exact timing of the primitives / cells again while re-iterating many times through the netlist and find the best placement and routing regarding the constraints which already was used for the synthesis. And this step should use already technology information based on Resistance and Capacitance (every line is a RC-circuit [11] which produces a delay), called wireload model. Long distances producing longer delays, to short lines are also avoidable regarding the Setup- and Hold-Violations [12] Forth, while the design matches all constraints (in the meaning of operations frequency for every part) etc, now the layout of the die, the placement of the IO-Cells, the clock tree, the placed cells and all the wires are now transformed to the GDSII file [13] which goes to the foundry. So, from LEF / DEF to GDSII is the last step. IMHO, we should look at the ALF file format also [14] for the library. There are all informations we are needing for all steps, from synthesis to place'n'route and GDSII generation in one file format. This pure ASCII file format became a IEEE 1603 and IEC 62265 standard. But this format is dedicated for library elements (the Standard Cell Lib) - I am not sure we can use / re-use / expand it to our internal file format of the layout tool chain. I guess, we should use it for the layout also, keeping all the information together in one file format which could make a difference for our FOSS tools. All the tools for ASIC layout are quite old and limited; using cell delays (aka timing) or physical parameters of the process for better results are difficult with that old tools. While using ALF even for the layout, we are able to press the button and generate export formats (for user tools). On my list there are already as mentioned - BLIF - LEF / DEF and not mentioned - SDF. [15] I am currently organizing the hackathon for the tool chain - I'll send out today more about that. Let's make it better, let's make a difference! Regards, Hagen Sankowski [0] https://en.wikipedia.org/wiki/Register-transfer_level [1] https://en.wikipedia.org/wiki/Verilog [2] https://en.wikipedia.org/wiki/VHDL [3] https://en.wikipedia.org/wiki/Logic_synthesis [4] https://en.wikipedia.org/wiki/Netlist [5] http://www.clifford.at/yosys/ [6] http://bear.ces.cwru.edu/eecs_cad/sis_blif.pdf [7] https://github.com/chipforge/stdcelllib [8] https://en.wikipedia.org/wiki/Floorplan_(microelectronics) [9] https://en.wikipedia.org/wiki/Library_Exchange_Format [10] https://en.wikipedia.org/wiki/Design_Exchange_Format [11] https://en.wikipedia.org/wiki/RC_circuit [12] https://en.wikipedia.org/wiki/Flip-flop_(electronics)#Timing_parameters [13] https://en.wikipedia.org/wiki/GDSII [14] https://en.wikipedia.org/wiki/Advanced_Library_Format [15] https://en.wikipedia.org/wiki/Standard_Delay_Format