Author Name: Jeremy Bennett (@jeremybennett)
Original Redmine Issue: 651 from https://www.veripool.org
Original Date: 2013-05-23
Original Assignee: Jeremy Bennett (@jeremybennett)

We've recently run into a design where the choice of GCC version when building Verilator, causes different behavior in generated models. In particular we have one design, where a Verilator compiled with an old GCC 4.1 generated a model which would not work, while the same Verilator compiled with GCC 4.7 generated a model which worked without problem.

Key to this seems to be the C++ STL std::sort() method. This is not guaranteed to be stable, and thus may give different results between different releases of GCC. Replacing this by std::stable_sort() throughout fixed the problem. Verilator compiled with GCC 4.1 and GCC 4.7 both generated working models from the design. As it happens this also increased Verilator's performance.

This suggests there may be some hidden assumption on the stability of sorting within Verilator. In this particular case, it seems the sort in the linkcells step is the one that matters. Unfortunately the examples are all in large confidential designs, and so far we have not been able to reproduce the problem in a smaller test case. So I don't know why the fix works, of if we were just lucky, and the underlying problem remains. I'll have the opportunity to investigate this further next week - any suggestions for how to approach this welcome.

The proposed patch replaces all calls to @sort@ by calls to @stable_sort@. Please pull it from branch stable-sort at git://github.com/jeremybennett/verilator.git.