Archive for the 'Models' Category

Transaction-level models are the main building blocks of virtual prototypes, which are used for early software development. In my last blog post, I briefly introduced the different kinds of software tasks and the implications for models. Today, I want to talk about the modeling requirements for early SoC bring up. As I mentioned, understanding the software requirements correctly provides two clear benefits: 1) it makes modeling easier through a more focused application and 2) it increases the value for the software developer through more tailored modeling capabilities such as debug features.

Within the context of pre-silicon software development for SoCs, the dominate use model for virtual prototypes is the bring-up of both the operating system and the chip validation suite. To bring up an operating system such as Linux, you must consider multiple aspects: primarily the CPU architecture specific code, the peripheral device specific drivers and the SoC/platform (aka machine) specific configuration.  Once a new CPU architecture is supported, or a device driver is available, they can be leveraged by the different platforms. Still, it is surprising how much code you have to write (and validate) to support a new platform. Of course, this platform support code will need to register all the different devices and set up the memory map and interrupts of the platform, but interestingly a lot of the platform specific code just deals with clock and voltage control (e.g. TI OMAP). Power domains are defined; voltage levels and frequencies are configured all over the place. Linux provides specific clock and regulator frameworks as well as the so called CPUFREQ framework for DVFS which are also used by the various power management frameworks.  Most of the settings are managed by the board’s power management IC (PMIC), or the on chip power-reset-clock-management-unit (PRCM).

This is not just happening for advanced features such as DVFS.  These techniques are also employed to get the simplest peripherals to work such as a UART. Before the UART driver can access the UART, it has to be clocked and powered. If this is not the case, the register interface of the UART will be in an undefined state and many TLMs do not take care of this situation today. In order to have a model support these aspects of the software, the model should perform a simple check to verify any abnormal operating conditions and inform about them. This simple addition to the model will greatly improve the value of the model and make software development and debugging more efficient.

Transaction Level Model - Clock/Voltage/Reset Sensitivity

Of course, it is necessary that these models are also equipped with ports that provide information about voltage and frequency, so that the model can check whether the levels are within acceptable limits. This does not mean that we need cycle accuracy with sensitivity to the clock, but rather we are interested in supplying the model with numeric information about the frequency and voltage.

The software is driving the clock tree and power network by configuring the power reset clock management (PRCM) unit or the power management IC. Thus, our virtual prototype should have an abstract model of this component that provides an accurate register interface. The internals of this model are not relevant in this context unless we also want to develop the firmware here. All that is required is that the clock and voltage lines are driven correctly by this model and the topologies of these networks are accurate.

Power Reset Clock Management Unit

So, in summary, with three relatively simple additions to an abstract, loosely timed virtual prototype we can greatly increase its value:

• TLM should check voltage and frequency values are in acceptable ranges
• A register accurate model of the power management IC and/or power management IC
• Accurate topology of the clock, reset and voltage networks.

By the way, did you know that wrong constraints and settings of the software-driven voltage regulators can result in hardware damage? I bet you’d love to be able to just restart your simulation rather than explaining to your management why the board can now only be used for decoration in the office lobby.

In this post, I would like to share some perspectives on the transaction-level models needed for the creation of virtual prototypes. Just recently, TLMCentral kicked off a contest seeking the “best” model for a mobile phone sensor device. What actually makes a “good” model?  The most ad-hoc answer to this question has historically been that the best model is the fastest and most accurate. However, if you ask about the reason for this, you probably won’t get a very precise answer. What does “accurate” mean? What is the definition of “fast”?  Will an accurate and fast model be available early enough to start software development before hardware is available and therefore meet time-to-market demands?

 

Simulation performance and accuracy (timing and function) are for sure valid aspects.  But, there is much more to consider.  The opportunity for the “best” model arises when user requirements are understood correctly.  When this happens, model creation can be greatly simplified and sped up. The model will have more value for the end-user at an even lower cost.

 

A good model, in my eyes, is one that serves the purpose of the user at the right point, on time at a proper cost. Here, the user task has to be carefully reviewed before selecting or creating a TLM model. What is the user intending to accomplish with the model? Simply identifying that a model should be used for software development is not the right level of diversification we are looking for. It does not constrain the requirements! Thus, we would again need a model that has to be able to do everything. While this is a challenge that often has to be tackled by TLM model providers, it is not something that you want to deal with when enabling a certain class of the end-users in your project.

 

