Home > Community > Blogs > System Design and Verification > modeling interfaces with c to silicon compiler4
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the System Design and Verification blog (individual posts).


* 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: *

Modeling Interfaces with C-to-Silicon Compiler

Comments(0)Filed under: System Design and Verification, C-to-Silicon, SystemC analysis, CTOS, TLM 2.0, modeling, high level synthesis, transaction level modeling, dma, hls

Users of ESL tools are curious about the procedure for handling the interface to a bus or other communicaton protocol in a High Level Synthesis environment. This is usually formulated in the following question:

“How do we take into account the interface to the bus/processor for a piece of IP going into C-to-Silicon Compiler?”

There are two ways of addressing this issue using CtoS.  The first option is to model the interface at the signal level using sc_signals.

For example, a simple request-acknowledge interface would be written as follows:


while (acknoldege.read()==0) wait(); // wait until acknowledge.

      in = input.read();


A more complicated interface, for example a DMA transfer, would be similarly written:


while (acknoldege.read()==0) wait(); // wait until acknowledge.

      address = 0;


      for(i=0;i<N;i++) {

         // Loop as many samples as the DMA read requests


         data[i] = data_bus.read();


      ... process the N samples of read data


For a higher level of abstraction and for faster simulations the interface can be described using Transaction-Level Modeling (TLM).

When Transaction Level Modeling is used, the signals are abstracted away and I/O operations are performed by passing pointers or using function calls (Transactions). By doing this, there is a decoupling of the algorithm with the method it uses to communicate to the external world. Not having an interface “hard wired” in the design makes the design more flexible and re-usable.

CtoS supports synthesis of Transaction Level Modeling (TLM). Also, synthesizable TLM models of common bus protocols are available. The details embedded in these models provide CtoS the information necessary to synthesize the signal-level interface for the generated RTL from the High Level System C code.

It is important to emphasize that, in CtoS, both the algorithm as well as the TLM or signal based interface are described in a High Level Language (System C).

Less Effective Interface Synthesis
Rather than synthesizing an interface from a High Level Language such as SystemC, other technologies, such as pure C/C++ High Level Synthesis tools, decouple the algorithm from the interface by writing the algorithm in a High Level Language such as C++ and instantiating the interface from a pre-written menu of interfaces written in Verilog or VHDL.

This approach has the following disadvantages:

  • Only the algorithm and not the interface are written at a high level.
  • The algorithm and the interface are designed in different programming languages.
  • There is a substantial amount of overhead in incorporating the low level (Verilog or VHDL) interface into the High Level Synthesis environment.
  • A simulation which includes the interface can only be performed using low level RTL which is inherently slower.

Since the approach followed by CtoS does not have these disadvantages, I believe that CtoS’s approach is superior to a mixed C/C++-RTL interface synthesis approach.


This Team ESL posting is provided by Dr. Sergio Ramirez, Sr Staff Product Engineer for the C-to-Silicon Compiler high level synthesis product. Product Engineer for the C-to-Silicon Compiler high level synthesis product.


Leave a Comment

E-mail (will not be published)
 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.