Setting correct top module when parsing netlist from Lattice

[jacobdbrown4]

A netlist output by the lattice tools (Synplify Pro specifically. It's actually a third party synthesis tool that can be used in lattice) lists the top module last in the netlist. SpyDrNet assumes the top module to be the first in the netlist so things get messed up when it isn't. I'm working on a fix for this. Shouldn't be too bad but I wanted to document.

[jacobdbrown4]

There may be an option to fix this in Synplify Pro. I'll look at that.

Even if I can fix it in Synplify Pro, it may be good to make SpyDrNet "smarter" and be able to find out the correct hierarchy when parsing.

[jacobdbrown4]

I fixed the problem.

Now during Verilog netlist parsing, if a definition instances something that was supposedly the top instance, it updates the top instance to that definition. It won't blindly update the top instance, however. If that new potential top instance is being instanced by another definition, it'll consider that definition as the new should-be top instance. It'll climb the ladder until we find a new top.

The example netlist three_layer_hierarchy lists all the modules in a random order. Before, hierarchy was all messed up, but now it should be fixed.

I've tested it and it seems to work great. I've added a test to the pytests as well.

In short, hierarchy should be accurate no matter the order that modules are listed in a Verilog netlist.

[ganeshgore]

@jacobdbrown4
This is a very nice feature. What is the expected behavior if there are multiple top-level modules or some unused modules in the netlist?

[jacobdbrown4]

@ganeshgore
That's a good question, I hadn't thought of that. I believe unused modules are simply parsed in, added to the library, and then composed out without a problem. If there are multiple top modules, I guess one would be made into the top. Maybe it would be better for spydrnet to not assume a top module but rather wait to be told which module to set as the top? Or maybe spydrnet could assume a top module but then provide a flexible way to change which module is the top among multiple potential top modules. This may already work okay, but it's something to look into.