Archive for the 'High Level Synthesis' Category

Before March Madness and the Final Four Butler win become too much of a distant memory, I wanted to briefly write about a different kind of “Final Four”, the four challenges which KH Kim, Executive Vice President, Samsung Electronics, Co., Ltd., presented at day three of the recent Synopsys Users Group (SNUG). The audience was in for a treat, the presentation was great in structure, content and delivery!

First, KH Kim was setting up the challenges using great examples from his ASIC view of the world. Worldwide consumer electronics sales was growing by 13% in 2010 and projected 10% in 2011 driven by smart phones, TVs and PCs, Apps are a major trend for all devices in video, gaming and business. The mobile Internet together with “apps everywhere” is accelerating smartphone adoption, which in exchange becomes the connective hub with other devices & services. TVs are becoming the hub for home entertainment, integrating gaming, internet, and video services. An finally, ubiquitous connectivity and consumers’ demand for 24×7 connectivity leads to a cloud and web-centric world. All this led to the set of graphs shown in the first picture I took here, summarizing the implications for SoC Design. Processing – the combination of CPU performance and GPU performance – Samsung sees growing by a factor of 50 from 2010 to 2012, while bandwidth requirements, the combination of memory and network bandwidth is growing by a factor of 250!

From this daunting prediction, KH Kim went on to articulate the “Final Four” Challenges in SoC Design:

• High Performance with Low Power
• Given challenges to CPU Performance and GPU Performance, SoCs can only be kept within Low Power budgets using Multicore CPUs (of course only shifting the challenges into programming), Multicore GPUs, low power design taking into account application scenarios and HPMG processes enabling transistor scaling.
• High Bandwidth
• The bandwidth challenges on memories and networks can be addressed by increasing 4G network bandwidth, the switch to serial interfaces to avoid signal skew and cross talk and Through Silicon Via (TSV) increasing electrical performance and overall memory bandwidth
• Design Complexity
• According to Samsung new features & functions have increased the IP count by more than 22x from 90nm to 28nm, gate counts have increased by more than 16x, while the chip size only doubled. As solution, process migration becomes a must to deal with the increase of chip sizes and 3D ICs with TSV seem unavoidable.
• Short Turnaround Time (TAT)
• Well, the rate of growth in design productivity is still much lower than Moore’s law resulting in increasing design times, while product life-cycles are shortening over time, which demands fast design TAT. The only way to deal with that are the use of IP,which Samsung sees evolving into sub-systems of discrete IP blocks connected through busses doing computation and communication. Software is overtaking the hardware effort and the trend toward multi-core designs further complicates software development & debug. Samsung sees Platform Based Design as a key requirement, for which virtual prototyping has emerged to enable early (pre-silicon) software development. Finally, Samsung sees ESL (Electronic System Level) design being at the early stage of adoption to close the design productivity gap!

As a system-level guy I am of course very much excited about Samsung adopting and pointing out system-level design as key solution to the fourth challenge.

High degrees of automation in architecture design, high-level synthesis, transaction-level modeling and virtual prototyping become key for faster TAT, higher Quality of Results (QoR) and earlier software development.

The photo I took of the appropriate slide is shown on the left … and the arrow used here  is very akin to the graph I used in the first blog post I ever wrote. System-level design has reached the foundries! It is not alone, but recognized as one of the key solutions to the four main challenges.

The road was long … but we are getting there!

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!

Ingredients:

• 375 g ground hazelnut (Trader Joe’s has a good selection)
• 125 g ground almonds (Trader Joe’s has a good selection)
• 500 g powdered sugar
• 2 eggs
• 1 egg yolk
• 1 pinch of salt
• 1 tablespoon sale
• 1 tablespoon flower
• 1/2 lemon, juiced
• 1 tablespoon water
• 1 pack of Dr. Oetker Vanilla Sugar (carried at Cost Plus, don’t ask, it’s a German thing …). This may be replaced by a couple of drops of vanilla concentrate but I have never tried that.

Recipe:

