The TIPping point

Day 1 was IP day, featuring keynotes, panels and technical sessions. It included much practical advice from one of the most successful IP providers in the business, ARM. In his keynote address, Eric Schorn, VP marketing, ARM processor division commented: "We see a rosy future for the IP sector, with 400 suppliers, 6500 IPs available and a $1.5bn market." From the user perspective, Olivier Haller of ST Microelectronics confirmed that the quality of IP has improved considerably in recent years. In fact, according Haller, ST wouldn't dream of reverifying IP it buys from its selected vendors. However, he emphasised that you need the right technical information to integrate it efficiently, and verification at SoC level is important. According to Joachim Kunkel of Synopsys' IP division, there has been a shake out in the IP market. "Quality is a function of how much you spend on it," explaining that as broad-based IP vendor it can amortise the cost of quality across an extensive portfolio and customer base. "The vendors of poor quality IP have disappeared, largely along with their customers," he remarked. IP providers, users and tool vendors all agreed that it is potentially dangerous to tinker with third party IP. "Some users are better qualified than others to delve into the complexity of IP," commented Andrea Fortunato of Numetrics. The IP theme was extended to cover fabless ic vendors. A panel concluded that the largest fabless companies will probably survive as they are, mid-size companies will have to change their business model to stay profitable, and the smaller firms are "consolidation fodder". There is a view that the fabless business will split: companies that design, and companies that deliver. The rationale being that both functions represent too much investment for a single enterprise to do well. Model approach It was immediately apparent on Day 2, that the critical SoC issues are impossible to divorce from those of embedded systems design. ARM's Michael Dimelow underlined the increasing complexity of SoCs made possible through new process nodes. As a result more IP can be integrated into SoCs and the IP has become more complex. An embedded microcontroller core has become a multicore cpu cluster. Peripherals have become multimedia rich. There are distributed memory subsystems to manage, and three or more interconnect networks. Interconnects in particular can cause a problem, he said, due to poor latency. Increased multimedia functionality is the root cause, with massively increased data flow and scarce bandwidth, exacerbating the issue. Dimelow launched a 'call to action' to bring together the SoC and embedded software development tasks. He suggested that higher quality embedded software is required faster as this can provide the visibility to check out the hardware. Dimelow highlighted the need for tools to optimise designs, to better exploit multicore cpus, cope with memory latency, and, in the near future to provide real time performance profiling and support for cache coherent designs. Observations from Synopsys' Kunkel were that software development costs are coming to dominate SoC design and causing delays in delivery. A common modelling platform is one solution, supporting transaction level modelling, behavioural level modelling, cycle accurate System C models, virtual platforms as well as fpga and silicon prototypes, as necessary. Whether SoCs or multi-chip embedded systems, the challenges appear to be similar. The solutions, too, follow a theme of high level design strategies and a model-driven environment. Bernard Candaele, Deputy Director at Thales presented the Day 3 keynote, highlighting the challenges in the 'real world' of embedded systems. At the root of the solution, his company has determined, is a model-driven design environment, with models to express hardware parallelism in order to fully exploit multicore hardware. ARM's Top Tips for IP providers • Don't try to do everything. Automate whenever possible. Subcontract or partner where possible, even with competitors if necessary - trust-based relationships are important. • Work with the ecosystem. Understand the value chain. Find out how your success will help others. Look for the win-win. Build links (ie between products or between tools). Connect people: exploit the 'network effect'. • Understand your customer's customer. Understand their attitude to risk: are they visionary early adopters? Their success will reflect on you, but they may be reckless. Pragmatic customers may be risk-averse. • Help others get to where they are going. Seed what you have to, charge where you can. Be seen as a leader. Ensure your place in the ecosystem is evident. • Look to the future – don't just expect tomorrow to look after itself. Winners have a road map. Invest in the future – don't be a one trick wonder. Practical advice for IP users • Make sure you get access to the knowledge and technical data to integrate it efficiently. Check that the right models and other verification data and tools are available, either from the vendor or through the ecosystem. • Don't even think about modifying 3rd party IP. The impact on project schedules of modifying IP is often badly underestimated. The benefits of reuse (productivity gains, easier verification, lowerr cost, faster time to market) may well be negated. • But the temptation to tinker is strong, and may be necessary, especially for previously used IP, to gain a competitive edge. It is important to get the right alchemy between silicon-proven IP that can be easily re-used unchanged, and, differentiated or tweaked IP that may need more qualification and verification effort. Be prepared to take responsibility if you change things. • Formal verification tools can be useful in some tasks, such as checking for protocol compliance, but are not necessary on many standards-based IP blocks. Embedded systems challenges • Software productivity gap, particularly for functions such as software radio, where each waveform might require 75k lines of code. • Multicore: it may solve thermal and performance problems, but programming principles need to exploit parallelism within the model-driven development environment. • Legacy software needs to be supported within a stable ecosystem, and may need to be re-synchronised to new hardware. • Will need to deal with less reliable components due to process variability and greater susceptibility to soft errors.