The Technology Outlook section kicks off in the IEEE Spectrum of January 2000 authored by Linda Geppert and William Sweet with a discussion of the importance of standards. Microsoft was on trial for “proprietary standards”. Billy Joy was interviewed about JAVA, put into the public domain by Sun even though they controlled modifications and extensions to “protect it from the fate of SPICE and Unix”. Leonardo Chiariglione talks about what good has come from proprietary standards even though he also drove MPEG-2 as a standard.

So what was up in EDA? Of course! It was all about standards … The feud between SystemC and SystemVerilog was in full swing. Today, with 20-20 hindsight, we know that Co-Design Automation just elegantly played a MBA text book strategy game – picking a strong opponent to beat up – even though the technical differences between SystemVerilog and SystemC were pretty clear from the beginning. Now we also know that it worked.

Linda’s article kicks off with the three obstacles for IC Designers – lack of a unifying language for hardware and software, verification of design correctness and timing closure.

Focusing on the first here, Co-Design Automation is mentioned to have “ruled out the usefulness of extending an existing language to meet system-on-chip needs”, with candidates for extension having been C, C++, Java, and Verilog. Satisfying the three requirements which they set forth for a new language – unification the design process, improvement of design efficiency and evolution from an existing methodology – SuperLog was conceived. The opponent they had chosen was the SystemC Initiative. Several partners, including Synopsys and CoWare, believed that no new language was needed. They introduced SystemC, a modeling platform that extended the capabilities and advantages of C++ into the hardware domain. The supporters of SystemC came top down so to speak and violating Co-Design’s third rule to be evolutionary. They based their path on the observation that most software developers use C and C++ and many systems developers use C++ already to describe their systems at a behavioral level. But until SystemC it has not been possible to describe hardware using the same language.

So where are we ten years later? No surprise – standards have taken over. And has anybody won? No, both have, in their own way. Co-Design Automation was acquired by Synopsys and SuperLog was put into the standardization process to create SystemVerilog for both verification and design. This was the start of the end of proprietary languages like Verisity’s E. Today SystemVerilog is the clear winning language for evolutionary improving existing hardware design and verification – just as Co-Design Automation had predicted. Has it found an entry into software development? No, it hasn’t.

Equally, on the software side, SystemC has won the battle when it comes to becoming the interconnect fabric for virtual platforms, which enable software development. Standardization played a similarly important role. Synopsys acquired Virtio, put key technologies into OSCI and the TLM-2.0 APIs were born from here as a collaboration within the standards body.

So what is the conclusion 10 years later? Well, three things. First, I have to give it to Steve Leibson and his law that it ‘takes 10 years for any disruptive technology to become pervasive in the design community". It looks like SystemC and SystemVerilog are two good examples of his empirical observation, then formulated as “law”. Second, standardization was and is a key component for technology adoption. And third, business is just business and often trumps technology. Co-Design Automation’s approach ten years ago to pick an opponent to get attention as a small company (even though technically the languages were obviously quite different and for different purposes) was the right business approach and played out beautifully, almost like in MBA text books.

Off to a new decade … It remains interesting!

ShareThis

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!

ShareThis

I was very excited to try out a new tool I downloaded to try the animation of .gif files. So why not combine my experiment with some blogging? I had participated to questions to some of the surveys we did here at Synopsys, specifically as it relates to the effort spent during projects on hardware and software development. The question we asked was “What percentage of your total project effort is spent on software development (vs. hardware development) during design?”. We asked this question at several events starting at the Synopsys User Group (SNUG) in Santa Clara 2008, all the way through 2008 at the other worldwide SNUG events and then through 2009 at DVCon and two virtual conferences.

Using my new tool I have the animated those results and then claimed a trend towards more software versus hardware. Brian Bailey rightfully pointed out that I should not have put the results from different events in sequence in order to determine a trend. And he is right, this is where I went wrong, even though the animation looks nice and seemed to indicate a trend.

The second set of comments was related to the animation itself, that it was difficult to follow and also difficult on the eyes. So below you find the data in an un-animated fashion. I also followed Jacob Engblom’s recommendation to check on the different communities which actually answered the survey.

My take away from all this is as follows:

• While I was wrong to indicate a trend over time, the importance of software the overall chip related project development effort  remains unquestionably an important issue.
• Results of the survey taken at the Virtual Multicore Conference 2009 skews the data the most, given the very high percentage of software engineers and system architects.
• The communities for the first three data sets and also the final one are pretty closely comparable.
• Going forward I will try to make sure that we ask the same questions on the community definition to make sure that we can compare the communities.

At the end of the day I lost a little bit too eager to try to outline a trend here, but when looking at the data objectively it is very clear that software is very important for project success. The fact that this is true across different communities who answered the surveys makes it even more sticky.

Thank you now for your reference the data I had animated right next to each other:

ShareThis

In his article on “The Use of Assertions” he refers to a Microsoft paper called “Assessing the Relationship between Software Assertions and Code Quality: An Empirical Investigation”. The paper nicely outlines that the use of assertions increases code quality and gives empirical proof. I include a graphic from page 10 of the paper below. The example nicely shows a high fault density for code that has zero assertion density and higher assertion density for code with low fault density.

So far so good.

The article also compares dynamic and static tools. There is a graph on page 11 which empirically shows that the bug percentages found dynamically via assertions are actually higher that the bug percentages using static analysis tools. Well, at first I was clinching and wondering – wouldn’t it be great if this could be done all statically? There are different embedded software companies out there focusing on static vs. dynamic testing and it reminds a bit of the hardware world where we find bugs using formal and dynamic verification as well. The immediate conclusion could be: Hey, they are not so different after all those hardware and software verification engineers.