• Mix ingredients in a big bowl using a mixer, the hook works best. At the end it is best to finish the dough off with your hands to mix it completely. The dough needs to be evenly mixed, use flower as appropriate while kneading.
• Roll out or flatten the dough finger-thick and cut it into long 1in wide stripes and cut into 1in x 1in squares or 1in x 1.5in rectangles.
• Pinch crosses with the back of a knife into the top of the cookie.
• Distribute the pieces on cooking sheets and bake in pre-heated oven at 200 C / 392 F for 15 minutes. Keep distance! They should remain at light color.
• Cookies have to be taken off fast and while they are warm a mixture of vanilla-sugar and lemon needs to be applied using a brush immediately. For the lemon mixture use100g of powdered sugar and mix it with 1 pack of Dr. Oetker Vanilla Sugar, the lemon juice and a tablespoon of water. Mix it in a way that it can be applied using a brush.
• The cookies should be kept in air-tight boxes so that they do not dry out and stay moist. In order to keep their moistness, an wedge of apple in paper can be put into the box with the cookies. But no worries, they won’t last long anyway …

Happy Holidays!

With the year coming to an end faster than I really can comprehend (have you started on your Christmas wish list yet?), I am looking back to what I said would be important going into 2010.  In my Electronic Design column’s forecast “2010 Will Change The Balance In Verification” i suggested that software development would change how verification is done. Well, looking back I can confirm that this is happening, albeit not only the way I had suggested.

I have previously quoted Janick Bergeron, my fellow blogging colleague on verification, that the “solution to the verification problem lies in the design process”. 2010 validates for me that this is really becoming a reality. Simply put, design is changing and one of the main reasons is verification. To enable successful chip and system design while also enabling the different participants in the design chain from IP providers through semiconductor vendors, Integrators to OEM, three components are required. Developers need to be enabled to

• re-use as many blocks for chip design as possible and have tools to create new, differentiating blocks as fast as possible
• assess whether the integration of blocks  (new and re-used) will work correctly when integrated
• prototype the “chip to be” for early software development, hardware-software integration and verification

The last item is successfully addressed today by virtual platforms and FPGA prototypes, depending at which point of the design flow the project team or their customers decides to require enablement for software developers and verification. The integration aspect is addressed by IP-XACT based tools at the RT-Level (for RTL assembly) and architecture design tools at the transaction-level (to understand bus bandwidth, impact of software mappings into multiple processors etc.). To efficiently enable blocks we have a striving Implementation IP licensing market and various tool options for high-level block design and synthesis, which brings me back to the topic of verification.

The main reason for high-level design of blocks is not a faster path to implementation, better coding efficiency or re-use and connections to system-level models. The main reason for high-level design of blocks is verification!

I have used the picture on the left in a previous post on high-level synthesis already. It shows the various options a user has to implement a block once the idea for a the block is born. The options range from dedicated hardware implementation – read “inflexible” – to full software implementation – ready “flexible”. There are various grades of flexibility in-between.

Especially in consumer applications flexibility has become a key issue today. In order to meet changing standards and to be able to support different versions of algorithms with the the same intent (like en- and de-coding video or audio), mixed hardware/software implementations are very attractive. Two of the implementation options have profound impact on verification and a re worth to be singled out as verification actually seems to be the most important driver for their adoption:

• High-Level Synthesis (HLS) for fixed hardware blocks is on a path to real adoption, especially for data-path oriented designs, but also for control. Besides the advantage of getting to the actual implementation faster, verification also changes and makes HLS attractive. The basic idea is that more verification can be done at higher-levels of abstraction, i.e. TLM, and then the implementation path is automated. This is the same reason why the industry switched for digital design from gate-level design to RT-level design quite some time ago. In my first project I entered the blocks of an FFT chip at the gate-level, but already verified them in RTL. If logic synthesis would have existed the way it does today, I would have not even touched the gate-level.
• High-Level Synthesis for custom processors has emerged as an attractive option to get from idea to implementation. Flexibility of the implementation is key here. In contrast to a fixed hardware block and its high-level synthesis, the main functionality runs in software on a custom processor, which is automatically synthesized from a high-level architecture description language. This is a great approach to address the implementation of standards which have not been finalized yet as well as implementation of algorithms which are similar in nature (like different video standards). It turns out that verification is an even bigger motivator to adopt this approach because it eliminates the fundamental shortcoming of having to verify hardware blocks: Prior to taping out the design for ASIC implementation, the design’s functionality has to be verified in full using hardware oriented test-benches, which include for a video algorithm for example all variations of bit-rates, frame sizes etc. Custom processors, or Application Specific Instruction Processors (ASIPs) offer a very unique, fundamentally different alternative for verification. Given that the actual functionality – which drives the majority of the verification effort – is actually not implemented in hardware but has moved into software, now the correctness of the custom processor hardware itself can be verified independent of the function it executes. As a result of this separation of structural and functional verification, they also can be separated in time. Specifically, once the actual correctness of the custom processor execution is verified, the implementation can proceed and functional verification can be done fully in parallel using software.

