Visual Architect and Development System for Architectural Exploration and Performance Analysis - CoFluent Design
[ Back ]   [ More News ]   [ Home ]
Visual Architect and Development System for Architectural Exploration and Performance Analysis - CoFluent Design


CoFluent Design provides integrated solutions to bridge the gap between the specification of an electronic system and its implementation. Its ESL modeling and simulation software environment allows developers of electronic devices and chips to:

- DECIDE: Securely predict behavior and performance from partial software and hardware for design validation at all stages
- SHARE: Provide system executable specifications rather than static documents for common hardware / software reference
- CAPITALIZE: Capture projects’ system design expertise

Before DAC I had an opportunity to interview Vincent Perrier Co-Founder and Director in charge of Products and Marketing and Hagay Zamir recently hired U.S. Business Development Director, in charge of developing CoFluent’s business in North America.

As the last executive to join the firm would you please provide us a brief bio?
I started working for CoFluent the beginning of the year. Prior to that I was working for a company called Summit Design on the architectural product line. I was a technical director for about 18 months. Before that I worked for a company from the middle of the 90s called CARDtools Systems on a product called NitroVP which was in the ESL space. I was working as an engineering manager and a business development manager. That’s my last 10 years of experience.

What attracted you to CoFluent?
That’s a very interesting question. I have been around for quite awhile. I have touched several different technologies that address the electronic system level design space. With CoFluent I found a unique approach to address the true gap existing between the specification and the implementation. The previous technologies I have been dealing with although under the same category of ESL were designed more to assist the implementation of the solution rather than making the correct decisions. That’s what I found to be the biggest differentiation between what had been available and what CoFluent’s solution is.

What challenges do you envision bring this product to the US? Are there any special issues because CoFluent is a European company?
I do not think that there are any issues because the company is located in Europe. It is a global market today. The challenge in brining the technology to the US is that we are usually late adopters of technology in terms of EDA, especially with SystemC. Because the underlying technology is SystemC and based upon that library and it is not fully accepted in the US, the challenge remains in educating the end user about the benefits for SystemC design which is widely accepted in Japan and is definitely far more in use in Europe than in the US.

Do you speak French?
No. I speak Hebrew though.
Vincent: We don’t.

I can not imagine a US company hiring a country manager that does not speak English. This says a lot about the education system of the US versus Europe.

Vincent, will you provide us a brief bio.
I am coming from an engineering background. I have a computer science engineering degree. Worked for 15 years in the software industry first as a real time software developer. Then I worked for a company developing software modeling tool and then for a big company, a leader in embedded solutions called Wind River Systems. I held different technical and marketing positions there. After that I created here in France. I studied with the professor who created this technology. This is how the whole story started.

That professor would be Jean-Paul Calvez of the University of Nantes?
Yes. Today he is our Chief Scientist. He is the creator of the entire technology with his research team at a university in a city in the west of France along the Atlantic coast.

Is that a some what typical evolution for technical companies in France? How common is this?
There are a few spinoffs from public research in France. That happens in some cases. You have spinoffs from research labs, one is very well known in the high tech area but we are not coming from that branch of public research.

Does CoFluent have the rights to the technology? Are royalties owed back to the university or the research lab?
We have signed an agreement with the University. We are the owners of the entire IP. We have a agreement for some time. There is a limited duration and a limited amount for those royalties. We fully own the entire software IP.

Was there a problem that Jean-Paul was trying to address or a technology he was trying to develop?
Actually, before the creation of CAD tools, the professor (let’s call him JP) started with some methodology work. He has more than 30 years experience in electronic design industry. He started with the first microprocessor. He quickly realized that the new technology required new methods and new tools to develop the processor and the software. He started working on this. Then as electronic systems became more and more complex, we started working on an entire hardware/software codesign methodology. This was first published in the 90s. It is called MCSE (French for Méthodologie de Conception de Systèmes Electroniques also know as CoMES – Co-design Methodology for Electronic Systems). There is a book available on this methodology (English version from John Wiley& Sons). His objective was always to provide the methods and tools to help engineers design the right product that meets the requirements and performance criteria. He started to pitch that methodology to students and to companies. The feedback was that the methodology is great but we need tools to support it. With his team he started to create a CAD prototype in the early 90s. When CoFluent began that was already a 3rd generation that went through several industrial tests and experience with several projects. It is a quite mature technology. This is where we are coming from. In the background is how to do codesign. We have joined the ESL bandwagon.

