It's funny how problems parallel themselves, even as technology races forward. During the era of designing using discrete devices, engineers studied device data sheets, timing diagrams, I/O specifications, made throughput calculations, timing analysis, and so on.
These things still happen today, but, instead of learning about discrete chips, we are delving into the internals of IP functional blocks. IP seems to be the TTL data book of today (for those old enough to remember designing that way). IP is on the rise and poised for expansion as engineering teams everywhere come to the same conclusion their predecessors came to. It doesn't pay to reinvent the wheel when the wheel is just one part of the car your designing.
As a result, there is a growing number of companies who's product is IP. They capture their expertise in a descriptive language wrapper, and sell it. It is the logical step in the evolution of functional complexity.
But, engineers are running into the same issues as they did when it was discrete chips they were using. That is the possibility of using a sole source technology. But, instead of the function being sole source, it is now the target devices which house the function, and most likely the IP that are becoming sole sourced.
As a result, there are choices, tradeoffs, benefits, and pitfalls to be aware of when IP is in your design. If the target of your design is an ASIC or FPGA, you can search through the numerous small and medium sized groups who sell and license IP functions in source format compatible with the vendor and tools you plan to use. The other approach is to see what the target device makers offer.
Here is where it gets interesting. Device makers are actively soliciting and adding IP partners, functions and cores to their design resources. These of course, target their parts. If it's a third party IP vendor's function you plan on using, the odds are it is transportable to other target devices.
But, if it is an IP core made and offered exclusively by the device maker, it may not be as readily transported to another chip maker. But, on the plus side, you are dealing with only one company.
There is another benefit to this approach. The cores can be really well optimized for a specific part. This is evident this month with announcements from Actel and Lattice. Actel announced it's optimized CoreDDR controller core, and Lattice its ispLeverCORE IP for DDR SDRAM.
Actel has made the distinction between what they term DirectCore and CompanionCore IP. The DirectCore is their own IP spun to be optimized specifically to take advantage of their architectures. In this case, the CoreDDR controller, which is optimized for Actel's antifuse-based Axcelerator and RTAX-S FPGAs.
This is a nice high-performance, synchronous interface to double data rate (DDR) SDRAM memories. The fully pipelined architecture can be configured at run-time and supports standard SDRAM chips and dual in-line memory modules (DIMMs) with up to 1024 Mbytes of memory (to eight chip selects).
The controller performs all initialization and refresh functions for the SDRAM memories and can be customized based on system and memory-specific requirements. A local bus interface is used for read and write commands. These parts target fast data rates for consumer, communication, industrial and military applications.
The Lattice solution is also pretty good, but with a slightly different spin. The DDR SDRAM core is a general-purpose memory controller that interfaces with industry standard DDR SDRAM. What Lattice has done is add pre-engineered DDR memory interfaces to their FPGAs. These verified hardware blocks on the parts themselves achieve 400Mbps performance. The IP builds on the memory interface hardware and transitions it to your design.
The LatticeECP and LatticeEC FPGA device families, are the recipients of the new cores, and house dedicated DSP elements as well. The validated in-system speeds of 200MHz/400 for DDR is the fastest speed claimed by Lattice who states 'similar IP in competitive low-cost FPGAs is 133MHz/266DDR'.
Key is that these cores are verified and fully supported IP solutions offered by the same company selling you the chips. In contrast, the cherry picking approach of choosing an IP core and device/foundry individually may mean that your design is the first time that IP core has been implemented on that architecture/processor/device.