Well, all this happened faster in 2010 as I had expected and is really driven by verification. To close this post and to come back to my original 2010 prediction on verification, I was correct in principle with my prediction. We have more customers using embedded software and directed tests written software for verification of hardware blocks. It is now the second most adopted use model for virtual prototypes (besides early software development). The adoption of high-level design for blocks – custom processors and fixed hardware alike – is further changing the verification dynamic, especially for block verification.

It will be interesting to see how this will play out in 2011. Interesting times!

By Johannes Stahl

When Carver Mead and Lynn Conway published their famous statement about the ‘tall thin engineer’ in their book "Introduction to VLSI System Design" in the early 80ies, designs had about 5,000 gates. Their vision was to change VLSI design into a process, that was repeatable and also that designers could understand the entire process well enough to create chips starting with the knowledge of the design intent down to the final mask set. If we look into the reality 30 years later, the opposite has become true. The SoC design process has been decomposed into a number of major categories: System-level design, Software development, RTL design, RTL2GDSII, Design for Manufacturing with vastly different knowledge disciplines.

In this View From The Top we of course do not look down to DFM, so we are definitely not the prototype of that tall thin engineer. At best we can see that our end point from a hardware implementation perspective is RTL for implementation and some reference model or test vectors, we provide to the RTL designers.

So how should system-level tools support hardware implementation flows? First of all the role of system-level tools is to make sure that the design intent is completely specified and is validated in the system context. Second the tools should facilitate an easy way of getting to RTL.

How do system-level engineers know, if their specification of design intent is complete? The best way for them is to express their specification in a way that is intuitive, allow for reuse of their knowledge and manages complexity through encapsulation. This is the essence of model-based design. In the domain of communication systems design any algorithm designer today will start with a conceptual block diagram and for simulation use C-models to explore the overall system performance. Block diagram based tools with a large amount of proven models, such as SPW and System Studio, are the default way for design teams today.

Once designers have captured their system using this model-based approach, the complete power of the high-performance simulation tools for performance exploration, specifically going to the required fixed-point precision is at their disposal. At a minimum this model-based fixed-point specification is a reliable, easy to understand meet-in-the-middle reference for RTL designers and algorithm designers. However with the proven Synopsys tools for implementation, algorithm designers can take it one step further: They can either rely on proven DSP implementation building blocks, built-in C to RTL translation technology or high-level model-based synthesis using Synopsys’ Synphony to automatically create RTL which can go straight into RTL2GDSII flows. Hundreds of thousands gates blocks are being designed every day with these flows, retargeting from FPGA to SoC included.

The basic questions of how much implementation expertise and algorithm design engineer needs and how much domain expertise an RTL designer needs does not have a fixed answer. Design teams will always need to stretch to bridge the gap. Synopsys can help to make the stretch easier!

Being challenged to a duel (see the last paragraph here) can be scary. It often helps to re-visit what one is dueling about. The discussion in question here is about the role of IP reuse vs. high-level synthesis. And as is most life situations the truth probably lies somewhere in the middle, and for sure not in the extreme position

