Posted by frank schirrmeister on July 16, 2008
Some of the fruits of the Project Sydney are finally be available with the official announcement of the not so well hidden behavioral synthesis project Cadence ran for a while. The resulting C2S (C to Silicon Compiler) product has been written about by Richard Goering at SCD Source and Ron Wilson at EDN, a more thoughtful analysis on the “Return of the Prodigal Son”, in this case called ESL, has been published in Grant Martin’s Blog.
Given the various attempts on introducing behavioral synthesis in the past, I am wondering whether I could have used it as a designer when I was still actively developing chips. As pointed out in the above mentioned commentary, behavioral synthesis is today focused on the block level. The last chip development I was involved in – before moving over to the dark side of technical product management – was an integrated Video/audio/transport Decoder. My team was focused on some of the video, audio and transport IP components used in the MB87L2250 – MPEG2 Transport, Video and Audio Decoder with integrated 32-Bit RISC CPU, I include a block diagram here as well. This SoC has at its core blocks for transport, descrambling, video and audio decoding as well as some graphics capabilities. These are connected via a complex memory interface to SDRAM to shuffle data back and forth. In addition one finds less complex peripherals like an I2C interface, an IC card interface and an IR Receiver. For software control the chip has an built in ARC RISC core to run drivers and management software, alternatively the chip can also via an Host Interface to an external SPARCLite CPU.
How would I design and develop this one today? Well, several of the main blocks can be purchased as pre developer IP today. Definitely for the connectivity IP and peripherals like I2C and USB I would go to my favorite IP Provider, buy them and integrate them into the design. The RISC core I can buy from my favorite processor provider. Some of the blocks I will have to develop from scratch. Once I have all the blocks developed then I need to integrate them.
This means, that my “spec to implementation” problem can be partitioned into the two independent paths of implementing the “Chip Topology and Interconnect” and implementing the “Block Functionality”.
Let’s start with the former.
For the chip topology and interconnect this graph shows the different categories of implementation options. At the far end of the spectrum as developer I could code all interconnect by hand. I could keep it complete flexible at the other end of the spectrum, using a completely flexible, programmable switch to which I connect all data producing units. I could use automation for the assembly using SPIRIT IP-XACT based graphical tools, often offering some level of automation in the actual bus assembly itself. Next up, remembering the challenges in designing the memory interface – balancing 15+ streams with different rates and latency requirements – I would definitely consider an automated approach available today from Sonics and Arteris. Between the synthesized interconnect and the fully programmable NoC router I would position mesh-networks like you can find on Intel’s 80core or Tilera’s 64 core chip. They allow flexible packet routing between homogeneously arranged cores.
Bottom line though I am facing at least five fundamentally different implementation choices, some of them more automated than others, some of them offering more flexibility than others.
And it gets worse.
When I look at the implementation of the block functionality itself, I am facing seven categories as indicated in this graph. Starting again with the far ends of the spectrum, one can just bite the bullet and manually implement the block using RTL. Also, for ultimate flexibility one can decide to implement the functionality manually in software. Today, in 2008, I would expect still the majority of all blocks to be implemented that way.
Working my way backwards from full flexibility in software, some of that software implementation can be automated from higher level models. The Mathworks RTW and xUML implementation tools like Rational Rose or Kennedy Carter’s xUML play in this domain. Once you have decided on a processor, there are offerings like CriticalBlue’s Cascade, allowing you to create a custom co-processor based on the performance aspects of your software. You can buy tools to create your own Application Specific Instruction Processors (ASIP) from a functional specification (Target Compiler, CoWare) and then write software for it. As another alternative you can buy ASIPs in an IP play (ARC, Tensilica), again creating the ASIP from a functional specification. Classical behavioral synthesis is the automated version of getting from a high level description to RTL. Players and products in this field today include – in no particular order or ranking – Mentor Catapult, Forte Cynthesizer, BlueSpec, NEC Cyber, Synopsys Synplify DSP, Synfora PICO, CebaTech C2R, Mathworks HDL Coder, ChipVision PowerOpt and now Cadence C2S.
As a user I have to choose from five implementation choices for the topology and interconnect. I also have 7 options to implement the blocks itself. And this is where market fragmentation becomes an issue. Given these options, arranged nicely in 35 permutations, behavioral synthesis is one option in a fairly fragmented “Function to Implementation” market. That to me explains nicely while in overall numbers this market has been pretty small so far. It would be much more significant if we redefine it as the “Function to Implementation” market.
Nevertheless, its importance should not be underestimated in significance as it opens. Some users like STMicroelectronics, reported at DAC this year during a panel that in some divisions for 90% of their newly developed IP blocks behavioral synthesis is used. More importantly it gets us closer to the next abstraction level as a true design entry and has other use models as well, like an automated path of designs into rapid prototyping for instance.
This space is worth watching!
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.