‘Hug The Debug’ – Before It’s Too Late

Though the term “shift-left” originated in the software industry, its importance is often cited in the hardware (semiconductor) industry where the end-product (chip) costs are skyrocketing. The increase in cost is driven by a global chip shortage, especially in the automotive industry. Manufacturing a robust chip is a long, iterative process that may require many re-spins. Shift-left refers to finding and fixing bugs early in the development cycle rather than catching them during implementation where they are up to 100 times more expensive to fix. Leveraging shift-left in verification can result in less re-spins, more reliable products, faster time-to-market, and lower costs.

The process of shift-left comprises of two components: “finding bugs” and “fixing bugs.” The former is where verification engineers spend most of their time. Figure 1 shows recent data from the Wilson Research Group that highlights where engineers are spending their time. The graphic shows engineers spend the majority of their time in test planning, testbench (TB) development, running simulation, and debug.

Here is data from two sets of engineers:

Fig. 1: Where engineers spend their time. (Source: Wilson Research Group and Siemens EDA, 2020 Functional Verification Study)

On the left, you can see ASIC and Verification Engineers spend about 41 percent of their time doing debug. On the right, we see that for FPGA engineers the number is 46 percent. This data collection shows debug is critical to the success of any project.

The situation is even more significant for mixed signal verification. Customers integrating AMS blocks in their digital chip will typically have specialized analog design teams creating analog IP blocks or third party IP. These analog blocks are designed using schematics and SPICE and are verified as self-contained in a local testbench. These well-specified analog blocks are then delivered for top level system integration.

The system integrators may decide to use the analog IP in its pure transistor representation or may decide to use a higher abstraction of that block depending upon their verification needs. These abstractions could be either less accurate but fast Verilog or C models that are easy to integrate or could be more accurately represented in Verilog-AMS or VHDL-AMS, which is more complicated to integrate in the flow. Real number models (RNM) are becoming the new sweet spot in modeling analog blocks as they offer a balanced trade-off between performance and accuracy.

Real number modeling (RNM) is the functional modeling of the analog circuits or behavior in the discrete time domain. As you can see in figure 2, a true smooth analog signal can be approximately represented by a discrete step response. Being in a discrete time domain allows the model to stay in the 100 percent digital flow, allowing very fast event-driven simulation of the model that could be 10 times to 1,000 times faster than SPICE. There is no matrix to solve, which is typically the case in analog simulation. However, there are limitations on accuracy as this is just a transfer function modeling of analog. Also, frequency domain modeling of analog blocks is much more complex.

Fig. 2: Real Number Modeling.

So why model analog using real numbers? Why not use digital Verilog or register transfer level (RTL)? After all, top level SoCs are verified in the digital domain. SoCs have both analog and digital blocks, and the main challenge is the modeling of handshaking of information between these two domains. Based on Verilog/System Verilog abstractions, a wire is considered as a logic net and it only has three states (0,1, and X). It cannot capture analog functional behavior, which could result in a loss of information and eventually functional failure. You can see this in figure 3, where a logic wire cannot capture the real value from block A to block B. In real number modeling, real wires (wreal or SV nettype) can carry a real-number value that enables modeling of correct analog behavior (case 2 in figure 3).

Fig. 3: Logic wire versus Real wire.

The speed and accuracy advantage of RNM models assist the shift-left flow – verification can start earlier without finished schematics and models can be reused. The RNM model can also enable advanced mixed-signal verification such as with UPF and UVM. Lastly, since we are in discrete domain, only a single simulator – digital solver – is needed.

However, modeling with real number comes with a few overheads. First, designers must understand the correct functional behavior of the analog design and modeling it requires additional time and expertise. Second, checking model functional equivalency and simulation accuracy with schematic design is required.

RNM methodology is often very ad hoc. A good methodology improves quality and reduces debug. The three primary activities in RNM methodologies are: Build/update the model, Verify the model, and Use the model. This entire flow involves back annotation and optimization to improve the quality of models.

Fig. 4: RNM methodology.

The quality of the RNM model tells how close it resembles the true SPICE circuit behavior. Schematic versus RNM simulations must be checked constantly for functional correctness. Remember, a bad model is worse than a “no model.” The approach is to build a common testbench for the model and the schematic, provide the same stimulus to both blocks, run simulations, check the results, and modify or optimize the model.

Fig. 5: RNM versus Schematic – functional correctness.

Even after meticulous attention, bugs can creep in the RNM or mixed-signal verification flow. The bugs can be due to bad coding, such as illegal assignment. This is very common as RNM methodology and standards are still evolving. Connecting RNM modules requires a clear understanding of complex concepts such as SV nettypes and interconnects. Improper usage of these can result in functional failure. Bugs could also result from not properly verifying the model equivalency with the SPICE counterpart, or most commonly it could be because of the wrong use model.

Fig. 6: Typical bugs in the RNM methodology.

The wrong use model happens due to miscommunications within the stakeholders. Typically, the analog block designer shares specs with modeling experts and they create and test the model. They may use a separate testbench and may not have access to the top test bench, so functional failures are possible due to miscommunication between modeling and the system integrator.

For example, if the port orders of a block are swapped, a bug can get introduced during the integration of this block at the top level. The model expert and system integrator may be right within their own testbench environment; however, this scenario introduces a bug resulting in functional failure.

Fig. 7: Methodology induced bugs: “The Miscommunication.”

All these scenarios and complexities of issues happening at the analog and digital interface makes debugging a mixed-signal simulation a very cumbersome and tedious task. For decades verification engineers relied on a manual eyeballing of waveforms and traversing the source code to identify a mixed-signal bug. Such an approach can deeply impact the overall verification cycle and tape-out schedules, eventually delaying the time-to-market.

Siemens EDA’s Visualizer Debug Environment automates debugging for the digital design and verification of today’s complex SoCs and FPGAs. In addition to being very intuitive and easy to use, Visualizer has several powerful features that improve debug productivity for SystemVerilog/UVM, transaction-level, RTL, gate-level and low-power design. And now it is tightly integrated with Questa and Symphony mixed-signal platform to provide a full set of RNM and mixed-signal debug capabilities such as synchronized views, unified waveforms, and trace connectivity. These debug capabilities can improve productivity by up to 50 percent when establishing an RNM of mixed-signal verification flow.

The use of real number modeling definitely helps in the shift-left trend for mixed-signal verification. However, verification teams need to have a robust RNM methodology for building the RNM models, verifying them against SPICE, and correctly integrating them into the overall verification flow. Debug surely plays a critical part in improving the efficiency of production level deployment of this flow.

“Hugging the debugging,” or in other words establishing a robust debug methodology early on, can reduce wasted debug cycles and allow you to meet tape-out schedules and improve time-to-market. Meeting tape-out schedules will improve chip supply and assist the automotive industry, which is struggling with a global chip shortage.