[Libre-silicon-devel] Standardized Data Structures Lef/Def routines

Hagen SANKOWSKI hsank at posteo.de
Sat Apr 28 15:08:22 CEST 2018


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


More information about the Libre-silicon-devel mailing list