Doing too much at once?

EDN welcomes Brian Bailey, an independent consultant working in the fields of electronic system level (ESL) methodologies and functional verification, to the Practical Chip Design blog. Brian has published six books, has four patents to his name, chairs standards committees, has produced educational courses, and has given talks around the world. He graduated from Brunel University in England with a first class honors degree in electrical and electronic engineering. Below is his first post for this blog. You can also find his work on EDN’s IC Design Center and the EE Times EDA Design Line.

Doing too much at once?

Sometimes you find recurring themes and once you recognize the theme you see more and more cases of it springing up. Several years ago I noticed how migration to the electronic system level (ESL) was stalling and I finally realized it was because the companies trying to break into the market were trying to do too much, too quickly. They wanted to create completely general systems before they really understood all of the requirements, and for that matter the potential users of the system didn’t know exactly what they wanted either. As an industry, we forgot to prototype ESL, instead attempting to go straight to product and I believe that has slowed down product adoption.

At DAC 2010, I gave a keynote address to an ECSI system-design workshop. I was talking about advances made over the previous decade and what I expected for the coming decade. I talked about the challenges that had to be overcome, including technical and organizational issues, plus fears about change at all levels. I talked about the merging of hardware and software, tools and IP, to the point where they become inseparable from each other. At the end of the presentation, I made some predictions. Here is prediction #1 exactly as I presented it:

Figure 1: Prediction made in June 2010

The reasoning behind this prediction is simple: if you constrain the problem in some way, then it is more likely that you will find a solution that satisfies a particular group of people. The constraint I identified was limiting the tools to working with a specified set of IP. I identified platform providers such as TI, or FPGA vendors such as Cypress or Xilinx. Since that DAC presentation we have seen Xilinx purchase AutoESL - providing the company with high-level synthesis and Cypress continuing to expand their set of design tools that are specific to its PSoC platform.

Another example of trying to do too much occurred in a standards group that I chair. As we addressed a specific problem that required a new feature, some members wanted to solve a more general problem and yet there was nobody actually asking for it. One group within the committee wanted the most general solution even if it took longer to create, while the other group wanted something that could solve the problems that users were facing today and keep things open enough for possible extensions in the future. Now we are stuck in a discussion about which of those is the right approach.

I recently spoke with Ken Karnofshy, senior strategist for signal processing algorithms at MathWorks. He talked about how the company prefers to concentrate on the problems faced by a particular set of customers and solve that more constrained problem, rather than trying to create a completely generic solution. He believes that most EDA companies create products that are, in general, overly complex. As a result of this more pragmatic approach, Ken believes that MathWorks is more likely to hit its intended target and at lower cost.

I also recently spoke with Mark Saunders, product marketing/applications manager - PSoC tools, at Cypress, which have just released version 2.0 of its PSoC Creator Design Environment. This was already a tool that merged the notion of tool and IP, and with the 2.0 release it has done that even more. The company has also started the merge between hardware and software, although this has a ways to go yet before I would say they are fully integrated. But let’s back up a bit.

PSoC is a programmable device family where each device contains a processor, some configurable digital parts and some configurable analog parts. All of these are stitched together by programmable interconnect. The goal of the Creator tool is to hide all of the implementation details from the user. In a BDTI study conducted in early 2010, back-end layout and route was the number one issue for flows based on FPGAs.

Hiding the back-end allows the user to think about the design and not the silicon or even the hardware blocks involved. It uses a schematic user interface and a simple intuitive configuration editor. The library currently contains 147 components and two or three new ones are added every couple of months.

In the 2.0 release they have also integrated Keil MicroVision, which enables device firmware to be created and built for the PSoC family and fully kept in sync with configuration changes made in the design. They see this as a very necessary step because the sophistication of these devices has gone from being a one-man show type design, so a group effort and this requires more co-operation and control of the data as it gets generated throughout the design process.