What happened? In my last post I likened the Oakland harbor to a USB interface. Thomas Bollaert commented in his Blog entry title ‘The “S” in ASIC’ on the role of IP reuse and that ‘IP has an important role to play, but not an exclusive one’. Hey, I fully agree. How let’s look at where we are on the scale between IP reuse and creation of new IP.  I would at least want to augment the comment ‘it will be quite some time before chips are an assemblage of IP blocks’ with the notion that large chunks of design are already today. The graph on the left shows IP reuse data from Semico Research. The average number of IP blocks per chip is already around 50 and set to grow to more than 70 over the next couple of years. Together with data that more than 50% of a chip is reused today already (a number which is set to grow to at least 60% over the next couple of years), there is already a large amount of IP assembly going on today..

So what are these IP blocks? Well, processors like ARM, Atom, MIPS, PowerPC etc. for one. These blocks are designed to be a scalable business – i.e. being sold multiple times. The analogy of the Oakland harbor was meant to indicate other blocks which are a scalable business – connectivity blocks for defined interfaces like USB, SATA, DDR etc. Given that these follow defined standards, the main decision is whether to have them available or not. A custom implementation will in most cases not be differentiating for a chip vendor. As a result they will tend to reuse IP for those and focus their differentiation on some of the custom blocks Thomas describes (like video or audio) as well as on the software provided on the processor.

So with assembly of IP blocks being a given, where does high-level synthesis fit in? Well, it certainly does for new blocks. Even if IP-reuse grows to 60% or 70% as predicted, those remaining 30% are still a big chunk of work. That’s where high-level synthesis fits in with two effects. First, it accelerates the time to implementation. In addition it increases verification efficiency by enabling transaction-level verification combined with a repeatable, automated flow to implementation.

How far one takes this depends on perspective. Some vendors definitely take it a bit too far in questioning IP reuse at the RT-level as “high effort, error prone work” and “restricting architectural flexibility”. Pushing TLM models as the only golden source from which one synthesizes takes it too far. High-level synthesis from the transaction-level needs to be seen in conjunction with IP reuse of larger blocks like USB, SATA, DDR etc. Just like in the transition from gates to RTL, I doubt that high-level synthesis will eradicate reuse of smaller blocks. It will augment it and perhaps even use it by using the smaller blocks of IP to map to.

As always, the truth to me lies somewhere between the extreme positions.

Some of the recent coverage on our recent high-level synthesis (HLS) announcement is missing an important aspect. Fundamentally the discussion on entry languages is misleading. HLS is not about languages. Sorry, no war here. It is about the amount of information explicitly defined compared the amount of information left open and guided by constraints. While there is no language which does it all, pretty much all languages can express multiple levels of detail.

For example, Bryon Moyer over at TechFocus Media provided an interesting perspective giving the different languages personalities in his article “Living With Ambiguity: The Other HLS”. Bryon makes good points but the different personalities are in my mind really not competing, they are mostly complementing each other but also have some overlap.

Let’s try an analogy. How has your boss been treating you lately? Bosses fall into different categories, as we all know. Some bosses tell you “get this partnership done” and then leave all the details up to you. They may set constraints together with you regarding what the main objectives for the partnership should be, but you have freedom to go about it and implement it as you see fit. At the other end of the spectrum you find bosses who are with you every step of the way. They participate in decisions on detailed tactics. The key difference lies in the amount of freedom to “make things up”, or to “pull things out of thin air” given the basic constraints set by the objectives.

Well, in HLS we face exactly the same situation. In the press pitch we used the picture on the left to explain the relationship between the different levels to express detail. A flaw in the description is that we used languages. We really meant abstraction levels. While the 3 lines of M code just define a function, the 20 lines of C code are much more precise about which types to use. The 200 lines of RTL code are very specific, down to the bit. All the loops are unrolled and specific resource usage is defined.

If you allow a tool to “make more things up”, i.e. create more of your implementation automatically based on constraints, ultimately you will gain key benefits. Not only will it will be simpler and easier to create a working algorithm, you will also work on significantly smaller code and you will likely introduce less bugs into the flow. Everything comes at a price though. You have less actual influence on how loops get unrolled and which specific resources are used etc. You give up that freedom in exchange for the benefits mentioned above.