In the remainder of the post I want to provide some software perspectives on models. In context of those perspectives I would like to introduce the aspects that make a model valuable.

 

The mobile phone application developer uses models in context of emulators being a backend to SDKs. This class of users demands that the models executes at speeds closer to the real device. For interface IP models, it is necessary for the model to be connected to the real world. E.g. the develop can use his/her real “iPhone” to drive the sensor model in the virtual prototype. S/He values the fact that he is able to record and repeat the stimuli for testing. It sounds complex, but doesn’t need to be. An application developer will not look underneath the APIs he is using which leaves great room for abstraction/simplification. In the context of Android, a sensor model may be a combination of a simple middleware along with a generic interface model (e.g. a UART) that is used to send and receive sensor data. This is close to the way it is realized in the Qemu Android emulator.

 

 

 

However, if the focus is middleware-, and not application-development, then this level of abstraction does not hold true anymore. Still, we typically have fewer requirements on simulation performance. The scenarios in which we are using the model are mainly in context of short embedded directed tests. E.g. For compliance testing, Android provides small sensor test applications for developers that are creating their own sensor middleware. The middleware is interfacing with the driver of the OS. Thus, our model should be accurate up to the level of the driver’s user interfaces.  This implies that the coarse grain states of the IP are modeled correctly as those are typically reflected in how the driver is operated. E.g. the sensor is activated and configured to provide updated gyroscope values every 500ms via the file “/sys/class/sensors/gyroscope”.  

 

To enable this, it is not required to realize such a model register accurate or register complete in the first place. Only a subset of the driver needs to be realized and functions such as clock, reset, voltage control can be neglected to simplify the modeling. The middleware developer will get more value through the additional debug and tracing capabilities we can put into the model. A good model will assist the developer and inform him/her about the coarse grain operation. Why are things happening in the model, or why are things not happening? This level of visibility can be of great help for understanding the IP and debugging the embedded software.

 

Someone who develops drivers or brings up a device in context of a board configuration will need more functional completeness and accuracy. Here, an accurate representation of the register map is almost mandatory. This also concerns functions for the power management integration such as clock, reset, and voltage sensitivity to bring-up and test for the Linux clock/voltage regulator frameworks. The model has to provide the proper response when configuring it through the register interface and also trigger interrupts. Therefore, a certain level of timing accuracy is required. However, this does not refer to having the data-path of the model being cycle- accurate/-approximate. The correct operation of the IP in the system context requires responses of the model at proper times. E.g. a timer will fire interrupts in periodic intervals. But again, model abstraction can be done to simplify the task. For the purpose of driver development or board bring up, the most important aspect is the control plane. Here, e.g. the data plane of a video accelerator IP can be abstracted to just show dummy data.

 

In summary, creating a model efficiently requires careful review of the end user design task. The model development can be staged and aligned with the software development plan, to incrementally enable new software development tasks. Understanding the requirements correctly allows creating models at lower cost and with higher end-user value.  

What do the Inchron Real Time Congress this week and my last weekend home project have in common? They both are all about complexity, real-time, apps and platforms those apps run on. In automotive and consumer domains, apps are running on platforms in systems of systems. The question to me at this point is how many platforms – like AUTOSAR, GENIVI, Android, IOS, Windows Mobile etc. – as well as versions of them can an apps interested user really handle?

Let’s start with the Inchron Real Time Congress, which I was attending on Tuesday and Wednesday. After BMW talked about  the networked car with several networked sub domains. Continental then talked about how to enable Human Machine Interfaces (HMI) with one hardware and hypervisors underneath (see the graphic on the left, Source: Continental). Other presenters from Continental, Audi and Volkswagen confirmed the trend to the networked car and the discussion during the day centered around the real time aspects of car-related applications.

While my next “apps driven” car purchase is likely still some time away, my home remodel reminds me in a nightmarish way of what is ahead of us in cars and other apps driven domains. After a one-year re-modeling project and expansion, one geeky upside is that I now have CAT6 installed throughout our home. Everything is installed in-wall. I am happy (and somewhat proud) to report that the engineer in me is still present as without a problem I was able to add Ethernet plugs and such during the last weekend. If this whole system-level gig does not work out, I definitely am still capable of planning and installing home entertainment systems 


