Soft Macro vs Hard Macro in ASIC Design: Differences and Trade-offs

Last updated: 2nd November 2026
Total Views: 22378

A soft macro is a block delivered as synthesizable RTL (or sometimes a generic gate-level netlist) that you synthesize, place and route yourself in your own technology. A hard macro is a block delivered as finished, process-specific layout (GDSII plus abstract views such as LEF and timing models) that you drop into the floorplan as a fixed black box. Soft macros trade predictability for flexibility and portability; hard macros trade flexibility for guaranteed size, timing and, often, silicon-proven behaviour.

In this blog post, we compare and contrast these two types of macro that are commonly used in ASIC design, look at the advantages and disadvantages of each, and discuss how to choose the best one for your design goals.

Key takeaways

Soft macro: RTL, technology independent, configurable, portable, but timing, area and power are only known after you implement it.
Hard macro: layout, tied to one foundry process and metal stack, fixed shape and pins, timing and power characterised in advance.
A third form, the firm macro, is a netlist mapped to a target library: more predictable than RTL, less fixed than layout.
Analog, mixed-signal and very high-speed blocks (PLLs, SerDes PHYs, ADCs) are almost always hard. Processors, controllers and bus fabrics are usually soft.
Neither type is free. Both are normally licensed, and the cost comparison depends on royalties, porting fees and your own integration effort.

What are macros?

Macros are reusable blocks of logic that can be integrated into a larger ASIC design. They can be predefined or custom-made, and they can perform various functions such as arithmetic operations, memory access, encryption and so on. Macros help reduce design complexity, improve performance and lower the cost of an ASIC, because a team does not have to design and verify every block from scratch.

Soft macros and hard macros are both categorised as IP (intellectual property), each optimised for power, area and performance in its own way. When buying IP, an evaluation study is usually made to weigh the advantages and disadvantages of one type of macro over the other, covering points such as hardware compatibility (for example different I/O standards within the design) and compatibility with the reuse methodology the design house follows. The Logical and physical design reuse post covers the wider reuse picture.

What is a soft macro?

A soft macro is a subunit of a chip described at a high level of abstraction, at RTL or generic gate level, and not tied to a specific technology or process. It is synthesized, placed and routed by standard EDA tools along with the rest of the design, which makes it flexible and portable. Soft macros are widely used in SoC implementations and are far more configurable than hard macros: bus widths, FIFO depths, number of channels and optional features are often set by parameters before synthesis.

The disadvantage is that timing, area and power are not predictable until the macro has been implemented in your library and your floorplan. Two teams using the same RTL in different nodes, or even in the same node with different floorplans, can see quite different results. Soft macros also carry greater IP protection risks, because RTL source code is more portable and less easily protected than either a netlist or physical layout data. Vendors respond with encrypted RTL (for example under the IEEE 1735 encryption scheme) and licence terms that restrict use.

Soft macros are editable, and they can contain standard cells, hard macros (an SRAM instance inside a soft controller is common) or other soft macros.

To create a soft macro, you write the RTL for the desired function in a hardware description language such as Verilog, SystemVerilog or VHDL. Once the RTL is written and verified, it is synthesized with standard EDA tools to produce a gate-level netlist for the target library, and that netlist is then placed and routed as part of the chip, or on its own if you want to harden it.

What a soft macro delivery usually contains

RTL source, plain or encrypted, with parameter documentation
Synthesis constraints (SDC) and recommended scripts
A verification environment or test suite, often with coverage results
Integration guide: clocks, resets, CDC notes, interfaces, and lint and CDC waivers

What is a hard macro?

A hard macro is a block delivered as finished physical layout, imported into the physical design database as a GDSII file (often written GDS2). Many hard macros are produced with a full custom design methodology, particularly analog, mixed-signal and memory bit cells, but many others are "hardened" from RTL by the vendor using a standard place and route flow and then frozen. Either way the result is targeted at one specific foundry process and metal stack, and is optimised for power, area or timing in that process. Hard IP from established vendors is often silicon tested, meaning it has been fabricated on a test chip and measured.

Hard macros are defined at a low level of abstraction, layout or transistor level. They have fixed physical dimensions, a fixed pin position for every signal and fixed electrical characteristics, and they arrive pre-designed and pre-verified. They are inserted into an ASIC design as black boxes, giving predictable performance and quality. Unlike soft macros, which allow you to change the RTL, hard macros only give you access to their pins during physical design.

What a hard macro delivery usually contains

View	Used for
GDSII (or OASIS) layout	Final chip assembly and physical verification
LEF abstract	Floorplanning, placement and routing: size, pins, blockages
Liberty (.lib) timing and power models	Synthesis and static timing analysis across corners
Verilog behavioural or netlist model	Simulation and logical connectivity
Parasitic, power and reliability data	IR drop, electromigration and signoff checks
DRC and LVS reports, integration guide	Proof of clean layout and rules for placing the macro (keep-out zones, power hook-up, orientation)

Soft macro, firm macro and hard macro compared

