Archive for October, 2009

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 …

There is a lot of conversation these days about the impact of Electronic System Virtualization (ESV) on software development. Isn’t it obvious, that it is much better to develop software earlier, before chips are available? Don’t you agree that looking into the guts a multi-core platform for debugging a tough multi-threading problem is much easier using a Virtual Platform, than to use a board with a JTAG connected debugger? Wouldn’t it be nice if the semiconductor and OEM supply chain use this as their standard way of accelerating their time to market? Isn’t this the only problem that ESV addresses?

Actually this only one problem, albeit a big one, that ESV addresses. It deals typically with the next generation silicon and product, which in most companies is called N+1.

What about the products, that are further out, say N+3? Do you have the software applications that will run on those products in your hand today? No, they will be invented in the next few years. Do you even know the processors that you will be using for N+3? Maybe, but there are no models for those yet. What you do know today is the type of applications that you need to run. You may know the performance profile in terms of traffic that they trigger. You probably know exactly, which interconnect and protocol you will be using, because the interconnect, the backbone of your chip, is typically stable for many generations of platforms that you are developing or will be using.

Getting a precise idea, what your interconnect will deliver for the myriad of use cases and applications, that you need to support, is critical for making your design decision for N+3. The right ‘connection’ with the right bandwidth and priority management between your processors and the internal/external memory systems determines, if your N+3 chip or end product is competitive or not.

If you are a development engineer at an OEM or semiconductor company, this is what you care about.

However, it is even more critical that your company cares about a ‘connection’ at a business level. If you are the SmartPhone OEM trying to stay ahead of the pack or beating #1, you need to specify the most advanced silicon platform that will deliver on that goal. If you are a semiconductor company, that has a socket in N+1, you want to maintain that socket for N+3 or push your competitor out of it.

If you are the OEM, how do you communicate to your bidders, what they need to deliver? If you are the semiconductor supplier, how do you credibly pitch, what you can do vs. your competitor? The risks for miscommunication and missing the performance are high. What if you had an ESV solution, that serves as the specification that you can rely on for N+3? Do you want to have a ‘connection’ between you as an OEM and you as a semi based on industry leading interconnect IP, protocols and ESV solutions for architecture design?

Missing the ‘connection’? Talk to ARM and CoWare.

It’s all about the models. We have been using this tag line here at Synopsys for a while now. Now that SystemC TLM-2.0 finds more and more adoption in the industry, the focus is shifting from proprietary simulation by itself to standards based simulation. That shift enables interoperability and with that the models become much more important, just as the productivity tools making life with simulations easier.

Sometimes the challenge with abstract models can be … that they are abstract and that they are models. Per definition they are omitting information. That may be OK for abstract are like the “Model for an Unknown Monument” to the left (Source: EspenDietrichson). It requires some thought when applied to electronic design.

At ARM TechCon3 I will present this Friday a talk on “Increasing Software Development Productivity with ARM and Synopsys Modeling Solutions”. The main theme will be that all models have their limitations and that users have to be thoughtful how to apply them. Specifically, I will talk about the eight main characteristics for choosing models, especially when used for software development in virtual platforms or on FPGA prototypes (which can be considered as yet another “model”, even though they are considerably “more real”):

• Time of Availability: Once the specifications for a specific design are frozen, the time it takes for models to become available directly determines how long software developers will have to wait before starting on the project.
• Execution Speed: Ideally models provide an accurate representation of how fast the real hardware will execute. For software regressions, execution that is faster than real time can be beneficial.
• Accuracy: The type of software being developed determines how accurate the underlying models have to be to represent the actual target hardware, ensuring that issues identified at the hardware/software boundary are not introduced by the development method itself.
• Production Cost: The cost of models is comprised of both the actual cost of production, as well as the overhead cost of bringing up hardware/software designs within it. The production cost determines how easy a development method can be replicated to furnish software development teams.
• Bring-up Cost: Any required activity needed to develop models outside of what is absolute necessary to get to silicon can be considered overhead. Often the intensity of the pressure that software teams face to get access to early representations of the hardware determines whether or not the investment in bring-up cost is considered in order to create positive returns.
• Debug Insight: The ability to analyze the inside of a design, i.e. being able to access signals, registers and the state of the hardware/software design, is a very important model characteristic to enable debug.
• Execution Control: During debug, it is important to stop the models of the target hardware using assertions in the hardware or breakpoints in the software, especially for designs with multiple processors in which all components have to stop in a synchronized fashion.
• System Interfaces: If the target design is an SoC, it is important to be able to connect the models to real-world interfaces. For example, if a USB interface is involved, for verification and software development it is important to connect the development method to real USB protocol stacks. Similarly, for network and wireless air interfaces, connection of the design representation to real world software is important to execute software development.

