I have shared with you the most interesting I have heard during IP-SoC 2010, in two blogs, Part I was about IP market forecast(apparently my optimistic view was quite different from the rather pessimistic vision shared by SC analysts) and Part II, named “System Level Mantra”, was strongly influenced by Cadence clever presentation, but this was before Cadence decided to drop “EDA360”, as least according with Dan Nenni in “CDNS EDA360 is dead”.
Today, it’s time to talk about the future, as the next session of IP-SoC will be held in December in Grenoble, in the French Alps. As usual since 1998, the conference will be Design IP-centric, but the interesting question will be to know where the IP industry stands on the spectrum starting from a single IP function, ending to a complete system. Nobody would allege that we have reached the upper side of the spectrum and claim that you can source complete system from an IP vendor. The death of EDA360 is a clear illustration of this status. Maybe because the SC industry is not ready to source a complete IP system (what would be the added value of the Fabless companies if/when will occur?), most certainly because the IP vendors are far to be able to do it (it will require strong understanding of specific application and market segment, associated technical know-how of such application and, even more difficult to met, adequate funding to support up-front development, accepting the risk to miss the target…). This is why an intermediate step may be to offer IP Subsystem. According with D&R, who organize IP-SoC, the IP market is already here: “Over the year IPs have become Subsystems or Platforms and thus as a natural applicative extension IP-SoC will definitively include a strong Embedded Systems track addressing a continuous technical spectrum from IP to SoC to Embedded System.” So IP-SoC 2011 will be no more IP-centric only, but IP Subsystem centric!
It will be interesting to hear the different definitions of what is exactly an IP Subsystem. If I offer a PCI Express Controller with an AMBA AXI application interface, may I call it a subsystem? I don’t think so too! But should I add another IP function (like for example Snowbush offering PCI Express plus SATA) to call it a subsystem? Or should I consider the application first, and pick –or design- the different functions needed to support this specific application? Then, how to market the CPU, the memories and probably other IP which belongs to my competitor? The answer is far to be trivial, and this will make the next IP-SoC conference worth to attend! You probably should not expect to come back home with a 100% definite answer (if anybody knows the solution, he should start a company a.s.a.p.) but you will have the chance to share the experience of people who have explored different tracks, and learn from them. If you are one of these, then you definitely should submit a paper and share your experience on how to Design or Market IP subsystems! See the “Important dates” below:
• Deadline for submission of paper summary: September 18, 2011
• Notification of acceptance: October 15, 2011
• Final version of the manuscript: November 6, 2011
• Working conference: December 7-8, 2011
If you are not yet involved into IP subsystem but in IP Design/Market, don’t worry, as the “Areas of Interest” list is pretty long:
IP Best practice
• Business models
• IP Exchange, reuse practice and design for reuse
• IP standards & reuse
• Collaborative IP based design
Design
• DFM and process variability in IP design
• IP / SoC physical implementation
• IP design and IP packaging for Integration
• IP and system configurability
• IP platform and Network on Chip
Quality and verification
• IP / SoC verification and prototyping
• IP / SoC quality assurance
Architecture and System
• IP / SOC transaction level modeling
• Multi-processor platforms
• HW/SW integration
• System-level analysis
• System-level virtual prototyping
• NoC-based Architecture
Embedded Software
• Software requirements (timeliness, reactivity)
• Computational Models
• Compilation and code generation
Real-Time and Fault Tolerant Systems
• Real-time or Embedded Computing Platforms
• Real-Time resource management and Scheduling
• Real-time Operating system
• Support for QoS
• Real-time system modeling and analysis
• Energy-aware real-time systems
If you just want to attend, just register here, and send me a note, it will be a pleasure to meet you there!
By Eric Esteve from IPnest
The Need for Low Pupil Fill in EUV Lithography