Archive for the 'High Level Design Entry' Category

I am involved in discussions about adoption of system-level technologies a lot. System-level design in EDA and embedded software are always intertwined as the software is the main factor changing when going beyond RTL. Given that system-level design technologies expand beyond the traditional realm of hardware, their adoption is non-trivial for project teams. The overall situation reminds me more and more of Malcolm Gladwell’s “Outliers”: for success several factors have to fall in place together, not all of them in our control.

In “Outliers”, Malcolm Gladwell describes “The Story of Success” as it relates to people. He argues very convincingly how several things need to fall in place. Amongst them is being born at the right time of year to be more mature and therefore be chosen for special training in sports. Also, the need being there at exactly the right time for a technology like computers to be needed. In addition the right background is crucial to have the ability to develop a skill – parents supporting training, education capabilities or available of excess compute time on a mainframe.

The same is true in principle for technology adoption, and most certainly for system-level design technologies. The time for adoption needs to be right. Being too early means you simply may not have enough breathing room to get to the mainstream., which almost certainly means that you will fall into the chasm instead of crossing it. Having the right technology combined with the right environment for it to be adopted, is crucial. The actual user need has to be there too. If the users can get by with traditional techniques, then the reasons to change methodologies, i.e. to drop old habits, are not good enough. Finally, when the time is right, the technology exists, the need is there, users need to know about the solution too. That’s where the power of marketing comes in.

So where are we with system-level technologies? Let’s look back 15 years. As some of you know, I cam to the US in 1997 to run the technical marketing for the Felix Initiative at Cadence. The resulting product VCC has been described  – together with Synopsys’ Behavioral Compiler – as one of the two system-level trailblazer projects in “ESL Design and Verification: A Prescription for Electronic System Level Methodology (Systems on Silicon)” (Martin, Bailey, Piziali). Were we too early? Probably. Leading customer told us though that they would need function-architecture co-design as implemented in VCC at the time. They documented with their tool purchases that they had a need. Was the technology right? Well, it worked for the early adopter designs and most of its concepts – like transaction-based design – find itself now in technologies like SystemC TLM 2.0. Were user getting by with traditional techniques? Absolutely! It was getting harder, but why abandon a methodology that’s still works? Did users know about it? Well, we marketed it quite a bit, and knowledge about system-level design approaches was growing.

So what was missing? The technical barrier to adopt the technology was simply too high. In the case of VCC we were addressing hardware and software designers with a combined methodology. We had developed techniques to abstract hardware (processors, busses, peripherals etc.), to abstract software (RTOSs, drivers and the actual functionality) and we could even create the implementations from the complete executable system-level specification. Heck, at DAC in 2001 we were demoing a flow in which the customer told us during the demo whether a task should run in hardware or software and then we automatically re-built the design and did show the resulting layout of the hardware together with the implemented software image.

The results were awesome: We achieved much faster development times and more robust designs meeting their specifications. Too bad that software and hardware developers had to change the way they are doing things completely. Also the complete ecosystem of Processor, IP, RTOS and middleware providers had to provide models to make it all work.

In the spirit of fellow Blogger Steve Leibson’s law, that “it takes 10 years for any disruptive technology to become pervasive in the design community”, I am tempted to formulate my own “Schirrmeister’s Law” as “The ability to adopt a new design technology is inversely proportional to the number of changes it requires”. Sounds trivial. Still something I learned the hard way during the VCC days and something we often overlook today.

If I could just quantify and measure it. That is hard, but here is an example: Almost 15 years later Virtual Prototyping is going through its adoption. How many changes does it require? Well, compared to VCC it is much more adoptable given that the software developers do not need to abstract anything. The real software – namely .elf files – run on abstracted hardware. The number of changes – or additional steps – is limited to the hardware developer.

