Posted by frank schirrmeister on December 15, 2010
It’s Christmas time. My yearly cookie baking event has been canceled this year due to a broken oven and delays in my house remodeling project. Thinking of recipes, it turns out that one of the missing items preventing adoption of system-level design is the absence of a canonical system-level flow, a pre-defined recipe how to get from an idea to hardware and software implementation. We are getting closer, but every customer I talk to has their own different system-level flow, which prevents scalability. As an added bonus for reading I will publish my favorite Christmas Cookie Recipe at the end of the post.
Flows are an interesting thing. From RTL to Implementation we now have arrived at a state that there are canonical flows. They can be automated. Users are automating them and they are generic enough that EDA companies help to automate them too, like in the case of the Lynx Design System. Are we there yet for system-level design? Not quite. Do we know the ingredients and part of the recipe? Absolutely!
Here is a simple flow diagram to go from “Idea” to “Product”. The first step is to figure out the architecture and the partitioning of hardware and software. As indicated in my previous post on Application Driven Design, in some application segments like wireless (iPads, iPhones, Droids etc.) software is king and the hardware is largely designed to optimize its execution. Still, defining a properly partitioned isn’t trivial. Ingredients for success are trace based analysis and models of the “system-to-be” which are independent from implementation. As an output of this phase we get specifications for hardware, software and their integration. These specifications can be executable, i.e. for the blocks this may be C code or graphical representations as used in model based design.
The hardware design phase is pretty well understood, especially once we have RTL. It’s lynxable so to speak. From the hardware specification the flow is all about blocks. There are various ways to get them, the two main categories are to reuse them or to implement them as differentiated blocks. That can be done by hand, as configurable processor, as custom coprocessor or via high-level synthesis. All these techniques have different advantages, but it is hard to completely automate the block creation flow. There is no pre-defined recipe.
Then the hardware and the software have to be integrated. First, the various hardware blocks need to be integrated. At the transaction level the integration can be used to create virtual prototypes to enable first interaction with the software. Once RTL is available, hardware based prototypes – FPGA based or Emulation – can be used, again enabling software execution. As part of the architecture exploration phase the interdependence of the block hopefully has been analyzed. The RTL can now be integrated and assembled, and finally be fed into the “lynxable” hardware implementation flow.
Now that I have written this it does not sound all that bad. However, only the ingredients are pretty clear, users will need “Block Design” with high-level synthesis and processor design, “Block Reuse” based on IP libraries, “Architecture Design” at the transaction-level and “Prototyping” using virtual and FPGA prototypes. The recipe though, i.e. how they connect and how they are assembled within a flow, highly depends on application domains and individual customers.
When will we get there? There is hope. First incarnations of ESL flows are emerging, like the TSMC ESL Reference Flow. Once the ESL flows get to a state that we can create something like a Lynx Design System for them, we will know that we have passed this hurdle for adoption!
A recipe that always works: Nutty Christmas Cookies
And now to my favorite Christmas Cookie. Every year since my daughter has been two years old, the “Annual Schirrmeister Christmas Baking” takes place on the fourth Sunday before Christmas, in Germany we call it “1st Advent”. This year it has been canceled due to a broken oven, but just imagine 10+ kids unleashed on hand-prepared cookie dough. While the kids are more into shapes and sprinkles, the following cookie has become the universal favorite amongst friends and family. Enjoy!
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.