[Libre-silicon-devel] Standardized Data Structures Lef/Def routines
hsank at posteo.de
Sat Apr 28 15:08:22 CEST 2018
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
> 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 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  code, mostly in Verilog , VHDL
 or any other Hardware Description Language which is useful for that.
Than a Synthesizer tool  translates this behavioral description into
a so called netlist .
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  as an FOSS synthesis
tools uses the so called BLIF format  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 ).
Second, the designer now starts the layout by assigning the values for
size of the die, doing all the floor planning stuff. 
Here the physical sizes / layer of the primitives / Standard Cells are
very useful to calculate the space, that is the point where LEF  and
DEF  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  which produces a delay),
called wireload model.
Long distances producing longer delays, to short lines are also
avoidable regarding the Setup- and Hold-Violations 
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  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  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
- LEF / DEF
and not mentioned
- SDF. 
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!
More information about the Libre-silicon-devel