When it comes to languages, they really do not directly compete too much. Starting with M you define the algorithm and you set constraints on frequency, power and area and then you let the tool do the rest. Similar things can be done in C. We have seen that with  a couple of hundred lines of C code you can easily implement FFTs and IDCTs from C as well with little overhead. However, if you need more specific control, i.e. want to be a more influential “boss to your tool”, then you have to add specific information to your C or SystemC code to specify how to unroll loops and which resources to use. You are essentially doing hardware design in C. From a language perspective you can express a lot of this level of detail and detailed constrains in other languages as well – SystemVerilog for example.

In closing, let’s see which implementation choice my daughter will choose now that I told her to clean up her room. She can put everything way properly, could pile it and hide it in drawers or even just push everything into the “papa-taboo” area under her bunk bed. Let me get over there and be more specific with my constraints …

We all make these decisions on a daily basis. For me it is about the morning coffee. Do I prepare it at home, get it as early as possible, or do I wait until I am passing the coffee shop on my way to work, a path I have to take anyway.

For model usage we are facing a similar issues. When looking at a standard design flow, it is a fairly straightforward decision to take RTL – something which will be created in a path of a project anyway – and use it to create with fairly predictable overhead a software development environment, may it be an FPGA prototype, an emulator or software based hardware/software co-verification. In contrast, the C models needed for virtual platforms – for example to feed into our Innovator based virtual platforms – are not part of most “normal project flows”, which today still start with written specifications and then lead into RTL.

Today we introduced the Synphony High-Level Synthesis solution, which takes M language input – often used interactively for algorithm analysis – and creates RTL from it. Together with M, Synphony HLS accepts model-based design entry. Examples for model-based design entry here are The Mathworks Simulink and of course our Synopsys System Studio.

When looking at M at first I myself was quite confused, as it is often used interactively for algorithm analysis. However, by itself there is really not much simulation there. However, we used the opportunity of our LTE Whitepaper about next generation wireless systems to query users on which tools they use for algorithm design entry. Interesting enough, as the graph above shows, out of more than 500 respondents, 32% pointed to M, 29% pointed to C based entry  and 22% to model-based design entry, with our Synopsys System Studio fairing very well as number two used tool (32%).

M is really the next level up above C based technologies – and therefore Synphony HLS is really complementing C based synthesis technologies. Looping back to my coffee analogy earlier, one key item I am excited about is the Synphony High-Level Synthesis capability to provide on the way to implementation models which can be used for virtual platforms and verification. In an example we are showing to customers, 3 lines of M translate to 20 lines of C-code and 200 lines of RTL. As a result, creating C models as natural byproduct of this flow, will be yet another source of models for virtual platforms, in this case covering the communications and multimedia application domains.

Just as the Design Automation Conference in San Francisco comes to a close some cynics are pointing out that once again this was the DAC of ESL and we probably can look forward to another one like that next year in Anaheim . This feels like the proverbial road trip during which you hear from the back seat every five minutes “Are we there yet?”. There certainly were interesting panels and events at DAC, like the System Prototyping panel yesterday, for which Rick Nelson wrote a good write up here.

Personally I attended the 7th Annual ESL Symposium Luncheon sponsored by Mentor Graphics and moderated by Wally Rhines. The panelists included Nitin Chawla from ST, Joachim Kunkel from Synopsys, David Black from ExtremeEDA and Wolfgang Rosenstiehl from the University of Tuebingen and Alan Su from GUC.

As always Wally had lots of data. While he likened ESL at the beginning to technologies which took 30 years to adopt, he then showed graphics like the one on the left  confirming actual market growth. He called ESL one of two technologies leading growth in EDA. According to Mentor’s surveys, ESL adoption is driven by design complexity, verification challenges, design challenges to meet power and performance requirements and time to market demands.  When it came to the panelists, Joachim Kunkel and Alan Su focused in their introductions on system prototyping while the other panelists were more focused on high-level synthesis.

At one point the panelists had gone down the route of ESL synthesis so far that Daniel Gajski stood up and asked the panel whether ESL is only high level synthesis or whether there is more to it. The panelists attempted answers, mixing in verification, but in my mind one key question was left unanswered: Where does a block and where does a system start? What is the “S” in ESL?