Not unlike the networked car, our house now has several networked sub-systems, in our case the home office, bed room, living room and family room. Connected via CAT6, the closet in the bed room hosts a gigabit switch to connect the video server, an Apple iMac hosted in the home office, to the rest of the house. An Apple TV (Version 1) and a Samsung Blue-Ray Player connect via a receiver to a Samsung wide-screen TV in the living room. An Apple TV (Version 2) and an iPOD dock connect via a receiver to a Sharp wide-screen TV in the bed-room. A Comcast multi-room DVR connects from the bed room to the family and living rooms.

The second Apple TV was purchased pretty much specifically to enable more “Family Guy” episodes via NetFlix (OK, Caillou and Blues Clues are found here too). As always, the Apple interface is slick and intuitive. It took me 15 minutes from unpacking the box to streaming video via NetFlix. The nightmare started when I activated the internet service on my Blue-Ray player. The Samsung “Smart Hub” updated via internet. The Netflix interface looked much different on the Samsung “Smart Hub” platform and I had to tinker a while until I had signed up for a Samsung account, registered the DVD player and got to streaming video after about 90 minutes. It took me another hour to figure out how to get to the latest revision of the Samsung platform via internet, after which all apps needed to be upgraded as well. Now the interface for Netflix roughly resembles the Apple interface, but is less slick, slower and looks different enough to notice.

How do I explain these different interfaces to my wife and daughter? I have no idea. Why are they different, even on the same platform across revisions? Ideally they should not be.

To make things more complex 
. our Samsung TV also has an internet “Smart Hub” interface with apps. Comcast just sent me a advertisement on their apps. I am hesitating to unpack the Sony play station for the family room – yet another platform and yet another apps interface.

At the system-level I am musing in this Blog mostly about aspects at the hardware software interface. The experience with my home network, combined with what I hear about the future of cars, drives me to some conclusions applicable to my world at work of tools enabling software development and system-level design:

• The versioning of platforms and apps running on it, needs to be solved before the mainstream user – like my mom, dad, wife and daughter – can adopt these new technologies. Linaro is a first step for Linux. We desperately need similar activities for AUTOSAR, Android and other platforms.
• Case in point: Gadget Magazine T3 just compared the HTC Flyer, the RIM Playbook and the ASUS EEE Pad Transformer, three tablets. The HTC runs Android 2.3 with a HTC Sense custom UI on it. The RIM Playbook runs the QNX user interface. The ASUS runs Android for tablets – Honeycomb. Three fundamentally different user experiences are OK in competition, but not in the same environment (like our house, or a car). Fellow Blogger Steve Leibson recently referred in his EDA360 Insider post to a PCWorld article on why there are little Honeycomb apps. Oh well.
• To get to mainstream adoption, we may need “Uber-Apps”, both for hardware and software, which stand above the actual apps. I finally may have a good reason to get an iPad, if it could be the “Uber-Interface” from which I can control all our apps and devices.
• “Owning the user experience” is more crucial than ever. Apple has mastered the art, but you have to commit to them completely. The situation in my family room would be completely unacceptable in a closed environment like a car. That’s why the car OEMs at the end will own every interface which touches the user. They will define the platforms their suppliers will need to enable in hardware and have to run apps on.
• Given that the tools I am responsible for sit right at the interface between hardware and software, monetization on apps we enable has always been a fascinating topics. With hardware providers (like Continental above) actively thinking about hypervisors to shield the software from the hardware, monetization on apps will become even more difficult for tool vendors.

Bottom line, apps have become a central part of system-level design and are impacting every step of the design process. Getting them fully adopted and which platforms will prevail, remains an interesting question. As always I am looking forward to your thoughts and comments!

The industry did it again! Once again we are tightening the loops from system-level to implementation even further. 2010 was the year in which TSMC added the system-level flow to their reference flows for the first time. This year’s TSMC Reference Flow 12 marks the second revision of a system-level flow in which we are connecting a semiconductor manufacturer.all the way up to the system-level!

In one my previous Blogs called “Disruptive Ripple Effects From Implementation to Systems” I did talk about the evolution of links between different abstraction levels over time. Originally the flows from idea were disconnected and data had to be re-entered at every abstraction level. Driven by the ever growing complexity, the industry came up with logic synthesis, inventing new description languages – Verilog and VHDL – and automated the loop leading to gates and eventually implementation. Later the implementation effects of layout could no longer be ignored and synthesis become aware of layouts, i.e. became physically knowledgeable. Then variability of implementation could no longer be ignored, extending the loop of predictability and correlation between the different abstraction levels even further.

