A "netlist" is, as it's name implies, "a list of nets". But such a list can be given in various formats or for use by various tools/processes. A "Spice netlist" is in the Spice language (also Spectre or other Spice-like languages). This implies that it consists of devices, such as transistors, resistors and capacitors and the nets that connect between them. This is as opposed to a "gate-level netlist" (or often, a "Verilog netlist"), which doesn't usually go down to the transistor level, but stops at the gate level. So you would have a list of inverters, NAND/NOR gates, etc. at the lowest abstraction level.
Hi Prof, so with the problem2 #Assigns in netlist, should'nt we have assign statement in our netlist, and if it is there, what fails in our LVS, can u pls explain?
Hi, It's hard to say exactly what and why this type of failure happens, but it causes problems across tools and versions. I think that a lot of "black magic" happens because we use different tools and scripts (often from different vendors) for different parts of the flow and these have hidden bugs that are hard to clean up since there are so many options used by different chip designers. But the bottom line is that assigns in your netlist are just looking for trouble. Remember, the netlist should be a list of gates - no behavioral code. And an assign is - in essence - behavioral. Some tools leave them in the netlist as a way to connect two wires as opposed to just renaming the net so all connected wires will have the same name. But LVS can get screwed up because of this. I think the most critical problem that I have seen and can describe is when you have several inputs that are shorted together, as I showed in the video. LVS treats inputs as anchors for checking the design and this is probably the root of the problem. Bottom line - get rid of the assigns or you may spend many frustrating hours trying to figure out what the heck happened.
![Shenseea - Dating Szn (Options) [Official Music Video]](http://i.ytimg.com/vi/eUePmZFIXUg/mqdefault.jpg)
It's amazing, Prof. Thanks a lot
Glad you like it!
thanks Prof its insightful
Glad it was helpful!
Hi,
Can you please tell me the difference between verilog netlist and spice netlist?
A "netlist" is, as it's name implies, "a list of nets". But such a list can be given in various formats or for use by various tools/processes. A "Spice netlist" is in the Spice language (also Spectre or other Spice-like languages). This implies that it consists of devices, such as transistors, resistors and capacitors and the nets that connect between them. This is as opposed to a "gate-level netlist" (or often, a "Verilog netlist"), which doesn't usually go down to the transistor level, but stops at the gate level. So you would have a list of inverters, NAND/NOR gates, etc. at the lowest abstraction level.
Hi Prof, so with the problem2 #Assigns in netlist, should'nt we have assign statement in our netlist, and if it is there, what fails in our LVS, can u pls explain?
Hi,
It's hard to say exactly what and why this type of failure happens, but it causes problems across tools and versions. I think that a lot of "black magic" happens because we use different tools and scripts (often from different vendors) for different parts of the flow and these have hidden bugs that are hard to clean up since there are so many options used by different chip designers.
But the bottom line is that assigns in your netlist are just looking for trouble. Remember, the netlist should be a list of gates - no behavioral code. And an assign is - in essence - behavioral. Some tools leave them in the netlist as a way to connect two wires as opposed to just renaming the net so all connected wires will have the same name. But LVS can get screwed up because of this.
I think the most critical problem that I have seen and can describe is when you have several inputs that are shorted together, as I showed in the video. LVS treats inputs as anchors for checking the design and this is probably the root of the problem.
Bottom line - get rid of the assigns or you may spend many frustrating hours trying to figure out what the heck happened.
@@AdiTeman Tnks prof.