Would you provide us an overview of the product?
Vincent: The product is a visual architecture and development solution for architectural exploration and performance analysis. The idea with this tool is to get performance results out of the architecture very early in the design flow, the first 20% of the design phase when you need to make almost 80% of the decisions. We will get those results without requiring the writing of a single line of code or without integrating any IP or creating any SystemC models, although it is based on SystemC simulation.

The output of our tool is SystemC. We generate the SystemC. The input is graphical behavioral models and performance models. Out of this we are capable of modeling and simulating an architecture and studying its behavior in time and analyzing its performance with different resource loads and different traffic. We are also able to determine different metrics like cost and power consumption.

Is the simulator from CoFluent or from a third party?
The simulator is based upon the SystemC kernel. On top of that we have our own simulation library to support our modeling concept but the simulator is the OSCI (Open SystemC Initiative) simulator. The input is graphical notation and a few lines of C code. The SystemC code is linked to our simulation library and executed by the OSCI simulator. That’s how it works.

The CoFluent website references System Architecting and Time-Behavioral Modeling. Are these the product offerings?
CoFluent Studio is a tool set. We package those tools in different products. We have Time-Behavioral modeling to model the behavior of the system in an implementation independent manner. At this stage you do not know whether the functions you describe will be done in software or hardware. The idea is to get an executable specification of your application and to also specify the time requirements for different functions. This is Time-Behavioral modeling, a very simple behavioral model described by a network of communicating functions or classes. System Architecting is the second package. It includes time-behavioral modeling, we call it TBM. It provides in addition a capability to describe an execution platform for you system application and to merge the behavioral and platforms models to obtain an entire platform virtual system architecture. This is known as the Y design flow. Separate the functional view from the platform view and through a mapping operation you allocate the different computation and communication defined in the behavioral model to the resources that are available in the platform model. In this way you are capable of analyzing the execution of the application model and the performance of the platform model. For that you do not need an ISS (Instruction Set Simulator) or software code. You do not need TLM (Transaction Level Model) or SystemC IP. It is all based on a graphical behavioral model and performance model of the hardware.

 CoFluent’s Y Modeling Flow

I believe I saw where the product does not use TLM but another type of modeling.
Actually, out library is based on top of TLM. We have another layer on top of TLM but we are using the TLM concepts. We are providing a transactional modeling and simulation capability but at a different level than the one you find in other tools. Other tools are either cycle accurate or bus accurate. We have one abstraction level above. What we are doing is a type of message passing TLM, the equivalent of TL/3. Bus accurate is TL/2 and cycle accurate is TL/1. We are a TL/3 type of tool. What I call message passing is basically the functions in your model are just exchanging messages between each other in a very standard receive type of protocol. It provides very fast simulation and a lot of flexibility in architectural exploration.

How would you compare the CoFluent approach to the approach others have taken in the ESL space?
The others in the ESL space are co-simulating software with a model of the platform created by assembling various IPs, RTL or SystemC. For those tools you need IP for all the different parts. If you do not have those IPs, you have to write them. This takes time. If you do not want to write them, then you have to buy them from the vendors. That takes money. You also need an ISS model to execute the software code that you cross compile for the target processor. You need a lot of details and a lot of effort to get to you first simulation. At that point you do not have much flexibility left in terms of architectural exploration. You may be able to fine tune your platform here and there but the major decisions have already been taken. With CoFluent you do not need a single line of final software code. You do not have to bring in any RTL IP. We are not based upon ISS simulation. The system is very flexible. You can pretty much change any parameter in your system architecture very easily. The platform modeling is done in minutes or hours. The architectural exploration through the mapping tool is also done very easily through drag and drop operations, done in minutes. If for example you decide that instead of a function running in hardware IP or on a hardware accelerator, you want to move it to your CPU or a DSP, this can be done in 5 minutes. You do not have to reprogram anything or create a new model of any sort. It is just handled by the tool. The tool provides you the capability to explore the wide area of architectural possibilities.

