Featured Articles

Protocol Abstraction Views Simplify Chip Interconnect Debugging

Imagine you just started to figure out part of a great mystery novel. You flip back a few pages to reconfirm a particular detail. Then, you leaf forward to find another clue, and suddenly…you’ve lost your place in the book. Imagine the mystery novel is about 100 times longer than War and Peace. This is what it’s like to replicate traditional debug methods for many of today’s complex communication protocols.

Anyone who has ever had to debug any type of pipelined design has suffered through this painstaking process. So you try to be really clever with multiple cursors in the waveform window. Then you carefully craft debug messages for fast regex matching in the log. But, eventually, you succumb to the cruel realization that a piece of scratch paper next to your computer is really the quickest way. Now throw in something like "out of order execution" and you start feeling dangerous urges to use dry erase markers on your computer screen. There must be a better way, right?

Somewhere along the way, someone took a step back and realized that we could separate the information being passed (e.g., address, data, and control) from the implementation details (i.e., pin wiggles). Transaction-level modeling (TLM) was born. TLM techniques are very common now for both modeling and verification, and, these days, most decent waveform viewers have some level of transaction viewing built-in.

Read the entire article from Mentor Graphics Corp. on SOCcentral.

Why We Need Standards for Transaction-Level Modeling

Transaction-level modeling has been touted to considerably improve productivity in system-on-chip design. Recently, many popular SOC development environments have been flavored with the spirit of TLM, typically based on the favorite design language for TLM, which seems to be SystemC. Indeed, TLM fabrics for SystemC spring up like mushrooms in the EDA community. The promise is that with transaction-level prototypes, buses and networks-on-chip (NoC) can be simulated magnitudes faster than with RTL models, while achieving almost the same accuracy of simulation results — and all this early in the design cycle where decisions made on these results have the biggest impact. But, does TLM live up to the hype?

To stand a chance, TLM engineers need to hit the ground running – they need their models to work fast. The common goal for the fabrics that are being offered is to ease the construction of model-to-model communication. The communication mechanism is seen as being relatively complex, common to many models, and above all, if it were common, then re-use of models might be possible. The key word is “interoperability.”

TLM designers are spoilt for choice. Reviews of TLM fabrics reveal a diversity of opinions about what a TLM fabric should look like, and each TLM fabric boasts another set of features and limitations. In an attempt to get a general idea of the status quo in transaction-level modeling, we consider three main aspects of TLM fabrics:

The API (“User View”). Supported levels of communication abstraction (“TLM View”). The techniques used for the implementation (“Technical View”).

Read the entire article from GreenSocs on SOCcentral.

Using SystemC Reference Models in SystemVerilog Testbenches

System-on-chip (SOC) verification has become more complex than ever as applications converge to offer more features for consumer products. This new level of complexity is presenting SOC development teams with many challenges including verifying their designs in a mixed-language and mixed-abstraction level environment while meeting compressed schedules. Two languages in particular are increasingly popular for SOC development: IEEE Std 1800 SystemVerilog with its advanced verification, modeling and hardware design capabilities; and IEEE Std 1666 SystemC, with powerful modeling features and tight links to the C/C++ programming languages. The challenge faced by many SOC teams is how to use these languages together for mixed-language, mixed-abstraction level verification.

Mixed abstractions come from the fact that designers often develop models at the transaction level to capture the correct architecture and analyze the system performance fairly early in the design cycle. Various components of an SOC developed with high level languages such as C, C++, SystemC, and SystemVerilog are increasingly in demand and for obvious reasons. They are faster to write and faster to simulate. These components are also known as high level reference models. Typically, they are used to capture design specifications early in the design cycle, and then refined to lower levels of abstraction required for synthesis. High level reference models became increasingly important in verifying the implementation details at the RTL level.

Mixed-language environments using SystemC and SystemVerilog are becoming more common due to the growing complexity of the verification challenge and the growing size of verification teams. Both languages are positioned to address the need to abstract the communication behavior and separate communication from control, hence, creating a true IP re-use environment for speeding up designs. SystemC and SystemVerilog are both suitable for writing efficient transaction level models. The use of either language depends heavily on the engineer’s background and expertise.

Typically, engineers with C/C++ expertise use SystemC for its natural extension to C++. The majority of these engineers would be the system architects and analysts. On the other hand, engineers with RTL and verification background tend to use SystemVerilog for its natural extension to Verilog. One common scenario is for SystemVerilog to be used for creating the overall verification environment, while SystemC is used for high-level reference models. This paper explores techniques for integrate a SystemC reference models into SystemVerilog verification environments.

Read the entire article from Synopsys, Inc. on SOCcentral.

Transaction-Level Modeling: SystemC and/or SystemVerilog

Today’s chip design requires extensive system-level simulations to ensure that the right architectural trade-offs are made. In most cases these simulations require that a substantial amount of software is executed on the simulation model of the chip to cover the required functionality. To perform these simulations with adequate performance, design architects increasingly leverage abstract, transaction-level models instead of RTL models to perform such analysis. This article takes a practical view of transaction-level modeling. It looks at two well-accepted design languages, SystemC and SystemVerilog, and explores how they support the concepts of TLM. It further explores how today’s verification tools can leverage the strengths of each language, and shows how a well-engineered transaction-level (TL) interface between SystemC and SystemVerilog offers a modeling solution today that can accelerate the adoption of TLM by providing portability and interoperability of TL models.

Read the entire article from Synopsys, Inc. on SOCcentral.

Advancing Transaction Level Modeling: Linking the OSCI and OCP-IP Worlds at the Transaction Level

The convergence of communications and multimedia data processing onto a single chip continues to push SoC complexity in two areas, SoC integration and software development. To address SoC integration issues, the industry has been moving towards standardizing the IP core interfaces to achieve high reuse. To address software development, the industry has been adopting higher abstraction simulation models which can deliver near enough performance and accuracy to enable software development to begin in parallel with chip development. While OSCI (Open SystemC Initiative) has focused on the software development concerns, and OCP-IP (Open Core Protocol – International Partnership) has focused on SoC integration concerns, the concept of Transaction Level Modeling (TLM) would most benefit from a methodology such that both standards can be utilized in a straight forward manner.

Using CoWare's ConvergenSC and Sonics' SMART interconnects, the two companies have designed such a common methodology which achieves the unified TLM goal. In this article, each TLM standard is discussed, followed by the interoperability work conducted between CoWare and Sonics.

Read the entire article from Sonics, Inc. on SOCcentral.

Rapid SoC Hardware/Software Co-Development Using Transaction Level Modeling

According to the market research company, International Business Strategies (IBS), the semiconductor vendors' system-on-chip (SoC) embedded software development effort has grown in absolute terms by more than 4x from the 250nm process node to the 90nm processes node, and now constitutes about 56% of the total SoC design effort. This growth in effort has proceeded despite the extensive re-use of legacy software intellectual property (IP), and demonstrates the extent to which new software IP must be developed to deliver the requisite SoC functionality.

This growth in effort threatens to adversely affect both the economics and the timely delivery of advanced SoC design. The design methodologies developed for earlier SoC technology are inadequate to the task of designing a multiprocessor SoC. Transaction level modeling (TLM) methodology has been devised to solve these problems. To understand how, we must first examine the major SoC design tasks to be performed before hardware implementation.

Read the entire article from CoWare, Inc. on SOCcentral.