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.
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
Q: How do your models
work with the Cadence C-to-Silicon Compiler?
A: We can create SystemC models that can be synthesized
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.