Aspect	Soft macro	Firm macro	Hard macro
Delivered as	RTL	Gate-level netlist for a target library	GDSII layout plus abstracts and models
Technology dependence	Independent	Tied to a cell library	Tied to one process and metal stack
Configurability	High, through parameters and RTL changes	Limited	None beyond options fixed at delivery
Timing, area, power predictability	Low until implemented	Medium	High, characterised in advance
Integration effort	Synthesis, P&R, timing closure, verification in your flow	P&R and timing closure	Floorplanning, power hook-up, pin access and abstract-level checks
IP protection	Hardest to protect	Moderate	Easiest to protect
Typical examples	CPU cores, bus interconnect, DMA, USB and PCIe controllers	Some processor cores and crypto blocks for a named node	SRAM and ROM from memory compilers, PLLs, SerDes PHYs, DDR PHYs, ADCs

Soft macro vs hard macro: pros and cons

Both soft and hard macros have their advantages and disadvantages, depending on the design requirements and constraints. These are the main factors to consider when choosing between them.

Design time

Soft macros take more design time in your project than hard macros, because they need to be synthesized, placed, routed and verified (and timing closed) in each ASIC project that uses them. Hard macros save that time, as they are already designed, implemented and verified by the macro vendor or library provider. The integration of a hard macro is not free, though: floorplanning around a large fixed block, routing to its pins and connecting its power grid all take effort.

Design flexibility

Soft macros offer more flexibility, as they can be customised and optimised for different design parameters and objectives, and can be retargeted to a new process. Hard macros have little flexibility: their function, shape and pins are fixed, and moving to another process or foundry means buying or developing a new version.

Performance

Soft macros may achieve lower performance than hard macros, as results depend on synthesis quality, placement and routing congestion in your design. Hard macros usually perform better and more predictably, because they were optimised for a specific technology and process, often with hand-tuned placement or custom circuits. For a given function they can reach higher speed, lower power and smaller area than the same function built from your standard cells.

Cost

The cost picture is less simple than it first appears. Commercial soft IP is normally licensed too, often with a licence fee plus royalties per unit, so a soft macro is not automatically cheaper. What differs is where the cost falls:

With a soft macro you pay in engineering effort: synthesis, timing closure and verification inside your project, and the risk of missing area or power targets.
With a hard macro you pay the vendor for the implementation and characterisation work, and you may pay again for a port when you move to another node or foundry. In return the block's area and power are known before you commit.

Open-source RTL and in-house blocks are the cases where a soft macro really does avoid a licence fee.

A worked example: choosing for a small SoC

Consider a hypothetical sensor-hub SoC in a mature 28 nm process. The choices below are illustrative of common practice, not a recommendation for any specific product.

Block	Likely choice	Why
Microcontroller core and AHB/APB fabric	Soft	Configurable, easy to close timing at modest clock rates, portable to the next node
On-chip SRAM	Hard (memory compiler output)	Bit cells and sense amplifiers are custom, far denser than flip-flop arrays
PLL and clock generator	Hard	Analog circuit, needs silicon characterisation for jitter
USB 2.0 device	Soft controller plus hard PHY	Protocol logic is digital and portable; the analog transceiver is process specific
12-bit ADC	Hard	Mixed-signal, matching and layout dominate performance

Note the USB row. Interface IP is very often a soft controller paired with a hard PHY, which is the "use a mix" guideline from the next section in practice.

How to choose the best macro type for your ASIC design

There is no single answer to which macro type is better, as it depends on design complexity, performance requirements, budget, time-to-market pressure and how often the design will move between processes. Some general guidelines help:

Use soft macros if you need high design flexibility, configurability or portability across different technologies or processes.
Use hard macros if you need high performance, reliability or predictability, or if the block is analog or mixed-signal.
Use a mix of soft and hard macros to balance flexibility and performance, taking the best features of each, as in the controller plus PHY pattern above.
Before you commit, check that a hard macro exists for your exact process, metal stack and corner set, and that a soft macro has been proven in a node close to yours.

Common mistakes

Assuming a soft macro will meet the vendor's quoted frequency. Quoted numbers come from a particular library, node and flow. Run your own trial synthesis early.
Placing a hard macro late. Large macros shape the floorplan. Leave them until late and you can end up with routing congestion and long wires around them.
Ignoring the metal stack. A hard macro built for one metal stack may block or conflict with routing on another.
Forgetting the views. A hard macro without complete Liberty corners or reliability data can stall signoff.

Frequently asked questions

Is a hard macro the same as hard IP?

In everyday use, yes. Hard IP is the commercial term for a block delivered as layout, and a hard macro is how it appears in the physical design. Soft IP and soft macro are used the same way.

Can a soft macro be turned into a hard macro?

Yes. Implementing a soft macro on its own, closing its timing and freezing the layout is called hardening. Teams do this for blocks that are reused many times in a chip, such as a processor cluster, so that each instance behaves the same.

Is an SRAM a hard macro?

Usually. SRAMs are generated by a memory compiler for a given size and width, and the output is a hard macro with GDSII, LEF and Liberty views.

Which is easier to verify?

A hard macro arrives already verified and characterised, so you mainly verify its integration. A soft macro must be re-verified after synthesis in your flow, including gate-level checks and timing, though its functional testbench usually comes with it.

TDEB Top Bar

TDEB Masthead