After the user has finalized the decisions on what is to run on hardware and what is to run in software, what is the next step in the design process? How does CoFluent fit into the design flow?
What we have seen and what is our vision of system design is that it is not a sequential flow in the sense that you start with system level design and then go to hardware and software implementation. That is not how it works. In our opinion you have two parallel flows. You have the system level design flow that goes from the beginning to the end of the project. And then you have the software and hardware implementation flow that is done with the usual EDA tools and software development tools. We basically do not touch that flow with CoFluent. I would include in that flow any type of low level co-simulation tool that basically takes hardware RTL level platforms and co-simulates this with an ISS and software code. That in my opinion goes into the hardware implementation flow. With CoFluent the idea is to start very early with the first system architecting activity, right after the specification, to obtain the first executable specification and also the first test scenario, the first testbench for the particular system architecture that you define. Then to use this executable specification for driving the hardware and software implementation. Out of this you have a blueprint to help you do the hardware/software partitioning, to help you do block decomposition, to do software task decomposition, to analyze different interactions between different blocks and to have a blueprint for how to write the hardware and software components. We have the first specification for timing requirements as well as memory consumption and power consumption. We have the first views of CPU load, bus load in the system and the cost of everything. This becomes your reference model. But this reference model is not static, you do not forget about it until you reach the end of the project. You will continue to monitor, update and refine it along with the progress made at the implementation level. In the end you get a direct correspondence between the final hardware, the software system and the high level model of the system that you have created but at a high level description including very amplified requirements for timing and performance out of this you are now capable of extracting reusable components, system levels models into a library that you can use in the next project. Now when you start your next project, it will be easier and much faster to just take the components out of the library, assemble them and try new functionality. This is how we see the entire flow.

How did you verify that your modeling is correct?
We do have some cases where customers took existing designs, create a model and made measures. They got numbers within 5% of reality in terms of performance prediction as well as any type of timing requirement. This is very close. This is definitely at a high enough level to provide the capacity to make most of the decisions very early when you need to. Would it be hardware? Would it be in software? What types of load do I have and expect? What type of memory requirements?

When did the product first become available? What is the current version?
We came out with Version 1.0 sometime in 2004. Today, we are announcing V2.1. There will be a preview at DAC. Today, it is a quite mature technology, knowing the fact that we started with a 3rd generation out of the university. Version 2.1 represents a 4th generation codebase.

How big a company is CoFluent?
We are about 10 people.

How many customers do you have?
I would have to count them. I would say between 10 and 20.

Is there a particular end application for which this product is a particularly good fit?
We are working with semiconductor providers, terminal manufacturers, and equipment manufacturers with digital multimedia in the wireless and telecommunication industry. That is where we have most of our customers today.

What is the pricing for the products?
You have quite a range of prices depending upon node lock or floating and geographical options. It ranges from $12K to $150K.

So for $12K you have one module and for $150K all the modules?
$12K would be for a simple node locked license and the other price would be for all the modules with a floating license worldwide.

Is your sales model to sell direct?
Yes. We also have representatives in Israel and Germany.

How about Asia Pacific?
Not yet. It is coming, next in our agenda. Basically, Hagay was our first step for addressing the American market. Now we are thinking of the Japanese market. Something we can take care of in the coming year.

You have already explained the difference between CoFluent and other ESL offerings. Is there any other form of competition that you have encountered?
I would say that the competition is Excel spreadsheets. Today, system architects when they have to make the type of decisions we have been talking about very early in the design flow were until now using guestimation and Excel spreadsheet calculations. That’s not sufficient today. They need to get a dynamic view of the entire system including its application platform. Complexity is driving the adoption of this type of tool. With the complexity of today’s designs, a project can no longer afford to make its decisions on the basis of Excel spreadsheets. This leads them too often to wrong decisions and wrong directions that are very costly because as you know problems arising in designs are due to architectural and functional flaws, wrong decision taken early in the project, even before the hardware and software design has started. We are trying to address this particular problem area.

The high level appeal of ESL is very strong. As you have said, if you can detect a problem in the architecture upfront with minimal investment of time and effort, then you can reap substantial benefits. The payback can be enormous. It begs the question of why ESL has not been more successful than it has been. I can show you 20 year old slides from the mechanical CAE industry that shows this kind of potential. The appeal to C-level executive is clear.
Hagay: That has got to do with the challenge of adoption in the various markets. It is a very sexy message. It takes time to detach people from the traditional design flow to unleash the creativity that ESL can provide and take full advantage of it. What we find is that customers most of the time are driving full speed on their highway of design. They are in the process for years. They are successful in most cases.

