Posted by frank schirrmeister on March 23, 2010
Well, after the last post caused some controversy on much assembly re-use enables versus how much one should build from scratch, i did get a question on what the difference between hard and soft re-use is all about. I made sure in a brief huddle with a colleague in our IP team that these are really the only two categories worth mentioning. It all comes down to the abstraction levels and how much automation a designer still uses to implement the IP.
Hard IP has been already targeted to a specific implementation technology – TSMC, Global Foundries etc. Generally this happens for blocks that are already optimized, in the digital world these may be ARM cores for TSMC, in the analog and mixed signal world these can for example be physical interface IP (PHY IP) pre-ported to target technologies. For example, the Synopsys DesignWare USB 2.0 PHY IP has been ported to over 50 processes and configurations ranging from 180nm to 28nm.
Soft IP has not yet been targeted to a specific technology node but is instead available as synthesizable, pre-verified RTL, which the user can target to a technology of their choice using logic synthesis. A good examples is the Synopsys DesignWare IP Solution for AMBA Interconnect, which comes with synthesizable IP for the interconnect fabric, DMA controllers, memory controllers and peripheral IP, along with verification IP to make sure the design works in its context and tools to assemble the IP at the RT-level
So what does this mean in Slartibartfast’s world of designing the San Francisco Bay Area? They key difference between hard and soft and IP is shown in the picture at the left. Soft IP is delivered at the equivalent to the Street-Level in a textual form. Slartibartfast’s designers describe how many houses the customer needs, how they are connected to each other etc. They do not describe the actual layout, i.e. where to place these items. They don’t even describe the actual number of houses, sizes and connections because it all depends on how many people have to use the houses and streets as well as how often they need access. Form this textual description logic synthesis now creates the actual placement of the components, how they are connected etc. Another set of automation tools lays the different components out across the landscape. The final description – the blueprint how to build everything including all walls, electricity, plumbing etc. is then sent to manufacturing.
For hard IP the process is different. Instead of using automation to get from the street level textual description to the actual blueprint on how to layout everything across the landscape, everything is custom made. The Oakland Harbor used in the last Hitchhiker’s post is one example, for which the characteristic of how the water behaves over time, what type of ships arrive etc. cannot really be changed. It’s fixed like the line characteristics for USB PHY’s are and it has to follow certain protocols like USB Controllers have to. While the digital portion typically is synthesizable, the actual interface to the analog world is hard to implement in an automated fashion. For this purpose hard IP (interfacing the water) is an actual implementation at the blueprint level, which can be place and it has been already optimized and verified for the technology chosen to implement the Bay Area.
So why do both exist? Hard IP is not flexible but instead optimized for a specific technology, so it will be at best area, power or performance. In cases like Analog IP it typically is the only option of delivery. Soft IP is offering flexibility – users can choose more options in the area-power-performance target domain. Soft IP is typically configurable with parameters and users can even extend the RTL to add custom functionality. The latter comes at a cost – users have to verify that the additional functionality didn’t break the original design, which is typically pre-verified and comes with verification IP.
Regardless of which type of IP was chosen, IP Reuse in general is crucial to increase design productivity!
Patrick Sheridan is responsible for Synopsys' system-level solution for virtual prototyping. In addition to his responsibilities at Synopsys, from 2005 through 2011 he served as the Executive Director of the Open SystemC Initiative (now part of the Accellera Systems Initiative). Mr. Sheridan has 30 years of experience in the marketing and business development of high technology hardware and software products for Silicon Valley companies.
Malte Doerper is responsible for driving the software oriented virtual prototyping business at Synopsys. Today he is based in Mountain View, California. Malte also spent over 7 years in Tokyo, Japan, where he led the customer facing program management practice for the Synopsys system-level products. Malte has over 12 years’ experiences in all aspects of system-level design ranging from research, engineering, product management and business development. Malte joined Synopsys through the CoWare acquisition, before CoWare he worked as researcher at the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany.
Tom De Schutter
Tom De Schutter is responsible for driving the physical prototyping business at Synopsys. He joined Synopsys through the acquisition of CoWare where he was the product marketing manager for transaction-level models. Tom has over 10 years of experience in system-level design through different marketing and engineering roles. Before joining the marketing team he led the transaction-level modeling team at CoWare.