Transactional Level Modeling (TLM) of a High-performance OCP Multi-channel SDRAM Memory Controller

How the use of the OCP TLM SystemC library enhanced the design process of an OCP-based SDRAM controller IP, and dramatically improved the customer evaluation process.

Introduction

As a leading platform-based design EDA tools provider, Prosilog delivers a set of system IPs : Interconnect blocks for several SoC protocols (AMBA, OCP), general-purpose IPs (GPIO, Timer, Interrupt controller, UART), DMA controller, and memory controllers.
Particularly, Prosilog has developed high-performance SDR/DDR SDRAM multi-channel, multi-ports memory controllers. This kind of IP is used more and more in different types of high-performance platforms and the controller models need to be powerful, easily configurable and highly re-useable for best efficiency.

To match these criteria, the Open Core Protocol (OCP, developed and promoted by OCP-IP organization) was chosen to handle communication with the outside world, OCP being highly powerful and configurable.

OCP-IP has also developed SystemC transactional channels. They enable representation of OCP protocol behavior at higher levels of abstraction compared to RTL. At Prosilog, transactional memory controller models leverage this SystemC library for OCP communication. These models are part of a new methodology which reduces design cycle time, errors and hence time-to-market.

TLM-based verification flow

Usually, the IP design process jumps directly from the specification to the RTL coding stage. Functional verification follows, which may expose design errors, cause changes to the original architecture and re-coding of the RTL. This iterative process may be repeated several times before the design can be considered safe. Since RTL re-coding is a painful and time-consuming task, it heavily impacts the design cycle time.

During the SDRAM controller design, a methodology was introduced, which inserts an additional TLM modeling step before going to the RTL stage.

OCP TLM SystemC Channel

Within OCP-IP consortium, the System Level Working Group has released an OCP SystemC channel, at three levels of abstraction. Using OCP-IP terminology, these levels are called:

TL3: Message layer (highest and most abstract level)
TL2: Transaction layer
TL1: Transfer layer (closest to implementation)
RTL being called TL0 in this terminology

Each level suits different needs:

TL3 models untimed functionality and point-to-point communication
TL2 is timing estimated, enables to analyze/model SoC architecture and begins early SW development
TL1 is cycle-true but faster than RTL. It fits detailed analysis and low-level SW development

TLM Controller model

The SystemC model of the controller needed to be fast and cycle-accurate, so that it could provide relevant performance analysis and help to identify bottlenecks. As a consequence, Prosilog’s controller model was designed at TL1 level to achieve the following characteristics:

High-speed simulation
Cycle-accuracy

Thanks to SystemC/C++ capacity, high configurability could be easily obtained. For the controller, it concerns the following features:

OCP ports number
Arbitration scheme
Request and response buffer depths for each OCP port
SDRAM memory timings
Bank address mappings
Synchronous/Asynchronous design

As a consequence, functional verification starts at the TLM level instead of the RTL level. Its efficiency highly depends on the chosen abstraction. If the model is described at a high level, a lot of details of the future RTL implementation is not exposed and hence cannot be tested. In the SDRAM controller case, a TL1 model was chosen. As described before, this kind of model achieves cycle-accuracy, as the RTL one, exposing most of the pertinent micro-architecture features (finite-state machines, data and control flows) while hiding non significant details of the RTL implementation.

Thanks to the TLM model accuracy, most of the design errors can be detected during the TLM verification phase. Since the TLM code is more compact and readable than its RTL (VHDL or Verilog) equivalent, the recoding task which follows an error detection is easier and faster. Consequently, time needed to get a reliable, bug free functional model is significantly reduced.

Once the TLM model is stable, the RTL model can be coded accordingly to the TLM description. Of course, if the TLM model is described at a high level, RTL coding would be more difficult than with a more detailed transactional model. When choosing a cycle-accurate description, as in the SDRAM controller case, the RTL coding step is straightforward, since most of the complex part (FSMs… ) of the design is already precisely described in the TLM model.

After the RTL model is coded, it has to be functionally verified. Since almost all functional errors have already been detected and removed during the TLM verification phase, this step is very short. This was the case for the SDRAM controller, where all remaining errors were netlist-type errors, that were easy to detect and to correct. No critical error was found, and hence no major rewriting of the RTL code was needed.

Taking into account the time needed to develop the TLM model, the TLM-based verification flow leads to a 20% reduction in the time spent for the SDRAM controller functional verification process. Considering the weight of the functional verification step in the complete design flow (typically around 70% of the total design time), design modeling at transactional level proved to be significantly profitable.

OCP-based, multi-port SDRAM controller

