Get email delivery of the Cadence blog featured here
SystemC transaction-level models (TLMs) are great for architectural exploration, but what do you do if you don't have all the models you need? CoFluent Design, a Cadence System Realization Alliance partner, offers an alternative with CoFluent Studio, a product that automatically generates SystemC TLM models from graphical input.
CoFluent provided details about its solution in a Nov. 17 Cadence System Realization webinar entitled "Creating the SystemC Models You Need But Don't Have." In the following interview two CoFluent co-founders -- CEO Stéphane Leclercq (right) and CTO Vincent Perrier (below, left) -- answer questions about the company, the product, and CoFluent's role in enabling EDA360 System Realization. Meanwhile, CoFluent has posted a whitepaper on its web site that explains the company's role in EDA360.
Q: What is CoFluent's mission?
Stéphane Leclercq: CoFluent provides system-level modeling and simulation tools to accelerate innovation in embedded devices. Our product, CoFluent Studio, takes in a UML [Universal Modeling Language] notation, or our own graphical notation, and outputs SystemC models.
Q: Who uses the product, and how?
Vincent Perrier: Hardware developers, software engineers, and system architects use it. The product can be used in three ways. First, it can describe a functional model of hardware IP. If you have a piece of custom IP, you can generate a transaction-level SystemC model from a graphical description. A second use model occurs when you want to exercise the model with a workload, which could be a model of end-user software or any sort of application. The third type of use model is more on the architectural side. Here, you study how a multi-core or multi-processor application can be optimized, create models, and do architectural exploration.
Q: You also have a free product called CoFluent Reader. How does it compare to Studio?
Vincent Perrier: Studio lets you edit models, capture models, generate SystemC, and run the simulation. Reader is just for viewing the models. You don't edit anything, you just load existing models. It is basically for sharing models from different groups or companies.
While Studio is licensed, Reader is free. With it you can obtain models from anyone who has created them, look at the models, and run a simulation. It's like Adobe Acrobat Reader. The main goal is really to facilitate a sharing of information. Instead of a static specification or XML, a company can provide models for the reader.
Q: You've been in the ESL market for some time, and that was slow growing for quite a while. What are you seeing today?
Stéphane Leclercq: We have focused our efforts on the consumer electronics market, and more recently in the automotive and military/aerospace with the adoption of UML. We see a trend where the market is growing. There is also growing demand for an ability to handle multi-core systems.
Q: Is CoFluent Studio aimed at creating models for virtual platforms for software development?
Vincent Perrier: No, we create more abstract models. But we do have customers who create IP models or workload models to drive their virtual platforms.
When you are at the point of creating a virtual platform, you have pretty much created everything in your architecture, and you are fine-tuning here and there. The CoFluent tool is for much earlier, and much more in-depth, exploration. It's used before the hardware/software partitioning. It allows you to do any sort of exploration. You can look at what happens if you run everything in software or everything in hardware. You can try one core or two cores, one bus or two busses - it is very easy to do that kind of exploration.
Q: So, you automatically generate SystemC models from graphical input. How much time does that save compared to hand-coding the models? And how does the quality compare?
Vincent Perrier: We've done some experiments with customers, and found that it saves 5X to 10X compared to hand-coding. To judge the quality of the model, you have to judge what you want to obtain from the model. You don't need a very detailed model. You have to adapt the model to your objective.
Q: Do you generate OSCI TLM 2.0 models? These aren't synthesizable, are they?
Vincent Perrier: Yes, we use TLM 2.0. We have our own modeling library on top of TLM, and we provide ways to connect to either AT [approximately timed] or LT [loosely timed] models.
TLM 2.0 is not synthesizable, but we are working on a prototype for a SystemC generator for high-level synthesis. We will need a different generator for that.
Q: What did you present at the System Realization webinar?
Vincent Perrier: We explained how you can easily create a graphical model of a functional-level IP block, and then generate SystemC for this IP and connect it to a UVM [Universal Verification Methodology] or OVM [Open Verification Methodology] based verification environment. The idea is to create a testbench in SystemVerilog and hook this testbench up to a SystemC model using the DPI [Direct Programming Interface].
Q: How does CoFluent fit into the EDA360 vision?
Vincent Perrier: I think we are very well aligned, especially with regards to early system modeling and analysis, and taking into account the application point of view from the beginning. With CoFluent Studio, you create an application model, and you try to find the best fit in terms of platform in order to deliver optimized performance for this application model.
To read the whitepaper "CoFluent and EDA360," click here.