So what about the other adoption criteria? Is the time right? Well, software development has probably never gotten as much attention from the EDA side as it has these days. And our customers are expressing their concerns in every meeting I am at.. Do we have the right technology combined with the right environment for it to be adopted? The successes seem to speak for themselves – we have real users achieving real results. Is the user need there, do users get by with traditional techniques? We recently did a survey of about 800 embedded software developers. One of the questions we asked was “What target execution environment are you using for your embedded software development?”. The results are shown on the left. The top four answers are pointing to hardware based techniques, so they seem to work. Probing for limitations on those techniques users confirmed issues which I have written about in this Blog before – like the ability to control and debug the execution. Finally, whether software users are aware of virtual prototyping was a question intended to check whether target users know about the technology. There is definitely room for marketing effort here as the awareness was lower than we had hoped.

Bottom line, the adoption of system-level technologies like Virtual Prototyping remains a hot topic. Certainly the industry has lowered the barriers to adoption, but there is still some distance to go. The number of changes we ask users to adopt technologies is often still significant enough to shy away from adoption, even if it means mortgaging the future …

I will think about how to measure my postulated “Schirrmeister’s Law” above with quantifiable data. As always, I welcome your thoughts.

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!

The big topic these days seem to be the effects of 3D and silicon technology. Even though I am now more of a system-level guy, I do have full appreciation of technology effects given that for the first chip I developed, I had to design a three transistor memory cell which ended up in a FFT Chip for HDTV research. An interesting question I get asked more often these days is how the changes in semiconductor technology and assembly will impact the system level. My answer is: profoundly! How fast we will get there and how disruptive they will be, remains an open question to me.

When I developed the FFT chip mentioned earlier it was using Cadence Edge. Oops. I just gave away my age, did I? Needless to say, as indicated in the graph on the left, we did use RTL for verification only, had our own library of layout cells which we did assemble by hand based on gate-level schematics entered manually.

Later that decade I evaluated Logic Synthesis for the “Deutsche Telekom”. Great stuff, combining RTL and Gates and mapping from one to the other.

Well, even later that decade I arrived in the US, being very much involved in system-level already, but following closely the activities around what was at the time called “Physically Knowledgeable Synthesis”. Layout had been added to the mix and its effects were added into the logic synthesis process because the good old metrics of predicting the connections between blocks and gates had broken.

New decade, new challenge. Variability in manufacturing broke the good old flows and had to be considered as part of the equation. As commonality, in every step design predictability had been improved using characterization of lower-level technology effects.

So where are we today? Transaction-Level Models (TLM) still had been disconnected from the implementation process. That is, until last year, when we rolled out characterization of technology for low power all the way up into TLM models as part of the TSMC ESL Reference Flow. As a result the links from TLM based design to implementation are becoming tighter, predictability improves.

So back to the original premise – will technologies like 3D change design flows all the way up to the system-level? Absolutely! Are we ready from a technology perspective? Pretty much so. System-level tools helping with the “What If” decisions are pretty much agnostic to whether they deal with chips, chip-sets or systems. A good example are tools for Multicore Optimization. Their applicability goes well beyond the chip, they are used to make architecture decisions for chips, for chip-sets as well as for boards.

There is one caveat though, and it is a huge one. These tools need models to feed them and the models determine their applicability. Case in point, if the tools for Multicore Optimization are supposed to help with assessing the “what if” around 3D effects – for example how the partitioning of the memory amongst chips will impact performance – then appropriate models need to be available. Here is where the battle will be fought and the effort will have to be spent. Without models we will be lost.

Still, approaches like the TSMC ESL Reference Flow – which provides models of the technology all the way up into the level of TLMs – are a clear indicator that we are approaching the next level of integration, essentially creating predictability via characterization all the way up from TLMs to implementation. However, availability of models will determine when these approaches will become mainstream!

A trip up to Mount Tamalpais can not only be fun, it can change perspectives. It did hit me again when enjoying the panoramic view from up there, that system-level design value is hard to articulate. When taking the “View from the Top” perspective, one is so far away from the actual design implementation that value is pretty straightforward to understand but hard to translate into actual dollars. That is indeed a challenge we find in electronic system-level design as well.

The bay area is certainly created in a quite stunning fashion, I am enclosing the picture above as proof. I have used the analogy of “world design” to explain system-level design before, so this was living proof.