The multi-port capability is one of the key features of our SDRAM controllers. It allows a shared access to a unique external memory resource between several concurrent IPs. These IPs can be processors, DMA controllers, bridges, that access directly to the controller via point-to-point links, or indirectly through interconnect devices (e.g. AMBA AHB/APB bus controllers, OCP interconnects, …).

The controller ports use the Open Core Protocol (OCP) to communicate with the outside world. Performance and reusability are the two main reasons that justify the choice of OCP, rather than another interconnect protocol. To maximize performance metrics, mainly bandwidth and access latency, the controller relies on the following features of the protocol:

Separate request and response handshakes
‘Single Request Multiple Data’ transactions
Posted Writes

The OCP protocol allows ‘plug-and-play’, point-to-point direct connections between native OCP IPs. Hence the SDRAM controller can be plugged into any OCP-based customer environment in a straightforward and reliable way, without any additional glue logic required. In the common case where the user platform also uses non-OCP protocol in some part of the design, communication with the OCP-based controller is implemented using a ‘OCP to XX’ protocol wrapper, where XX identifies the target protocol. Prosilog provides this kind of wrappers, that bridges the communication gap between OCP and the industry’s most widely used protocols, such as AMBA AHB/APB/AXI, CoreConnect OPB/PLB etc…

As shown in Figure 1, Prosilog’s memory controller includes several OCP 2.0 target ports. Each port handles memory read or write transfers to the external SDRAM memory, from OCP initiators which are connected to the controller. A dedicated ‘Arbiter’ block is used to select one request among several concurrent transfer requests. Eligible request is then transmitted to the SDRAM Controller management unit, that translates the memory request to the external memory according to the SDRAM protocol timings.

Figure 1 SDR-SDRAM Controller architecture

Customer Evaluation Process

Developing a TLM model not only enables to reduce the functional verification length but also enables to provide customers with efficient, fast IP-evaluation platforms based on the TLM model. Advantages of a TLM evaluation platform based on SystemC are numerous, both for IP providers and customers:

For an IP under development, the TLM evaluation platform can be delivered sooner in the design cycle than the final RTL model. Customers can start first evaluations and provide important feedback to the IP provider quite early. If initial specifications need to be changed, impact on the IP’s delivery date will be minimum, since changes would occur during the final RTL implementation. This kind of collaboration around a common evaluation model intensifies the customer/provider synergy, reduces the design cycle, lowers the risks of errors, for the common benefit of both parties.

Customer is able to get precise information about the real performance of the IP under evaluation without needing the complete RTL code. This information, extracted from TLM real-case testbenches involving the IP TLM model, provide more reliable and precise information than those found in a datasheet. Of course, relevance of the simulation results would heavily depend on the precision of model. For example, Prosilog’s TL1 SDRAM controller model is almost fully cycle-accurate, as shown on Table 1. With this level of accuracy, the customer is able to carefully evaluate the IP performance, in a real system environment.

Bandwidth per OCP port	0.5%
Average latency per OCP port	0.5%

Table 1 Cycle precision, RTL/TLM deviation

SystemC TLM simulations are faster than RTL simulations. As a result, customers can run very complex test scenarios while maintaining reasonable simulation length. For example, Table 2 compares the relative speeds of the TLM and RTL versions of the SDRAM controller. In this case, the TL1 model is approximately 15 times faster than the RTL model.

RTL	TLM
2.9	44.5

Table 2 RTL/TLM simulation speed (in kcycles/second)

The OSCI (Open SystemC Initiative) SystemC simulation kernel being free, no additional charges are needed to run SystemC-based TLM models. From the IP provider point-of-view, SystemC being a C++ library, protection of evaluation models is easy, through insertion of C/C++ license-based checking procedure.

TLM testbenches that were developed to evaluate the TLM model can be reused during the RTL verification phase, thanks to the use of TLM/RTL adapters. These adapters translate TLM test stimuli to their equivalent in the RTL world. Manual recoding of test stimuli in a RTL compatible language can be avoided by simply inserting a TLM adapter between the testbench and the RTL DUT. The SystemC OCP library includes two adapter families (TL2/TL1 and TL1/TL0), that allow simple and efficient testbench between the different abstraction layers.

This TLM-based IP evaluation procedure has been successfully conducted with several major customers.

Conclusion

Modeling at the transactional level has several advantages, not only for the IP provider (designers and verification engineers), but also for the users, which can evaluate the performances and the behavior of the IP very early in the design flow. TLM advantages are well known and being demonstrated today, but solutions and standards that relies on this methodology are just starting to emerge. OCP-IP consortium has released efficient and powerful libraries that can help companies willing to move smoothly into the TLM world. Prosilog has successfully implemented this TLM modeling approach for its latest IP developments and is making it available for its customers.

For more information, visit Prosilog at www.prosilog.com