With the recent announcement together with TSMC we now have arrived at the far right of the graph I had shown in my related Blog post. The transaction-level is now connected all the way down into implementation. The top-graph in this post shows how this looks to a user at the transaction-level. Technologies have been characterized for power, performance and area (hence the abbreviation PPA). The user can literally instantiate power analysis objects from libraries and choose a related technology too be used during analysis.

What has changed from last year’s Reference Flow 11? Well, in RF11 users would generate data at the TLM-level and then feed activity data into special tools for technology analysis. Now, with RF12, this loop has been closed and everything can be chosen at the TLM level – as shown above in “Virtual Platform Analyzer”, i.e,. the tool associated with Virtual Prototype Analysis.

In the first graph you can spot on the bottom right the terminal interacting with the virtual platform running Linux on a ARM Cortex A9 Fast Model as part of a Virtual Prototype. The actual power analysis is shown in the bottom graph of this post. Users can trace processes running in software on the multiple CPUs, track the different states of the power models and follow the energy traced throughout the CPU and associated peripherals and compute engines like the H.264 decoder in the system.

How cool is that? Now that we are closing this loop, the next level is already on the horizon 
 the next description level may be independent of hardware and software. UML and SysML, here we come!

This is a follow up post to my July 7th Blog entry called “Dealing with Moving Targets in Interesting Times”. In response to Nokia selling its modem division to Renesas I had thought about who the actual customers for system-design tools are in a landscape of consolidation and change. It turns out that there are actually more parties involved these days, which increases the potential for business but makes the interaction a bit more intricate. We are about to close the loop to manufacturing even tighter, just like we did in the days of PKS – Physically Knowledgeable Synthesis – back a decade ago.

I remember those days quite clearly – has it really been ten years? When searching for “PKS” I found headlines like “IBM Integrates Envisia PKS Into Its ASIC Design Flow”, “Cadence’s Ambit PKS speeds tapeout at EmpowerTel Networks” and “Cadence Envisia Physically Knowledgeable Synthesis Selected by Ericsson Microwave Systems AB; Cadence Envisia PKS Used For Successful Million-Gate Production Design”. These headlines were all from about mid 2000. I am getting sentimental – at that time I was the product manager for Cierto Virtual Component Co-Design (VCC), which was probably 10 years ahead of its time. Somehow corporate had hired a leftover consultant to rename all or products to sound like cars. And I remember being somewhat jealous of my colleague’s situation in synthesis, because unlike us in the “Cierto” system-level flow, the “Envisia” guys in synthesis just had found a way to connect to the main business of layout and implementation. They made the next level down in abstraction – layout – part of their flow. The static predictions of what the impact of layout on timing would be, were simply running out of steam. Layout and synthesis would be integrated, or at that time, at least synthesis became layout aware. From a business perspective this meant that the next abstraction level up – logic synthesis – was connecting directly to the main business.

So ten years later I find myself looking at an ever changing landscape of customers. System Houses like Nokia abandon hardware and do only software. Semiconductor houses like TI, Marvell and Freescale provide more and more software as part of their complex platforms. IP providers like Tensilica combine their IP and software to provide sub-systems. In that changing landscape we are now starting to connect the manufacturing of foundries with the system-level world of transaction-level models – we are closing the loop just like ten years ago logic synthesis did. The picture on the left illustrates what is happening. Properties like power, performance and area (PPA) are characterized at the foundry level and annotated into system-level transaction-level models. As a result the design flow becomes more predictable and decisions can move up in the design chain to the user who defines the architecture, more and more the system house based on the software architecture.

Here are two examples which underline this point:

• TSMC recently announced Reference Flow 11, in which users for the first time ever now can get a foundry defined reference flow for system-level design. In the examples users can analyze their technology choice’s impact on power at the transaction-level the effect  .
• At the Interoperability Breakfast at DAC, Subramani Kengeri (Global Foundries) presented together with John Cornish (ARM) and Joachim Kunkel (Synopsys), how IP Providers, Foundries and System-Level Tool Providers interact more closely to provide technology characterizations into transaction-level models. All of this is meant to raise the level of abstraction at which design decisions happen. Global Foundries was specifically pointing to Virtual Prototypes as “Application optimized Integrated Platforms and Collaborative System Design Solutions” at the system-level combined with “Automated Precision Manufacturing (APM) and Early enablement of System level views” at the silicon level.

