Date: March 10, 2009

Macro Libraries

• Library must be from the vendor for the die (process-specific)

• Agreement must be in place as to the operating conditions

  • Temperature
  • Power supply
  • Other
    
    
• Max/Max and Min/Min libraries must be available
• Libraries must support the design flow software - provide a list – may need different models for different software – count on that
• Variations to the existing library must be identified early in the design initial phase to ensure timely arrival of desired models
• Vendor cannot guarantee the library performance if the operating conditions are violated
• Vendor cannot guarantee performance if the individual macro specifications are violated
• This include over-driving, over-loading of the macros
• Both the library models and the Place & Route data are required to provide actual physical delay values
• Macro libraries are very complex and each macro contains parametric information as to the ERC and DRC rules checking software.

Macro libraries contain a variety of macros or functional units. They range from the simple SSI: 2-input NAND and NOR gates (or AND and OR gates) to multi-input gates; to MSI-level blocks such as 8x1 multiplexors, 1x8 demux, 8-bit counters, adders and large blocks of memory. I/O can be bidirectional, 3-state or simple buffered I/O. The may/may not contain functionality.

• There are usually different libraries for the I/O macros and the internal core macros.
• Special functional blocks vary with the vendor, or are specifically designed for a customer.
• Memory (RAM, ROM, etc.) are usually in their own library.
• The macros (considered "soft") are more typically Verilog code blocks.
• Paths through a macro usually have differing speeds – even through a 3-input AND gate for example
• There are often several choices for a macro to perform a given function, with varying speed, power, and/or area consumption (macro footprint). There are over 10 different adder designs, not just ripple-carry and carry-look-ahead.

If a 30-yr library were compared to toady's library, the amount of similarity at the functional level would be surprising. The actual model for the macro is much more complex today, when we have so many complex EDA software tools from which to select.

Basic Rule of Thumb:

The designer who understand the library, its model, the characteristics of the different paths thru the macros, and the properties of the macros (such as: which adder takes less room, less power, but is the slowest? Ripple-carry. Which adder suits the current design and its design objectives? well – that depends on the design objectives, doesn’t it?)

Synthesis Tools

The novice designer will simply run the Verilog code through a synthesis tool such as the Synopsys Design Compiler (popular in the 1990s and still with us today), and take what comes out as a reasonable design. This might work. Problem is, it works often enough.

A more demanding design might need a lot of tweaking to achieve desired speed, power or area constraints.

The better (and more efficient) approach is for the designer to "help" the tool by blocking it from considering macros that do not mesh with the stated design objectives. In the case of MSI and up macros, go a step further and pick the macro to be used. (Instantiate it.)

The synthesis tool now can run faster because it will not alter the hand-picked macros, and it will not have to examine the macros marked as do not use. (Design Compiler actually has a command for that. The designer supplies a list of macros that are to be ignored.)

The first pass of the design through the compiler now has a greater chance of success without all that tweaking. (Read tweaking as manpower, compute power, and delay.)

This concept of someone actually understanding the library is not new – it has been around since the first ASIC was created and the first design manual written.

Logic Designers, faced with demanding (often unreasonable) design schedules, who opt to throw things into the maw of the tools, without spending time considering ways to make the tool more efficient, actually end up wasting more time than they usually save.

There is just that one case they have seen where sloppy default design paid off, and they were lulled into thinking that this is the norm.

Nope.

Those who do not study history are bound to repeat it.