Home > Community > Blogs > Industry Insights > circuitsutra q amp a what it takes to develop systemc tlm models
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

CircuitSutra Q&A – What It Takes To Develop SystemC TLM Models

Comments(0)Filed under: Industry Insights, ESL, SystemC, High-level Synthesis, TLM, TLM-2.0, virtual platforms, virtual prototype, EDA360, system realization, CircuitSutra, Sisodia, Circuit Sutra

SystemC transaction-level models greatly speed design and verification, but they're not easy to develop. CircuitSutra (Noida, India) is a Cadence System Realization Alliance partner that provides SystemC modeling services for virtual platforms, high-level synthesis, and verification. In this interview Umesh Sisodia, CEO at CircuitSutra, describes what's involved with SystemC modeling and what the challenges are.

CircuitSutra will discuss the role of standards in TLM-driven design in a System Realization webinar presented by Cadence Sept. 15, 2010.

Q: You provide SystemC TLM SoC modeling services. What are the models used for?

A: Our modeling expertise spans virtually all aspects of ESL design. We create untimed or loosely timed transaction-level models for embedded software development, synthesizable models for high-level synthesis, approximately-timed models for architectural exploration and performance analysis, and cycle-accurate models for RTL verification. We also create bus-specific adaptors and transactors that make it possible to mix models created at different abstraction levels.

Q: What steps do you go through to create SystemC models?

A: We start with the specification for the IP, but that alone is not sufficient. We also have to know the purpose for which the model will be used, and depending on that we decide at which abstraction level the model will be created. If the model will be used for embedded software development, for example, then we need to create a register-accurate model, but the model can be untimed or loosely timed.

Once the abstraction is defined, we create a high-level block diagram of the model that shows how it will fit into the whole system. Communication is kept separate from core functionality to support maximum code reuse when the model is refined to another abstraction level. We then create standards-based models that can fit into any ESL tool environment.

The next step is to develop the model according to the specification and verify it. We create the unit test cases to verify the model and monitor standard quality metrics such as code and functional coverage. We also test the model by integrating it into a reference virtual platform. Final testing is done after integration into the customer's ESL environment.

Q: What steps are involved in creating a virtual platform for a customer?

A: First we develop the SystemC TLM 2.0 models of the individual IP blocks of the SoC, and integrate these with the processor model. The next step is to port the embedded operating system to the target SoC architecture. This may also require the development of device drivers for specific IP blocks whose drivers are not present in the kernel. Once the operating system is ported and running, the virtual platform is ready for embedded software development.

Most of the time we use a standard reference board as a starting point for creating the virtual platform of an SoC. We create IP models one by one and integrate them into a reference board that is already up and running. And wherever possible, we create interface IP models that connect with the real hardware interface of the host computer, such as a USB port.

Q: Why do customers work with you, rather than creating their own models and virtual platforms?

A: Our customers work with us because of our expertise in SoC modeling. We have in-depth understanding of modeling standards such as SystemC, TLM 2.0, STARC TL guidelines, OCP-IP, and others. Most of the models we create are the property of the customer. Our team acts as an extension of the customer's team, providing them with complementary skills and scalability without increasing their fixed cost.

Q: What are the biggest challenges in creating SystemC TLM models?

A: One challenge is to create the verification environment for testing the models. If the same IP is modeled at different abstraction levels, different test cases will be required to test the model at those different abstraction levels. Creating these different sets of test cases is a very non-productive approach. The TLM-driven design and verification methodology that has been proposed by Cadence solves this problem, because the same test cases can be refined further to verify the models at different abstraction levels, including RTL.

There is no standard definition of SystemC abstraction levels. The OSCI TLM 2.0 standard provides loosely-timed and approximately-timed modeling styles, but they do not provide definitions for the abstraction levels. Some standardization work is required in this direction.

Q: You're part of the System Realization Alliance. How are you planning to work with Cadence?

A: Our SystemC TLM 2.0 expertise fits very well into the TLM-driven design and verification methodology proposed by Cadence. We are developing expertise in Cadence tools and we can help mutual customers ramp on those tools. We have also provided some models that can be integrated with Cadence tools in customer demonstrations.

Our ability to create virtual platforms of SoCs makes us the ideal long-term partner for SoC companies. That fits perfectly into System Realization as defined in the EDA360 vision paper.

Q: How do your models work with the Cadence C-to-Silicon Compiler?

A: We can create SystemC models that can be synthesized using C-to-Silicon Compiler. We can create the bus-specific transactors that fit into the C-to-Silicon Compiler flow. The customer can simply use the TLM interfaces in their models, and C-to-Silicon Compiler will use the appropriate transactor to generate the pin-level interface.

Q: What's your impression of System Realization as described in the EDA360 vision paper?

A: Modern semiconductor chips are no longer discrete components - they are complete computers in themselves, often with multiple embedded processors. The functionality of these chips is not defined just by their hardware design. The software and applications that run on these chips is an integral part of the functionality.

Traditional methods of chip design are not sufficient for designing these chips. The application-driven System Realization approach advocated in the EDA360 paper is the right way to go.

Richard Goering

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.