However. after a great read of Microsoft’s James Larus, et. al, called “Righting Software” and some of the references from the original Microsoft Paper, it turns out there are are fundamental differences as well. In my mind there is always a difference of verifying “form” vs. verifying “function”. Verifying function means to me to make sure that code is doing what it is supposed to do, “wait until the USB connection is established and then start some other functions”. Verifying form means to me to make sure that the function is expressed the right way and correctly, i.e. all memory allocated used to do a task is indeed freed at the end, all internal and external coding guidelines are met.

It seems to me that dynamic assertions are used in both worlds to make sure function and form is met. I can make sure with an assertion that a specific state is hit – or never hit – as well as indicating that at the of a major process not all memory has been released, or semaphores have been executed in the wrong order, which may result in a risk of locks in a multicore system.

Static verification – at least the ones I encountered – is in the hardware world mostly used to verify function. Certain states have to be hit or are never allowed to become true. Given that there are so many the “state explosion” has always been an issue on the hardware side. From what I can tell the static verification tools in the software world seem to be focused on verification of form mostly. Hence I have not seen any issues around state explosion in the software world.

Some differences, some similarities. Perhaps assertions can be a bridge between HW and SW verification as my colleague Tom Borgstrom (read his Blog “On Verification” here) put it in a discussion recently. Or I may be completely wrong on all this … so I am looking forward to your comments!

ShareThis

The slides of the presentation Paul and Jim used showed some interesting data, including a graph on adoption of technologies on page 5. The iPhone and iTouch are the fastest adopted consumer devices ever, beating the iPod itself and the internet. Software is key to that success. Paul also pointed out that semiconductor economics determines a lot of issues in our industry. As a result of cost shifting to software, Paul and Jim articulated the requirement of a software sign-off.

If you have read any of my Blog entries before, then you know that I wholeheartedly agree with the importance of software. I also fully agree with the direction we need to take to enable software development and as early as possible hardware/software integration. The key is timing. I know exactly what my Dad would say in this situation. He would quote the old German saying that “nothing is consumed as hot as it is cooked”. Don’t take me wrong – I do not want to downplay the importance of change. The questions are when, how and where. On “when” – we certainly have been trying for a while to get to the next level of abstraction. With transaction based design we are making progress I am part of teams who are working on the “how” every day in our world of system-level design, virtual platforms for early software development an so on. On “where” it is very clear to me that change is not EDA specific, it happens everywhere in the semiconductor related eco-system.

The adoption curve of page 5 of Jim’s and Paul’s presentation made me choose the title of the Blog. One key differentiator in the development of Apple’s iPhone and the iTouch is “control”. The design of the hardware and the software is controlled by the same company. The situation is different for phones using Windows Mobile, Symbian or Android. Here the OS and hardware are controlled by different vendors. The OS effectively locks in the channel to access the hardware and provides the necessary monetization – providers take a share of every application sold through that channel. The idea is great and if a vendor has control of both he can flexibly allocate the monetization between hardware and software.

System-level design may turn out to be about control and about enabling communication to assert it. One of the beauty of system-level models – of functional algorithms and of architectural platforms running software – is that they allow effective interaction between companies or between groups within companies early on in the design flow. In exchange that communication enables better control of requirements. For example architects can change the hardware to address issues the software brought up. And eventually we may arrive as suggested by the ICCAD discussion at a “software signoff”. Will EDA help get us there as part of a constantly changing ecosystem? Time will tell. We are definitely working on it daily! My boss is knocking … back to work

ShareThis

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 …

ShareThis

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.

ShareThis

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.

ShareThis

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.

ShareThis

It started with a fun connection of wine to systems. Rogers, an avid wine enthusiast, showed papers from which he learned and optimized wine making. What else is more natural than using Cypress products to help with the wine making? In an effort to keep enough sun on his Pinot Noir but to not over heat it at the same time, a couple of videos introduced how Rogers used his company’s product PSOC – the programmable system on chip – to control the temperature system in his wine/backyard “Clos De La Tech”. Temperature sensors are literally inserted into the wine, gauge and wirelessly transmit the temperature and then literally trigger water cooling for the grapes.

Rogers outlined the history and reasoning behind PSOC and also was giving interesting insight into some of the PLD wars. He admitted Cypress’s loss against Lattice due to some of those issues they had not thought about. In the processor their customers simply chose the competitive solution to do “PSOBs”, i.e. programmable systems on board. However, the subsequent improvements positioned them well for some of the consumer needs in 2007 with products they did in 2004. With respect to the “evolution of programmable systems” Rogers clearly argued for PSOC 3 and PSOC 5 being the next steps after the transitions from PLD – CPLD – FPGA – PSOC. According to their business plan, this will let Cypress expand from being “the biggest dwarf in the room” (i.e. being a player only in the $5B 8bit microcontroller market) into the 16 Bit and 32 Bit markets, which they are addressing with 8051 and ARM Cortex M3 based products.

At the end Rogers turned his keynote theme around into “solving problems your boss jerked you around on because he talked to customers you never met”. Oh well.

Roger’s keynote was noticeably better attended than the keynotes on the first day. That made me think about the relevance of this show to our business here at Synopsys. We are here in the ARM Partner Pavillion and I was a track chair for sessions around “Improving Productivity at the HW/SW Interface”. Software becoming more important for our customers in the System on Chip (SoC) domain is a clear trend.

However, the type of embedded systems dealt with here in Boston are not 100% in our core target market. Browsing through the exhibition guide there are 132 companies. They fall (according to their own characterization) into the following categories:

This explains why I am looking here at a lot of hardware boards, lots of 8bit and 16bit microcontrollers … all of which are a tad less interesting for virtual platforms. It will be interesting to see which direction this conference and exhibition will take going forward.

ShareThis