WP_Term Object
(
    [term_id] => 101
    [name] => Empyrean
    [slug] => empyrean
    [term_group] => 0
    [term_taxonomy_id] => 101
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 20
    [filter] => raw
    [cat_ID] => 101
    [category_count] => 20
    [category_description] => 
    [cat_name] => Empyrean
    [category_nicename] => empyrean
    [category_parent] => 157
)
            
Empyrean Logo SemiWiki
WP_Term Object
(
    [term_id] => 101
    [name] => Empyrean
    [slug] => empyrean
    [term_group] => 0
    [term_taxonomy_id] => 101
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 20
    [filter] => raw
    [cat_ID] => 101
    [category_count] => 20
    [category_description] => 
    [cat_name] => Empyrean
    [category_nicename] => empyrean
    [category_parent] => 157
)

How Good Is Your Library? Are You Sure?

How Good Is Your Library? Are You Sure?
by Paul McLellan on 05-26-2015 at 7:00 am

 

One task that is not very exciting but is critical is that of library quality assurance. Many design groups have created their own procedures, often having been burned in the past, to ensure that the libraries that they use are good. Failure to do so has resulted in:

  • example 1: just before tapeout it was discovered that the layout and the LEF for a cell did not match. It took days to track this down
  • example 2: the timing files did not match the netlist causing post-layout simulation to fail
  • example 3: after weeks of iterating to try and achieve timing closure it was found that there was a constraint error in the library with setup+hold<0

These types of errors are at one level almost trivial, but the consequences can be severe. ICScape have a tool Qualib to address this. As you might guess from its name, Qualib is a library quality inspection tool. It is a comprehensive platform to qualify library/IP with advanced analysis features for better quality. Qualib can be used by design groups as a sort of incoming inspection on 3rd party libraries and IP, and it can also be used by the creators of library and IP to perform an outgoing inspection, ensuring that they are shipping good product.

Qualib performs a number of important checks:

  • Cell Presence Check: based on a cell list ensure that all views of all cells are present and that there are no additional cells or views
  • LEF vs GDS Check: ensure that the reduced cell view in the LEF matches the actual layout: pin name, pin shape, boundary, obstructions (layers should either be pins or obstructed)
  • Timing versus Verilog Check: ensure that the timing in the .lib matches the Verilog: pin name and direction, function, timing arcs

  • LEF Check: make sure that the LEF is consistent: cell properties, pin properties, DRC issues (such as off-grid), routability issues (unreachable pins)
  • GDS Check: label errors, tag errors, DRC errors issues (layout out of boundary etc)
  • Timing Check: ensure timing constraint consistency, setup+hold>0, timing arc presence, power arc presence, condition consistency, timing table monotonicity (if the load doubles the cell should get slower not faster)
  • For transistor level designs there are also equivalent checks that the circuit description language (CDL) matches LEF, timing and verilog

The flow is straightforward, selecting the rules, running the checks and then getting reports in either html or text formats. There is an interactive environment for setting up the checks and examining issues.


The benefits of Qualib are not so much that errors are found that would otherwise be missed. Modern design practice almost guarantees that the problems will eventually come to light. But what is important is to find problems that will be tapeout show-stoppers earlier in the design cycle, with the reduced risk of major panic just before tapeout. By having “known good” libraries early in the design cycle there is a reduced risk of missing the tapeout schedule when errors only get discovered during final verification. This is another example of what has become almost universally known as “shift left”, moving the discovery and fixing of problems earlier in the design cycle so that the design cycle is shortened and issues are discovered when there is still time to fix them without slipping the tapeout.

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.