History repeats itself! Ten years on I find myself in the same situation as my “Envisia”colleagues were ten years ago. We are starting to close the loop from system-level to implementation! All this is great news and probably yet another indicator that the marker for system-level design tools is finally moving towards mainstream.

Commuting back home on Central Expressway, KFOG was playing Pink Floyd’s “The Wall”, which reminded me of all the comments that projects will run into brick walls if they do not adopt system-level technologies. As January is the month of predictions, let’s see whether the trends in semiconductor design can add more bricks to that wall into which projects allegedly will run into (picture source here).

As I wrote in my column in the 2010 Outlook issue of Electronic Design “2010 Will Change The Balance In Verification”, there are definitely some changes ahead in hardware verification, mostly caused by the increased importance of embedded software for the success of semiconductor designs. However, in looking at the trends in semiconductor design more holistically, there are eight trends which will add more bricks into the alleged complexity wall. Hey, and that in exchange will system-level design all the more necessary!

The eight major trends are (1) further miniaturization towards smaller technology nodes, (2) a decrease in overall design starts, (3) increased programmability and trends to software, (4) IP re-use, (5) application specificity, (6) adoption of multi-core architectures, (7) low power and (8) an increase of the analog/mixed signal portion of chips. All of these have profound impact on requirements for system-level design, specifically prototyping – using virtual platforms and FPGA prototyping:

• Further miniaturization (1) increases the sheer complexity of things users have to deal with. Judging from “The magic number 7 plus minus 2” users can’t handle complexity without divide and conquer. From a prototyping perspective virtual and FPGA prototypes simply need more capacity to prototype designs. This is a great trend causing more desire to combine virtual and hardware prototypes.

• The decrease in overall design starts (2) makes companies consider their investments much more carefully. As a result, platform based designs have emerged, which are flexible and programmable. In exchange this drives to more processor based design and more software. This increases the need for early software development in virtual platforms even prior to RTL and FPGA prototypes once RTL is available but still well before silicon.

• Increased programmability (3) and the trend towards more software are again great for virtual platforms and FPGA prototyping. Getting to an executable of the hardware under development as early is possible is becoming even more crucial for early software development, verification and architectural exploration.

• IP Re-use (4) is further increasing. Given that the integration of ten’s of IP components is not easy, delivery of transaction-level models in with SystemC TLM-2.0 APIs becomes mandatory for more and more customers. Great times for offerings in the transaction-level library space.

• Application specificity (5) is a important trend enabling system-level design for algorithms and for processor design. For example, LTE and other application specific libraries enable model based development of algorithms as well as transaction-level models for processors define application spaces a tool can play in. This means great times for tools with the right application libraries.

• Multicore architectures (6) may be the trend finally driving virtual platforms towards mainstream adoption. Good luck with trying to control multiple processors with breakpoints in the final hardware. System virtualization helps to allow multicore debugging, i.e. being able to individually control different processors flexibly to find race conditions, deadlocks etc.

• Low power (7) requires users to make assessments – and changes – as early as possible in the design flow. Trying to optimize for low power at stable RTL is crucial but likely has much less impact than choosing the right split of processors and dedicated hardware accelerators at the architectural level in the first place. Great times for ESL low power analysis.

• Higher analog/mixed signal content (8) leads to more specific needs to validate designs within their respective system contexts. Great times for prototypes – virtual and hardware – which can connect well to their respective system environments like USB, Ethernet and even wireless air interfaces.

So will 2010 be the year of ESL? As they say, predications are hard, especially about the future, but the various trends in semiconductor designs are definitely continuing to stack up bricks into those walls projects might run into if they do not employ system-level technologies. Interesting times!

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.

Getting of the campaign trail here for a bit – if you have not yet voted for me as EDA Top Blogger, please do so – I reviewed some statistics which went into an article I recently wrote for my ED Column. The article is called ‘When One Plus One Has To Be Less Than One” and I am seriously expecting to get in trouble with my math teacher back in Germany.