Unfortunately the discussion seemed at times to miss the separation of block development and block integration. High-level synthesis is today well applicable for block development. However, with block re-use in hardware reaching 70% and 80% levels, the other challenge in the design process has become the integration of blocks, re-used or newly created. Several questions later-on confirmed this lack of clarity as the question “how far away are we from synthesizing complete chips” came up in several variations.

Overall, however, I am glad that according to the data ESL is growing and has not been voted of the EDA island … Off to the next round and let’s hope that we are progressing even further until we meet in Anaheim next year.

Synopsys announced last Monday a breakthrough in verification, system validation and embedded software development technology. There was good coverage, for example in Ron Wilson’s and John Blyler’s blogs. One main question we got from users and the press was about how this all works together with the virtual platforms we provide as part of our Innovator environment.  John Blyler asked it flat out “One other question: How will this hardware prototyping platform eventually work with Synpopsys software (virtual) prototyping tool – from the Virtio acquisition?”

We have demonstrated interfaces to hardware based solutions for a while with Eve and Palladium. Synopsys now has the three necessary technology components for hybrid prototypes in house and are preparing for demonstrations with various customers. Starting on the hardware side, physical interfaces must be provided to connect the actual hardware prototype to the workstation running the simulation. PCI Express is a common solution here. Second, data must be transported using an agreed upon protocol between the software and hardware worlds. SCE-MI has become a standard in this domain. Finally, for conversion from the transaction-level model to the transport interface, transactors are necessary to translate high-level protocols like AXI, OCP and AMBA.

In addition we have talked to about 25 customers worldwide (yeah, I made it to be United 1K for the tenth year now) to understand their needs. We were able to condense the use models of virtual platforms and FPGA prototypes to five main use models:

• RTL Reuse and Architecture Verification: Given the high IP re-use rates in today’s design, RTL may exist from previous projects or may be acquired. While more and more IP users request high-level models as part of an IP purchase, it may not always be available. Hybrids of virtual platform and FPGA prototype allow a virtual platform to re-use existing RTL and avoid modeling effort of potentially complex IP blocks. Given that FPGA prototype execution is essentially cycle accurate, it also increases overall fidelity and allows to swap out the virtual model with RTL to verify that architecture decisions were correct.
• Accelerated Software Execution: Due to FPGA implementation optimization for algorithm execution and not processor implementation, software typically runs on workstations and virtual processor models faster than in FPGA prototypes. Hybrids of virtual platform and FPGA prototype with processor models on the workstation allow overall faster execution while maintaining accuracy of accelerators and peripherals.
• Virtual Platform as test bench for FPGA prototype: Given that verification often starts at the pre-RTL level for validation purposes, system-level development efforts can be re-used for the actual RTL verification. Hybrids of virtual platform and FPGA prototype with the virtual platform acting as testbench avoid duplicate efforts and enhances model re-use
• Joint system environment connections: For popular interfaces like USB and SATA virtual platforms already provide real-world and virtual I/O interfaces, for example connecting to physical USB devices. In addition a daughter cards in FPGA prototypes provide real world I/O with interfaces to real life streams like the wireless physical interfaces. Hybrids of virtual platform and FPGA prototype with real world I/O on both sides allow real world stimulus to be used where most appropriate.
• Virtual platform “Virtual ICE” connected to FPGA prototype: Re-use of the virtual development environment running in a virtual platform including for example disks, USB virtualization, visualization etc. allows better access to FPGA prototypes and decreases set-up time. Hybrids of virtual platform and FPGA prototype with the virtual platform executing the development environment avoid additional development efforts, allow the FPGA prototype to be kept remote and increase familiarity for software developers who often prefer to just see a keyboard and screen

Over the next couple of weeks and month we will be demonstrating this flow using Innovator virtual platforms connected to the ChipIT FPGA prototypes using the SCE-MI 2.0 interface.

If you are interested in more information or a demo please don’t hesitate to contact me directly or contact the system-level design team directly.

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 porgrammable 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 rouiting 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.

Bottom line:

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!