Equivalence Check: Yosys Fails Despite Matching Simulations

by Dimemap Team 60 views

Hey guys, let's dive into a quirky issue I've been wrestling with: a situation where the equivalence check in Yosys is failing, even though the simulation results look perfectly fine. It's like the tools are disagreeing, and that's never a fun place to be! Specifically, we're seeing this problem when using a synthesis flow that incorporates Hypergraph Partitioning, a technique that leverages the KaHyPar library to break down a circuit into smaller, more manageable chunks, and then maps it under those partitioning constraints. When using the standard if command for synthesis, the equivalence check in Yosys sails through without a hitch. But, as soon as we introduce this hypergraph-based flow, boom! The equivalence verification throws a fit. Yet, the simulations run in Vivado, using the same testbench, show identical outputs between the pre-synthesis design and the post-synthesis netlist. This is a head-scratcher. Let's unpack this, shall we?

The Core Problem: Yosys and Hypergraph Partitioning

The crux of the matter is that Yosys's equivalence checker seems to be tripping up when it encounters the netlist generated by this hypergraph-based flow. The equivalence check, or equiv_status step, is designed to rigorously prove that two circuits (in this case, the original design and the synthesized one) behave identically. When this check fails, it means Yosys has found a discrepancy – a point where the outputs of the two circuits differ. However, the simulations, which use a separate method to verify the design's behavior, tell a different story. They show that the synthesized netlist functions exactly as expected, matching the original design's output for the same inputs. It appears that the equiv_status step is the one that is acting up.

This contradiction points to a potential defect in how Yosys handles the specific type of netlist generated by this hypergraph-based flow. Hypergraph partitioning, as you know, is a powerful technique for optimizing circuit design, especially for complex, large-scale circuits. By breaking the circuit into smaller parts, it can improve the speed and efficiency of the synthesis process. It's a technique that can be particularly effective in reducing routing congestion and improving overall performance. However, if Yosys's equivalence checker isn't properly equipped to handle the resulting netlist structure, this can lead to these false negatives. For example, the hypergraph partitioning might introduce some logic transformations that are valid but are not easily recognizable by the equivalence checker. Another possibility is that the partitioning process could introduce specific circuit structures that the equivalence checker doesn't handle correctly. The logs indicate that the checker found 4 unproven cells, which means that it failed to prove the equivalence of 4 specific signal points in the circuit. This failure is not a sign of the actual circuit's functionality, but rather a limitation or misinterpretation of the specific equivalence check process.

Dissecting the Issue: Logs and Symptoms

Let's get into the nitty-gritty of what's happening. After running the script, the equiv_status command reports failure. It states that it could not successfully prove the equivalence of 4 signal points. Here's a snippet from the log file:

Found 408 $equiv cells in equiv:
 Of those cells 404 are proven and 4 are unproven.
Unproven $equiv $auto$equiv_make.cc:257:find_same_wires$13615: \y_gold [136] \y_gate [136]
Unproven $equiv $auto$equiv_make.cc:257:find_same_wires$13613: \y_gold [134] \y_gate [134]
Unproven $equiv $auto$equiv_make.cc:294:find_same_wires$13410: \wire13_gold [2] \wire13_gate [2]
Unproven $equiv $auto$equiv_make.cc:294:find_same_wires$13408: \wire13_gold [0] \wire13_gate [0]
Found a total of 4 unproven $equiv cells.

These log entries show that Yosys's equivalence checker is unable to verify the equivalence of certain signals. Specifically, it's comparing signals in the original design (labeled _gold) with signals in the synthesized netlist (labeled _gate). The lines find_same_wires suggest that the checker is trying to locate matching wires in both circuits and then comparing their values. The fact that it can't find these matches indicates that the transformation or structure caused by the hypergraph partitioning is confusing the equivalence check. The log also points out the specific lines of code where the issue is occurring, which might be helpful for anyone debugging the code. The crucial point is that while the equivalence check fails, simulation in Vivado consistently validates the functionality of the synthesized netlist. This discrepancy is the core symptom.

The Implications: Trust and Verification

This situation raises some important questions about trust and verification in our design flows. Equivalence checking is a critical step in verifying the integrity of a synthesized design. It's designed to give us confidence that the synthesized netlist behaves exactly like the original design. If the equivalence check fails, we're generally led to believe there's a problem with our synthesis. However, in this case, the simulation results contradict that conclusion. The simulations give us a green light, providing evidence that the synthesized design is, in fact, correct. This situation has two key implications:

First, it suggests that the equivalence checker might be overly sensitive to the specific structure of the netlist generated by the hypergraph partitioning flow. This could lead to false negatives, where the check fails even though the design is functionally correct. Second, it means that we have to be careful in interpreting the results of the equivalence check. In this specific case, the simulation results are more reliable indicators of the design's correctness. That is because, the simulation is verifying the overall functionality of the design, whereas the equivalence check might be focusing on specific structural aspects that are impacted by the hypergraph partitioning. This highlights the importance of having multiple verification methods and cross-checking results. Relying on a single verification method can sometimes lead to misinterpretations or overlooking design flaws. Therefore, it emphasizes the need to review the results carefully, especially when using advanced synthesis techniques. It underscores the need for continuous improvement in tools and flows. As we integrate advanced techniques like hypergraph partitioning, we need to ensure that our verification tools can keep up. This includes validating the equivalence checker's ability to correctly analyze the generated netlists. Overall, this scenario encourages a comprehensive approach to verification. This approach should combine different methods to build confidence in the correctness of a design.

Potential Causes and Solutions

Let's brainstorm some potential causes and possible solutions:

  • Tool limitations: The equivalence checker in Yosys might not be fully optimized to handle the specific netlist structures generated by the hypergraph partitioning flow. This is particularly true if the flow introduces unusual or complex logic transformations. A future version of Yosys could be improved to better handle the netlists. This may involve updating the algorithms used by the equivalence checker, or providing some configuration options to optimize the check for certain flows.
  • Transformation ambiguity: The hypergraph partitioning process could be introducing logic transformations that the equivalence checker struggles to interpret. This could be resolved by modifying the partitioning flow to provide more guidance to the equivalence checker. For example, the flow could include annotations or additional metadata that help the checker understand the relationship between the original and synthesized circuits.
  • Incorrect constraints: It's possible that the equivalence check is not using the correct constraints for the synthesized netlist. Constraints specify which inputs and outputs should be considered during the comparison. Incorrect constraints could lead to the checker failing. You can check the constraints to make sure that they accurately reflect the behavior of the design.
  • Debugging and investigation: If you are encountering this issue, you need to provide detailed information, to determine the cause of the issue. You need to analyze the netlists generated by the hypergraph partitioning flow. Also, comparing the original design and the synthesized netlist to understand the changes made during synthesis. You might also consider experimenting with the equiv command and its various options to see if you can get it to pass.

Conclusion

In conclusion, we've got a curious situation on our hands. While the simulation results in Vivado confirm the correctness of our design, the Yosys equivalence checker is throwing up flags. This suggests that the hypergraph-based synthesis flow might be tripping up the equivalence checker. It is essential to rely on thorough testing and verification. Using a combination of tools and techniques to confirm your design's functionality is the best way to avoid potential problems. I hope this breakdown helps you better understand the problem. If you have encountered this issue, don't hesitate to dig in and make sure you have a complete picture of what is going on. Happy debugging!