Sorry, Herr Stabba, I know that 1+1 can not be smaller than one, but that’s actually what we are asked to do here in EDA. Exciting – a new attempt at the impossible every day 


What I argued in the article was essentially, that every new methodology has to have a good, measurable ROI. With moving to a next level of abstraction, the additional work spent there has to pay off, i.e. the new tasks added on, have to lead to less work overall. Specifically, when using higher levels of abstraction for verification, the approach can only be adopted if overall the verification effort gets reduced.

In the article I do refer to some statistics we measured here at Synopsys, and given that the upcoming theme for our virtual platforms at DAC will actually be “Software Driven Verification”, I wanted to detail them a little bit:

Well, there is hope yet. To my surprise, in a recent survey we did at DVCon, over 50% of the respondents told us that they are already running embedded software on embedded processors in their design to verify the surrounding hardware. We also know that simulation of RTL in conjunction with TLM processor models runs between 20 to 50 times faster than their pure-RTL counterparts.

So let’s be a bit more specific. We actually asked the question twice now 
 at DVCon009 in February and at Virtual Multicore Conference in June. We got 54 respondents at DVCon and 171 at the Virtual Multicore Conference.

The results are shown on the left here and averaged over the two events. The results were remarkably similar for both events.

First, only 10% of the designs given this audience have no embedded processors in them. 90% of the designs with processors. The second item then was surprising. We specifically asked: “Are you using the processors in your design for hardware verification, i.e. run test benches on them to verify hardware?”. More than 50% responded with yes, some of them only use this approach for post silicon validation. While I had seen this use case in customers, I was surprised by the overall percentage of respondents here.

So here we go. This may just be a pivotal point for hardware verification 
 using the embedded software to do it. There are lots of advantages:

• Users can start with the test bench development on TLM processor models prior to the actual availability of RTL
• Once RTL is available, TLM models of the processor can be used to speed up verification, keeping as much at the TLM level as possible
• When a rapid prototypes becomes available with RTL getting stable, processor models can still remain on the TLM side in the virtual portion of System Prototypes.
• Once Silicon becomes available, the same test benches still run.

True verification re-use across the different stages. Sweet.

You may remember this story from Red Hat. A couple of years ago I heard a presentation from a Red Hat representative, who was telling a story from the early days. At a time when Red Hat tried to figure out their business model, a couple of key executives went on an offsite and as part of that were kayaking in Colorado or another equally beautiful area. The guide they had taking care of them asked them after a while “so, what are y’all doing here, what line of work are you in”. The team apparently replied with “We are trying to find out how to sell free stuff”. Allegedly the guide thought for a while and then came back with “Well, good luck. Sounds hard!”.

Apparently it is still hard to make money with free stuff. Which brings me to Imperas and OVP. First I need a disclaimer: I have been their VP Marketing in 2006/2007. In my judgment their technology for processor modeling is cool and well thought out, probably the best I have seen so far – for processor modeling that is. They are also a partner for our System-Level Catalyst program here at Synopsys.

Imperas recently announced that they support the OSCI SystemC TLM-2.0 APIs. This – in my mind – has made them a valid player for processor models as SystemC TLM-2.0 is now the standards on which all vendors in the virtual platform space keep their models interoperable.

On the commercial side, Imperas recently announced some license changes:

Until now, OVPsim has been available on Linux to Imperas commercial customers only and was funded by their commercial contracts. We are now making OVPsim available on Linux to the wider OVP community.

 

To enable and fund this, from the new release, OVPsim will only be free for non-commercial usage. Commercial use of OVPsim on Windows or Linux will now require a commercial license from Imperas with pricing from $300/month per user. Commercial users can download and use the free OVPsim for evaluation purposes.

So this means that to simulate processor models, the price for the OVP offering just went from free on Windows (Linux was always charged for as the first sentence above shows) to $3600 per year per license on both platforms. This is an interesting step. Soon we will know, whether OVP users were actually interested in the openness of the APIs for processor modeling or in the aspect of free simulation. There is an interesting Blog post on this at Golden Pebbles, called “On Free, Open Source and VRM”, from which I borrowed the drawing on the left. I think the “free-ness” deserves an even bigger bubble in relationship to the “open-ness”, but time will tell. And when it comes to openness, the APIs for SystemC TLM-2.0 to enable model interoperability were open all along, so were the Freescale ADL descriptions for processor modeling, even prior to OVP. 