The talk will be at ARM TechCon3 on Friday, 10/23, at 10:00am in the MCUs & Tools track. I am looking forward to meeting you there to discuss this further.

I will also be available on the exhibition floor on Wednesday and Thursday to present our Virtual Platform solutions and the connections to the ARM Fast Model Enablement program, through which ARM and Synopsys provide a critical mass of models to get closer to the goal of drag and drop assembly of virtual platforms. Enabled through standardization with the SystemC TLM-2.0 APIs, ARM based subsystems containing Fast Models from ARM combined with busses, peripherals and infrastructure components from the DesignWare System-Level Library can be integrated into virtual platforms using the Synopsys Innovator IDE. Together with Synopsys services to enable model customization for peripherals and processors, ARM and Synopsys partner to enable developers to get to virtual platforms with the right combination of models for software development, verification and architecture as early as possible.

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.

Well, for those of you familiar with dancing, I am not talking here about the sequence in Rumba – albeit that’s fun too – but instead of being within a hockey stick adoption curve. How do you identify a trend clearly? You ask the same question multiple times and over time you will see the trend. That’s what we did with the following question: “What percentage of your total project effort is spent on software development (vs. hardware development) during design?”. We asked this question since March 2008 – at the Synopsys North American User Group meeting SNUG, then throughout the year during later user group meetings. We then asked again at DVCON 2009 in San Jose and finally at two recent events – the Virtual Multicore Conference and the EETimes Virtual SoC Conference (for which by the way you can still register and watch the archived presentations and our virtual booth).

The result is quite amazing to me and shown in an animated graphic on the left. Essentially, over this 18 month period the answer to this question shifted fundamentally. At SNUG 2008 84% of the users responded with either “0% to 25%” or “26% to 50%”. That means that for 84% the hardware effort was dominant. However, 46% already responded at that time that the software effort is between “26% and 50%”. I was quite happy with that response at the time.

Well, over the last 18 month the answer has shifted quite fundamentally. As the animation shows the numbers for software increased over the year. 15 month later, at the Virtual Multicore Conference, 61% of the respondents reported higher effort on the software side. And most recently, 18 month after we asked that question for the first time, at the EETimes Virtual SoC Conference 54% reported higher effort on the software side. That number is slightly down from the previous peak, but the audience was much more hardware oriented compared to the multicore conference.

So what does it all mean? Are we within the hockey stick transition to software taking over in importance in chip design? Perhaps. This is a good and relevant data point. And the impact on traditional hardware techniques may be even more profound, as I outlined in my Electronic Design column “When One Plus One Has To Be Less Than One”. Software becomes the means for verification, i.e. the software running on processors in the design becomes the actual testbench. The main advantage here is that the testbench can be re-used across different process steps:

• Verification can start using transaction-level models and virtual platforms even before RTL is available
• Once RTL is developed, the same testbenches can be re-used, now verifying the RTL in co-simulations of TLM models and RTL
• When the RTL is mapped to a FPGA prototype, the same testbench can still be re-used – both in pure FPGA hardware and in System Prototypes – hybrids of virtual platforms and FPGA prototypes.
• Even post silicon the same testbenches can be executed to test that that actual silicon is correct.

There are obvious differences in the amount of verifiable detail in each steps. Still, it looks like we have interesting times for verification ahead of us.