This is a real selection on a real program. The target was SMIC 40LL. Two commercial DDR controller IP datasheets were compared side by side, one was licensed, and the comparison below is reconstructed from the two datasheets rather than from memory.
DDR controller IP is unusually easy to compare badly, because the datasheets lead with different things. Putting them on the same eight axes is most of the work.
Axis 1 and 2: host ports and bus interface
One controller supported up to 16 application-side host ports; the other up to 32. That is not a marketing number — it determines how many independent masters can issue memory requests before arbitration becomes the bottleneck.
On bus interface, one supported AMBA 4 AXI, AMBA 3 AXI, AMBA 2 AHB and a custom host interface; the other supported AXI and AHB plus its own Host Memory Interface. If your SoC is already committed to one AMBA generation, a controller that needs an adapter is an integration cost and a verification cost you did not plan.
Axis 3 to 5: data rate, burst handling and ECC
The DDR3-class controller supported 800 to 2133 Mbps with a 4:1 data width conversion from host interface to DRAM, and programmable burst length of 4 or 8 including on-the-fly switching. Both supported ECC generation, checking and correction, and configurable data bus widths — one from 8 up to 64 bits plus ECC.
Burst handling looks minor and is not. Whether the controller supports variable burst lengths independent of the programmed DRAM burst length determines how efficiently the fabric can issue short transfers to scattered addresses, and that shows up in real bandwidth long before the theoretical peak does.
Axis 6 and 7: ranks and PHY pairing
One supported up to four external memory ranks; both supported standard UDIMM and RDIMM, one additionally LRDIMM. Rank support matters if the memory subsystem may grow after the controller is fixed.
PHY pairing is where a controller decision becomes a subsystem decision. One vendor's controller integrated with its own PHY into a single-vendor solution, with a PHY utility block automating initialization and production test. Choosing a controller from one vendor and a PHY from another is possible but removes that integration and puts the interface between them in your verification scope.
Axis 8: what actually gets delivered
One datasheet listed core source code, testbench source code, complete documentation, expert technical support and maintenance updates. The licensed package delivered open RTL and schematics, with configuration through a GUI or batch generation tool, and DDR4 protocol verification IP included in the package rather than priced separately.
The verification IP line is easy to overlook and expensive to discover later. A DDR controller without a protocol verification environment means building one, and building one is a project.
The commercial terms
The quote carried a 60-day validity, required GDSII delivery compliant with the foundry's design platform tool kit and tape-out user guide, and set payment within 30 days subject to credit approval. None of those are unusual. What matters is that all three were read before the licence was signed rather than after, because a GDSII compliance requirement is a design-flow obligation as much as a commercial one.
What was actually decided
The licensed package was an enhanced universal DDR memory controller supporting LPDDR4/4X, DDR4 and other DDR memory subsystems, with support for AMBA 4 AXI, AMBA 3 AXI, AMBA 2 AHB or a custom host interface, up to 16 application-side host ports, a DFI interface supporting DDR4/3/2, mDDR and LPDDR4/3/2, and support for industry-standard UDIMMs, RDIMMs and LRDIMMs.
The reason it won was not any single parameter. It was that the DDR4 controller came with a DDR3 PHY already integrated on the target process, and the DDR4 protocol verification IP came in the same package. On a program with a fixed tape-out window, removing two integration risks was worth more than a higher host port count.
Outcome
The controller selected was licensed for the target process with the PHY and the protocol verification IP in the same package, and the configuration the customer needed was supported as specified. The requirement was met.
