September 12, 2005
Who Is Using ESL and Why?
Please note that contributed articles, blog entries, and comments posted on EDACafe.com are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
| by Jack Horgan - Contributing Editor
Posted anew every four weeks or so, the EDA WEEKLY delivers to its readers information concerning the latest happenings in the EDA industry, covering vendors, products, finances and new developments. Frequently, feature articles on selected public or private EDA companies are presented. Brought to you by EDACafe.com. If we miss a story or subject that you feel deserves to be included, or you just want to suggest a future topic, please contact us! Questions? Feedback? Click here. Thank you!
If these trends continue would you expect to see a step function in ESL adoption at some point?
I don't think that you would see a step function but a big ramp though. Once you get to a certain point where people adopt it as mainstream then you get a much bigger ramp up than we've seen so far. I think that's starting. We are starting to accelerate the adoption.
86% of the responders had no training in ESL. Does this present an obstacle to adoption?
Education is the key to the acceleration of adoption. It's partly due to the confusion that is out there as well. People don't know exactly how they are going to use ESL because there are so many mixed messages about what ESL even is. That's one of the things that's still a challenge for the industry. When you start getting some tools and applications where people are having some success, like the bomb detection example you wrote about with HiEngery, when people see that type of capability, they start to understand how ESL impacts them and their applications. You get more adoption and more clarity on what ESL is. At that point we will start to see methodologies come up and more
people will invest in training.
How is Celoxica itself doing?
We are seeing increased growth. This year we are going to be growing 50%. We are actually seeing that that to accelerate. The clarity is helping us out as people see what you can do with this stuff.
There a lot of different tools out there that fall into the ESL category. A lot of people are claiming to be in the ESL marketplace causing confusion about the definition and benefits of ESL. There are a lot of different tools that fall into ESL the way Gartner defines it. It's a little confusing as well because they have different categories and then they have the “other” category where a lot of these tools fall. It comes down to the way they define it. The way I prefer they define it is that you have the behavioral level ESL, the architectural level ESL for algorithm development and implementation on hardware and software sides which ties ESL to the existing
implementation flows that exist in the embedded world and in the EDA world. In all three of those categories you have two different methodologies that someone could follow, either a language based methodology using C, C++, or System C basically using code or an IP block based methodology where you take existing things that are already designed whether they be behavioral models, DSP blocks that MathLab provides or blocks of transactional level models in your architectural analysis or blocks of RTL code that IP developers produce. But an IP based flow that could be used at the system level. Once people understand those different capabilities and all those categories, then the tools start
to make sense. For example, the things that we do help you do algorithm analysis for architectural level supporting splitting between hardware and software at the architectural level. Then our C synthesis ties it down from that level into the EDA hardware development level. Those are the connections that our tools make. There are other tools for example a company called Catalytic Inc. that started off translating from floating to fixed point on top of MathLab currently trying to behavior algorithm level where you are trying to get ready to go to implementation. But it doesn't compete with us. It's pretty complementary to what we do.
There are any number of examples that are really complementary but because there is no defined flow, people are having to put that together in their own mind or even worse you have a lot of marketing groups out there pushing their own solution as the only one necessary for ESL and people get confused. I think by having some concrete examples like HiEnergy where you can see this is what we did. You had an algorithm that was running on a processor and for a number of reasons they needed to run this on an FPGA or a portion of it on an FPGA. We provided the board, the C Synthesis and the algorithm capability. That gives people something concrete. “Oh, my designs are like that. I
could use that in the same way.” The more and more those happen, the easier it is for people to adopt. We are seeing that in our business where it used to like pulling teeth to get people to meet with you. “ESL, that's like back magic.” Now they actually call us and we get meetings with them. That doesn't always mean that they will buy immediately. There are a lot of people in the survey that are in the evaluation phase, in fact 27%. It's a lot nicer to know that people are calling us to say we need to evaluate your tools because from there I know that we can show value and that our business will eventually win.
Could you name a couple of “ESL” vendors doing similar things?
One of the ones that competes with us would be Mentor's Catapult because they do C based synthesis into FPGA. We think they've missed the key point here that 40% of the people in this survey are not hardware engineers. Mentor is part of the Innovator's Dilemma in any industry. Their customers are hardware people, they are EDA people, and they have CAD departments. They buy tools based upon the CAD budget that Mentor negotiates with them every year. That means they are missing 40% according to our survey. In our business we see 80% coming from those people. They are missing 80% of the market because they don't provide a solution that meets the needs of the algorithm developers going
into an FPGA solution. So while they are a competitor we don't see them in most of our accounts because they don't have the full solution that our customers need. Again in the large scheme of things in the industry, they are out there. It confuses things, it muddies the waters.
There are a few others on the System C side. We compete directly with Forte. Again they tend to be more oriented toward the ASIC engineers than systems and software people. So we don't see them very often. When we run into that group of people with out system engineer working off System C we will see them. There are some firms that actually get it but they are very small, like Impulse C and Mitriant. They understand the broader market. They are going after the algorithm designers, the system designers. They're very small. The advantage we have over them is basically 10 years of developing our tools go back to the Oxford days that and three years of product selling and we have a big
install base. From that install base we have lots of experience in what you need change and what you need to add to the tools to have a very complete solution.
Do you compete with or complement MathLab?
Right now MathWorks is basically an algorithm analysis tool that works at the behavioral level. It doesn't get into architecture or implementation. I think that they have designs on moving into that space. They certainly have some partners that help them move into that space, people like Accel Chip. However, we don't usually see them as direct competitors because MathWorks itself is at the behavioral level. A sizeable percentage of our customers start off with MathLab and move into C code for implementation. Right now we see them as complementary.
Lack of training! You would expect most new engineers would be well versed in C. What additional training do they need? How much and who will provide it?
Right now the training that is out there is just tool training. It's related to one particular tool and how to use that tool. We certainly provide that around our tools. I think we are going to have to give broader training on the use of C based languages. I think with any design tools you end up first with tool training, tool specific design flows and methodological training, generically how to use System C to model the behavioral level and then from that into the architectural level and finally into implementation. It will take time. It will be driven by standard bodies and system houses and customer demand. Right now we
are in the early days. If you want a System C course, you are going to have to go to a specialized system training house that's going to charge you $50K to $60K for a training course which means it's only affordable for people who are really motivated or have made a decision at the corporate level to support this. Until there's more adoption, there won't be majority market price range. Once more and more people are using System C then the training classes will be available and we will be able to operate at price point.
You can find the full EDACafe event calendar here
To read more news, click here
-- Jack Horgan, EDACafe.com Contributing Editor.
Be the first to review this article