Libraries: What the Tool Must Be Told

Part II · Module 21 · Chapter 21.4 · Libraries: What the Tool Must Be Told

Synthesis turns logic into real cells from a real technology. To do that it has to know which cells exist, what they do, how fast they are and how much area they take.

That information is in the technology libraries, and pointing the tool at the right ones is a surprisingly common source of results that are confidently wrong.

1. What the libraries supply

Three things, and the distinction matters for what goes wrong:

• Which cells exist — the logical functions available, and their pins.
• How they behave — delay, transition and power, usually as a function of input slew and output load.
• Under which conditions — a library is characterised at a particular process corner, voltage and temperature.

The third is the one that produces plausible wrong answers. A design mapped against a fast corner and signed off as if it were the slow one meets timing in the report and not in silicon.

2. Telling the tool

Every tool has its own variables and commands for this. The categories are consistent:

• A target library — the cells synthesis is allowed to map onto.
• Link libraries — everything needed to resolve references, including hard macros and memories.
• A search path — where to look, so the others can be named without full paths.

I am not going to name specific variables, because they differ by vendor and I cannot verify them here. Find yours once, using the discovery technique from Chapter 17.1 §3:

info commands *librar*
info commands *target*

and the tool's reference (Chapter 17.6). Write the answer down; it is the kind of thing that is obvious for a week.

3. Check the files before the run

Whatever the variable names, the paths are files, and files can be checked — the same discipline as Chapter 21.2 §4:

proc check_libraries {paths} {
    set missing {}
    foreach p $paths {
        if {![file isfile $p]} { lappend missing $p }
    }
    if {[llength $missing]} {
        error "[llength $missing] library file(s) missing: [join $missing {, }]" \
              {} [list LIB MISSING $missing]
    }
    return [llength $paths]
}

Run it before anything else happens. A library path that is wrong because a mount is not available, or because somebody moved the technology directory, should stop the run in the first second rather than fifty minutes in.

4. What goes wrong downstream

The registry purpose asks specifically about this, and the point is that none of these failures appear where the mistake was made.

No target library. The tool has nothing to map onto. Depending on settings it errors, or produces a netlist of generic logic that is not implementable — a design that looks synthesised and is not.

A missing link library. A reference the tool cannot resolve. This usually becomes a black box with no timing and no area — so the design appears smaller and faster than it is, and the gap is invisible until the block is integrated. That is Chapter 21.5's subject.

The wrong corner. The most dangerous, because everything works. The design maps, times, and reports clean numbers — against the wrong conditions. A fast-corner library used for setup signoff gives optimistic slack, and the chip fails at speed.

Mismatched versions. A library that does not match the one used by the next stage means two stages optimising against different data. The symptom is a design that met timing in synthesis and does not in place-and-route, which is usually blamed on the physical implementation.

5. Make the choice visible

Libraries are usually selected by the project setup rather than the synthesis script — which is convenient and is exactly the Chapter 17.4 problem: a setting that differs between two engineers and explains why their results do not match.

So print what you are using, every run:

puts "  target library : $target_lib"
puts "  link libraries : [llength $link_libs] file(s)"
foreach l $link_libs { puts "      [file tail $l]" }
puts "  corner         : $corner"

Four lines in every log. When two runs disagree, the first question is answered before anybody has to ask it — and when somebody asks "which corner was that signed off at" six months later, the log says.

6. A worked check

Putting the phase together:

set LIBS [list \
    [file join $TECH_ROOT lib slow.lib] \
    [file join $TECH_ROOT lib mem_slow.lib]]

check_libraries $LIBS
puts "  libraries: [llength $LIBS] file(s), corner $CORNER"
foreach l $LIBS { puts "      [file tail $l]" }

read_libraries $LIBS        ;# the tool command, whatever yours is called

Note the shape is identical to Chapter 21.2's file list: build the list with file join, check every entry exists, print what you are about to use, then hand it to the tool. Two phases, one discipline.

7. Exercises

Exercise 1. Name the three things technology libraries supply.

Exercise 2. Which of those produces plausible wrong answers, and why?

Exercise 3. Why check library files with file isfile rather than trusting the search path?

Exercise 4. What does a missing link library typically produce, and why is the design then misleading?

Exercise 5. Why is using the wrong corner more dangerous than having no target library?

Exercise 6. Two engineers get different synthesis results. What should the log already tell them?

Exercise 7. What does this phase have in common with reading the RTL file list?