Our day up there was meant to take our minds off the house re-modeling, specifically the issues with the floor and ceiling height in the to-be-remodeled family room. On the architectural plan everything looked straight forward. Quite a contrast now while we are in implementation. The dry-wall is off, a fact that causes immediate regret given the bad shape the ceiling beams. Not to mention the floor height being off by an inch and the ceiling height changing between the kitchen and the family room.

No problem, says my contractor. Well, good for him. At this point I really have only limited options to proceed. Stopping the project is not really an option, so I will pay the additional amount in tools and work to get it done.

It all sounds so familiar from being in system-level design for as long as I have. And yes, I will get in trouble for having had work-thoughts on this trip to Mount Tamalpais. When a design team is 2 weeks prior to tape out, they will probably put up the money for additional resources and tools to achieve timing closure, the last ECO etc. In the backend of chip design the proximity to tape out is so close to what the designer is doing, that the value of adding resources and tools is obvious. Unfortunately for us in system-level design, the value gets harder to explain the farther one is away from tape out. The same guy putting up the licenses to close on timing two weeks prior to tape out, is typically much harder to convince 2 years in advance to tape out to spend money on system-level tools.

On the software side we have done a better job articulating the value of parallelizing software and hardware development. On the pure hardware side it may turn out that the only way to get over this issue to get closer to implementation. That does not necessarily mean that everything has to be automatically created from early system-level descriptions, but the predictability and correlation of early results with the implementation details will have to increase. This means the loop of abstracting and characterizing data from the actual technology implementation will widen even more. We have seen first cases of that in last years System-Level Reference Flow 11 for TSMC, in which implementation details from the implementation technology have been abstracted all the way up to the system-level.

Back to our home re-model here – there was no way for the architect to know how the beams in the ceiling looked like. He worked under the assumption that everything had done up to code, which is the equivalent of relying on implementation details being done the right way. Sometimes double-checking and confirming can help tremendously …

It’s Christmas time. My yearly cookie baking event has been canceled this year due to a broken oven and delays in my house remodeling project. Thinking of recipes, it turns out that one of the missing items preventing adoption of system-level design is the absence of a canonical system-level flow, a pre-defined recipe how to get from an idea to hardware and software implementation. We are getting closer, but every customer I talk to has their own different system-level flow, which prevents scalability. As an added bonus for reading I will publish my favorite Christmas Cookie Recipe at the end of the post.

Flows are an interesting thing. From RTL to Implementation we now have arrived at a state that there are canonical flows. They can be automated. Users are automating them and they are generic enough that EDA companies help to automate them too, like in the case of the Lynx Design System. Are we there yet for system-level design? Not quite. Do we know the ingredients and part of the recipe? Absolutely!

Here is a simple flow diagram to go from “Idea” to “Product”. The first step is to figure out the architecture and the partitioning of hardware and software. As indicated in my previous post on Application Driven Design, in some application segments like wireless (iPads, iPhones, Droids etc.) software is king and the hardware is largely designed to optimize its execution. Still, defining a properly partitioned isn’t trivial. Ingredients for success are trace based analysis and models of the “system-to-be” which are independent from implementation. As an output of this phase we get specifications for hardware, software and their integration. These specifications can be executable, i.e. for the blocks this may be C code or graphical representations as used in model based design.

The hardware design phase is pretty well understood, especially once we have RTL. It’s lynxable so to speak. From the hardware specification the flow is all about blocks. There are various ways to get them, the two main categories are to reuse them or to implement them as differentiated blocks. That can be done by hand, as configurable processor, as custom coprocessor or via high-level synthesis. All these techniques have different advantages, but it is hard to completely automate the block creation flow. There is no pre-defined recipe.

Then the hardware and the software have to be integrated. First, the various hardware blocks need to be integrated. At the transaction level the integration can be used to create virtual prototypes to enable first interaction with the software. Once RTL is available, hardware based prototypes – FPGA based or Emulation – can be used, again enabling software execution. As part of the architecture exploration phase the interdependence of the block hopefully has been analyzed. The RTL can now be integrated and assembled, and finally be fed into the “lynxable” hardware implementation flow.