Slowly they are adopting and taking more advantage of the promise of ESL. It is a process. It starts with education. This is how they teach system design today. I agree with you that you can find 20 year old things about this concept. In the last few years especially with the growth in the use of SystemC as a modeling language we are stepping up in abstraction and we learn how to take advantage of those system level capabilities. I am very hopeful in the next couple of years there is going to be a breakthrough in that area.

Vincent: You are right when you say that codesign is not new. Professor JP worked on this topic for almost 20 years. This is not new but what is perhaps new is the level of pain that the projects are under today. Until now they could be more or less successfully get to the end of the project with existing practices such as the Excel spreadsheet. But when it comes to SoCs going out to the marketplace today or very complex mobile terminals, it is becoming too complex for a human being to analyze the ins and outs of the different situations that the system could be in. When customers maybe five years ago would tell us that their architects are right 90% of the time with their decisions, now they are coming to us saying their architects are very often wrong because it is becoming too complex. The complexity is here. They do not have a choice but to adapt and embrace a new way of thinking about their designs and analyze the different situations and the different choices that are available to them in order to optimize the architecture and the products they will release. ESL is part of the answer to these problems. It is clearly illustrated by the various statistics that you find in the marketplace. You see that the most important problems are at the architectural level and functional level. They have moved from implementation related problems that were solved by the existing EDA technology to the earlier phases of design. This is the challenge of ESL to address.

The top articles over the last two weeks as determined by the number of readers were:

Cadence Design Systems Is Said to Be in Buyout Talks (New York Times)
Cadence Design Systems, one of the largest makers of the software used to design computer chips, is in talks with at least two buyout firms about a possible sale of the company, two people close to the matter said yesterday.

The company has held talks with Kohlberg Kravis Roberts and the Blackstone Group, and other suitors may emerge, those people said. But they warned that a deal may not happen because of the complicated risks in the company's business. Other private equity firms took a look at Cadence but passed.

Representatives for Blackstone, Kohlberg Kravis and Cadence declined to comment.

Extreme DA at the 44th DAC: It’s Time for a New-Generation of Timing Sign-Off and a Chance to Win an Apple iPhone! Extreme DA will provide informal demonstrations of its new GoldTime product featuring Extreme's new ThreadWaveTM technology for the fastest, highest capacity timing closure.

HP Unveils Print 2.0 -- a New Era for Printing HP is creating technologies to make it easy to print content from the Internet in a useful format. HP also has teamed with leading weblog software and services company SixApart, Ltd., creators of Movable Type, the world's most advanced blogging platform, to enable bloggers to add a "print" button on their blogs. HP also plans to introduce the Tabblo Print Toolkit, an embeddable website widget and corresponding web service that enables web designers to incorporate print functionality into new and existing websites. The toolkit is based on custom template technology developed by Tabblo, a company HP acquired in March.

HP has also added eight imaging and printing solutions to its enterprise portfolio targeted to customers in the higher education, public sector, retail, transportation/logistics and financial services industries

Avago Technologies Announces Second Quarter Fiscal 2007 Financial Results Avago Technologies, a supplier of analog interface components for communications, industrial and consumer applications, today reported financial results for its second fiscal quarter, ended April 30, 2007. Net revenue increased to $386 million, compared with $384 million in the previous quarter and $373 million in the same period a year ago.

Denali and Mentor Team to Enable Verification IP for SystemVerilog Verification Environments
Denali Softwareand Mentor Graphics announced the availability of Denali's PureSpec(TM) verification IP products that are integrated with Mentor's AVM (Advanced Verification Methodology) SystemVerilog environment. The integration is a result of a collaborative effort between Mentor and Denali to address the rapid migration towards SystemVerilog in their respective customer bases. Commercial verification IP products for AVM-based environments enable designers to more effectively use key SystemVerilog functionality, and drastically reduce verification cycle times for designs that incorporate standard interfaces such as AMBA, PCI Express, SATA, and USB.

Other EDA News

Other IP & SoC News