Analysis of the three key points of the waveform system

In chip functional verification, simulation waveforms have always been an important means of debugging. By observing and analyzing waveforms, engineers can infer whether the code is running normally, whether the circuit functions correctly, and whether the design meets expectations. Waveforms solve the problem of observability in chip verification and debugging. Although relying solely on observing waveforms is not enough to solve all debugging problems, waveforms are a basic means. Many FPGA and hardware design engineers regard simulation waveforms as oscilloscopes or logic analyzers for hardware debugging.

Waveforms in digital circuits are usually represented by four-valued logic, including: 1 - high level, 0 - low level, X - indeterminate state, Z - high impedance state.

Of course, in order to reduce complexity, some simulation systems simply ignore indeterminate states and high-impedance states and only use binary logic representation. The waveform system displays simulation data in a visual way. Advanced waveform systems require more functions, including the display of protocol transaction level, mixed signals, file input and output (File I/O) and other functions. Most of the current EDA vendor tools embed waveform systems in various simulators and debugging tools, making them a closely integrated part.

There are many waveform formats in the industry. In addition to VCD, which is an open standard format, other commercial formats have their own characteristics, and each has its own advantages and disadvantages in performance and function. At present, the most commonly used tool in the industry is C2, which has a very efficient data compression rate and a very friendly user interface. However, data loading is still a little slow in large designs, and the underlying optimization needs further improvement. The C1 tool is slightly complicated to operate, and there is still a lot of room for improvement in the ease of use of the human-computer interface. The B tool is average, and it and the A tool cannot compare with the C2 tool in terms of data compression rate. The following table lists some of their respective characteristics.

The waveform system is crucial in chip verification. When design verification engineers use waveform debugging, they have high expectations for EDA tools and put forward many specific requirements. This article will explore the three key technologies of the waveform system. Through understanding these specific technical details, engineers can have an in-depth understanding of the performance and ease of use of the waveform system, so as to make better judgments when selecting tools in the future.

An IP may contain tens of millions of signals, and the amount of data generated by these signals over time is huge. If the waveform system does not effectively compress the data, but simply records the waveform data over time, the final amount of data will be huge. Even with the current decreasing disk prices, such a large amount of data is unacceptable for debugging a complex IP or SOC. A huge waveform not only poses various challenges to the disk space, but the biggest problem is the efficiency of the debugger calling this data.

The most commonly used waveform open standard in the industry is based on the VCD (Value Change Dump) format, which is based on the IEEE1364 standard, that is, a data format for storing waveforms in text format defined in the VerilogHDL standard. This format mainly records the name of the waveform, the time point corresponding to the value change, and the value change amount. Its core idea is to only record data and time points when the Value change (VC) occurs, and not to record anything when there is no VC.

Since it does not need to record the waveform value at each time point, it has a certain data compression effect in a sense. However, even so, the size of the VCD file generated in a complex IP may exceed hundreds of GB. Since it is a text data format, the tool is not efficient in reading file index data. Therefore, using VCD for waveform debugging in large designs will encounter many performance bottlenecks.

Each major EDA commercial company has its own waveform format. Although the specific standards are private, they are generally based on a database to store and manage waveform data. These data are not only stored, but also further compressed and optimized to reduce disk overhead and allow tools to read and manage data more efficiently. Since waveforms are an important tool for debugging, each major EDA manufacturer has compression technology for waveforms and has optimized the graphical waveform interface of the debugger to facilitate user use and maximize debugging efficiency. However, in addition to the key compression technology, another important feature for the tool is memory management technology.

The memory management technology of a debugging tool determines the usability and ease of use of the tool. In the current field of simulation technology with large amounts of data interaction, excellent memory management technology is crucial for tools. Simply put, memory management is the tool's need to find a balance point or optimal ratio between data placed on disk or in memory.

If too much data is stored on the disk, the tool will be very slow every time it loads the waveform; if too much data is loaded into the memory, it will cause memory explosion, making the entire server run slowly, which will also lead to reduced efficiency and user experience.

There is a joke that a project manager specifically requires engineers to start loading waveform debugging at 12 noon. During the loading process, the memory is basically exhausted and the server cannot do other things. After lunch and a break, the tool completes the waveform loading and the engineer can start debugging by looking at the waveform, thus avoiding wasting time. Although this joke does not stand up to careful scrutiny, it reflects the defects and deficiencies of some tools in memory management, which will lead to serious performance problems and reduce user experience. In any case, a good debugging tool must solve or avoid these problems.

In addition to the underlying core technologies mentioned above, the waveform tool technology itself must have several key application-level technologies: efficient cooperation with the simulator, and the representation of scenario-level and transaction-level operation types. Although the waveform reflects the signal changes within the design very intuitively, the design itself is RTL, and the signals are interrelated, so debugging cannot rely solely on observing the waveform. In many cases, engineers need the cooperation of the simulator to make debugging more effective.

After the RTL and testbenches are running, they are actually very similar to the running process of general software codes. Many engineers also hope to understand the execution of the code when observing the waveform changes; similarly, in the process of code debugging, it is often necessary to understand the execution process of the code and the corresponding signal changes. At this time, the single-step dynamic debugging of the simulator can be combined with the waveform changes, and engineers can intuitively understand the execution process and signal changes of a certain section of code. This method similar to software single-step debugging is also one of the commonly used methods in chip verification.

Signal driver tracing is a commonly used debugging technique that queries the driving source of a signal. When the user finds that a signal has a problem at a certain moment on the waveform interface, the user can trace the driving source of the signal. This debugging is similar to the effect and cause deduction process, which greatly enhances the effectiveness of debugging. Usually the source of a signal may not be single but multiple. The user can choose to observe multiple sources on the waveform interface, or choose to observe using code or schematic methods through the cooperation of the simulator and debugger. This signal tracing technology requires the organic combination of simulators and debugging tools, and the underlying layer also needs the support of an efficient database.

Transaction Viewer. It is very difficult to clarify the true meaning of data in a large number of signals in a complex design. Users often need to refer to the changes in the quantities of dozens of signals to determine the data type and operation. For example, an AXI protocol read and write operation may involve more than 20 signals. To complete a read and write, the user needs to observe the changes in a large number of signals over a period of time. This operation is inefficient and not conducive to a long debugging process. Transaction viewer can provide a higher-level perspective in the graphical interface, allowing users to intuitively understand the data types and definitions of these transactions without having to analyze data from the bottom signal. With this tool, users can quickly analyze debugging data, including enum type, class based transaction, sequence item, etc. Of course, to achieve a transaction visualization, it still requires the cooperation of the simulator and some additional work in the code, such as using verification IP (VIP) or describing it in a high-level modeling language such as SystemVerilog.

The waveform tool is different from other verification tools. It is a graphical interface that frequently interacts with users. These interactions are reflected in the user's mouse and keyboard operations and long-term visual observation of the graphics. Like most commercial software or mobile apps, this tool requires users to operate and interact for a long time. User experience has become a crucial factor in the waveform tool. User experience is generally referred to as the fluency and ease of use of the tool. The speed of loading waveforms, the response of waveform window zooming, the correspondence between code and waveforms (cross-probing), waveform comparison and merging, etc. can all be regarded as the embodiment of the fluency of the tool.