Now that I have written this it does not sound all that bad. However, only the ingredients are pretty clear, users will need “Block Design” with high-level synthesis and processor design, “Block Reuse” based on IP libraries, “Architecture Design” at the transaction-level and “Prototyping” using virtual and FPGA  prototypes. The recipe though, i.e. how they connect and how they are assembled within a flow, highly depends on application domains and individual customers.

When will we get there? There is hope. First incarnations of ESL flows are emerging, like the TSMC ESL Reference Flow. Once the ESL flows get to a state that we can create something like a Lynx Design System for them, we will know that we have passed this hurdle for adoption!

A recipe that always works: Nutty Christmas Cookies

And now to my favorite Christmas Cookie. Every year since my daughter has been two years old, the “Annual Schirrmeister Christmas Baking” takes place on the fourth Sunday before Christmas, in Germany we call it “1st Advent”. This year it has been canceled due to a broken oven, but just imagine 10+ kids unleashed on hand-prepared cookie dough. While the kids are more into shapes and sprinkles, the following cookie has become the universal favorite amongst friends and family. Enjoy!

Ingredients:

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

Recipe:

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

Happy Holidays!

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

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

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

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

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

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

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

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

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

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

Now that I am back from honeymoon, the obligatory post-honeymoon-email-catch-up-marathon and then some business travel, I find myself in lots of discussions around application domains and the specific characteristics how system integrators, chip vendors and software vendors interact. How can one visualize the interaction between the different participants in the design chain? Is it applications driving the hardware or hardware enabling applications?

One way to illustrate design chain interactions are the “ASV Triangles”, which Alberto Sangiovanni-Vincentelli created in the late 90’s while I was product manager in the Felix/VCC team. Cadence VCC of course is described in “A Prescription for Electronic System Level Methodology” as one of the “Trailblazer Projects”  for system-level design (Synopsys Behavioral Compiler being the other).

I remember seeing the original triangles sometime in 1999. The transition to platform based design was in full swing with platforms like Texas Instruments OMAP, Philips/NXPs nExperia and ST Microelectronics Nomadik under development. A hardware platform would be equipped with software APIs to allow application development to be relatively independent from hardware. This way video decoding was for example provided as a software API about which the application developer would have not to worry anymore. At the next revision the hardware provided underneath could change and as long as the API remained the same, application software would be compatible. This is illustrated with the upper set of triangles in the graph on the left. A range of applications can be mapped to hardware platforms with software APIs. Underneath different hardware architectures within a platform family support the applications.

This is where application specificity comes in because different application domains are driven by different requirements. The ITRS differentiates various product classes and design styles. They are SoCs, MPUs, Mixed Signal and Embedded Memory, with Networking, Consumer Portable and Consumer Stationary as sub-categories of SoC. In terms of driving markets the ITRS differentiates between Portable/consumer, Medical, Networking and Communications, Defense, Office and Automotive. In Networking for example it is all about increasing processing performance at constant die area, while in SoC Consumer Portable die size is actually shrinking and low power is the biggest issue.

As a result the ASV Triangles can now – roughly a decade later – be adjusted as I suggested in the lower portion of the graph on the left. The hardware platforms have become more programmable with multiple cores and software distributed among them driving the applications. The next step is to find application specific programming models which can be mapped from pure application design into programmable hardware architecture. This is what I would consider application driven design, in which hardware architectures enable different types of applications. Grant Martin and I wrote an article back in 2002 about the design chain effects called “A Design Chain for Embedded Systems”

Are we there yet? No. The time constants in the design world are pretty long and we are just now approaching mainstream adoption of the automation from the C-Level to hardware implementation. Virtual prototypes and architecture design as it stands today enable software driven development today, but it is largely manual, i.e. hardware platforms are provided as virtual platforms and software is developed on them after architecture decisions are made.

The next step will be to automate the partitioning of software across multiple cores – for which virtual prototypes already greatly help the debugging aspects today. However, completely automating the software partitioning is still some time away, even though the industry has figured it out for specific niches like HPC with technologies like NVidia’s CUDA.

As always – I am looking forward to your comments. It’s fun to be here in EDA. Times of transition are always offering many opportunities!

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.

By Johannes Stahl

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

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

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

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

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

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

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

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

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

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

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

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