First, we move inline verilog to the end of the module, as it was done before. This simplifies regression tests for existing code and shouldn't affect any new code.
Next, we sort the inline verilog strings by the instance name, this allows us to preserve the original order of the code generator (since it generates instances names in order). The reason for this is there is existing code that relies on the order in which inline verilog nodes are code generated (For example, one inline verilog node opens an if def, then subsequent ones insert code, and a final node closes the ifdef). Since coreir instances are a generic graph that don't have a notion of ordering, and because we code generate by tracing from outputs, this seems like the simplest way to preserve the ordering. When we move to more explicit verification nodes in the graph, this won't be an issue since they should be self contained, but the existing inline verilog code relies on this ordering behavior.
First, we move inline verilog to the end of the module, as it was done before. This simplifies regression tests for existing code and shouldn't affect any new code.
Next, we sort the inline verilog strings by the instance name, this allows us to preserve the original order of the code generator (since it generates instances names in order). The reason for this is there is existing code that relies on the order in which inline verilog nodes are code generated (For example, one inline verilog node opens an if def, then subsequent ones insert code, and a final node closes the ifdef). Since coreir instances are a generic graph that don't have a notion of ordering, and because we code generate by tracing from outputs, this seems like the simplest way to preserve the ordering. When we move to more explicit verification nodes in the graph, this won't be an issue since they should be self contained, but the existing inline verilog code relies on this ordering behavior.