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.