Overall this is another interesting twist in the discussion where the value for vendors is in virtual platforms. Is it simulation? Or debugging? The models? The tools enabling virtual platform development? It looks like the concept of completely free simulation to enable other tools around it – like Imperas had indicated in an interview around the “Blue Ocean Strategy” – did not quite work out from a commercial perspective. It is an interesting experiment though.

Here at Synopsys our slogan has been for quite some time “it’s all about the models”. It has been the major driving thought for our DesignWare System-Level Library, which works in all SystemC compatible environments. More models being SystemC TLM-2.0 compatible – like the OVP models – can only help to further fuel adoption of SystemC based virtual platforms.

There are a couple of things which impressed me permanently back in school. One of them is the realization of the superiority of cooperation over competition. No, this is not a post on world peace. It all started with an article called “Cooperation and Competition”. It was setting up a simple game. You are a producer of a good of any value, let’s say Slow Churned Rocky Road Ice Cream. You have a deal with a partner of yours, who is paying you with some other good of equal value, let’s say plain Chocolate ice cream – my 4 year old daughter’s favorite. You arrange for a time of exchange, but instead of meeting directly, you put your respective goods at two different places in a forest and then go to the other place and pick up the goods intended for you.

Of course it is tempting to not deliver your own goods and only take what was left for you. This way you get it all, the ice cream you were supposed to give and the ice cream the other person gave you. Well, this now all becomes very interesting when you do this as a series of events, like every week. What is the best strategy to win? Any thoughts? I spent countless hours on my Commodore 64 to figure it out. I even had local competitions with my friends to develop the best strategies on how to win. It was almost my dream to connect this to some evolution strategy simulation to identify who eventually would survive in a virtual society.

There were two main take aways from this and they stuck with me ever since. First, cooperation wins. If you always deliver your ice cream, everybody wins. However, there are of course the meanies and bullies who don’t deliver their ice cream. How to deal with them? Well, it turns out that the simplest strategy against them in this game with simple rules is “Tit for Tat”. Beat them back once and then switch to cooperation again.

Founding System-Level Catalyst Members

I have been notably absent from this Blog with no posts for the last two weeks. The reason is that I was heavily involved in launching a cooperative partner program, launched today. It is called the System-Level Catalyst program and in the true spirit of my Rocky Road ice cream experience at school: It is all about cooperation. The program is meant to accelerate the adoption of system-level design and verification, in short to help ESL. It includes at this point 27 partners of our system-level solutions at Synopsys, the picture on the right here says it all!

The program is open to electronic design automation (EDA) vendors, intellectual property (IP) vendors, embedded software companies and service providers. It benefits our mutual customers by advancing tool and model interoperability and availability of system-level models and services. Our partners get access to Synopsys system-level and rapid prototyping products such as Innovator, DesignWareÂź System-Level Library, System Studio, SynplifyÂź DSP and the ConfirmaTM platform. They can also use the System-Level Catalyst logo with their products or services to indicate system-level interoperability.

The partners can be lumped into three different categories: Models, Embedded Software and Verification. The specifics are pretty straight forward:

• IP providers and EDA vendors get access to and support for Synopsys tool and library offerings to validate and demonstrate interoperability of system-level models of their IP and their tool solutions
• Embedded software vendors get access to Synopsys’ Innovator and DesignWare System-Level Library to validate and demonstrate interoperability of debuggers
• Qualifying embedded software developers who specialize in the development of software for Synopsys DesignWare Cores get access to virtual platforms and Confirma rapid prototyping platforms for software development prior to silicon availability
• Training and services companies get access to Synopsys system-level tools in order to help system-level teams rapidly adopt the best practices for system-level design, virtual platforms, digital signal processing and FPGA-based rapid prototyping

I welcome you to check out the partner pages of the System-Level Catalyst Program and the 27 endorsements we got. Every partner has their own page on our websites (we have about 15 active at this point, the others will follow over the next couple of weeks), from which you can inquire on more information on the joint value our partners and us provide to you by clicking on the “tell me more link”.

Overall, I am convinced that cooperation wins! The system-level market’s growth and our customers’ adoption of system-level methodologies have been limited by severe market fragmentation and lack of model and tools interoperability. With the System-Level Catalyst Program, Synopsys is helping open up the system-level market to mainstream adoption, enabling new levels of interoperability.