Expand LEF Support to include the technology components

[dan-fritchman]

The Lef21 docs begin with:

LEF is near-ubiquitously used IC-industry-wide for two related purposes:

LEF design libraries, primarily comprised of LEF macros, provide the physical abstract view of circuit designs.
Such abstract-views are commonly the target for layout-synthesis programs ("place and route").
They include a circuit's pin locations and requirements for physical blockages ("obstructions"), among other metadata, typically without including the circuit's internal implementation.
LEF technology descriptions ("tech-lef") provide a concise description of design-rules for assembling such cells, as commonly performed by layout-synthesis software.

Lef21 includes comprehensive support for parsing and writing LEF design libraries, primarily stored as its [LefLibrary] and [LefMacro] types. A select subset of tech-lef features are also supported, particularly those which blur the lines between technology and library data.

This issue: add the latter "tech-lef" content.
This will be especially valuable for other layout21 use cases which endeavor to auto-generate layout from existing technology data - especially from tech-LEF.

---

Likely Implementations

• Lef21's primary "top-level" entity is the LefLibrary, which is essentially the manifestation of the "LEF design library" idea
• Add two more:
  • LefTech (or similar), which includes all of the technology-specification contents (SITE, LAYER, etc.)
  • A union of LefLibrary and LefTech, which I suppose can just be called Lef.

[nanobowers]

Per the lef documentation (http://coriolis.lip6.fr/doc/lefdef/lefdefref/lefdefref.pdf) page 11, there is some overlap of allowed statements between what's in a tech-lef vs. a library-lef, is your idea to have something like this?

Lef
-> overlapping items here (version, busbitchars, via, site, beginext...)
-> Optional<LefTech> (LAYER, NONDEFAULTRULE and other tech-only statements)
-> Optional<LefLibrary> (MACRO and other library-only)

[dan-fritchman]

Wasn't sure honestly!

I think the primary options are
(a) that, or
(b) just having a bunch of overlapping fields (perhaps with some macro-assistance), or
(c) just one big thing called Lef, no explicit LefLibrary vs LefTech

[nanobowers]

Thinking about this a little more, there are two main approaches I can think of:

• Implement parsing for all of the things. For some of the LEF tech features (LAYER, VIA, VIARULE, NONDEFAULTRULE etc) this is no small feat, as the list of things arguably grows/changes over time and likely a lot more than the version to version changes that would be found in a MACRO.
• Implement a somewhat generic parser for the stuff inside the major tech components, e.g. capture the stuff between LAYER layername and END layername as a vec of LefGenericAttributes which is stored in fairly generic fashion. E.g. a struct with a LefKey type and a vec of String that goes up to but does not include the trailing semicolon. Or just a simple vec of Strings.

Skipping over the pros/cons of the first method, the second method has the following pros/cons

• pro: generic enough to not need much maintenance for future version changes or new tech features.
• pro: should be straightforward to read/write nearly all tech lefs
• con: downstream code would need to implement parsing for the elements they care about.
• con: no "safety" enforced at the parser - LefGenericAttributes inside tech constructs that look somewhat like a lef construct but are invalid would not be caught.

A hybrid method is possible/practical: certain tech constructs could be fully parsed/supported and other unsupported/undersupported constructs would be captured as LefGenericAttribute. Maybe this would be be more confusing, unsure.