netgen
netgen copied to clipboard
RTimothyEdwards
Tool is Wrongly mapping same module two time.
Design/Spice netlist have one instance of "u_core.u_skew_wi", "u_core.u_skew_wh", "u_core.u_skew_uart", "u_core.u_skew_spi", "u_core.u_skew_sdram", "u_core.u_skew_sd_ci", "u_core.u_skew_riscv", "u_core.u_skew_glbl",
But Tool reporting it is one more time defining it as "skew_adjustu_core.u_skew_uart", "skew_adjustu_core.u_skew_sd_ci", "skew_adjustu_core.u_skew_sdram", "skew_adjustu_core.u_skew_glbl", "skew_adjustu_core.u_skew_spi", "skew_adjustu_core.u_skew_riscv", "skew_adjustu_core.u_skew_wi", "skew_adjustu_core.u_skew_wh",
Look like it's once again appending Module name with instance.
Attached the complete setup. Run command is : run_cmd All Inputs are inside input directory. exp4.tar.gz
This is not "wrong". Based on typical/historical schematic-derived netlists, the devices would typically be "X1", "X2", etc.; to provide information about the instance "1" in a meaningful way, the subcircuit or device name is put in front, e.g., "nmos1". In the case where tools make complicated hierarchical instance names, the output looks a little strange, but it is following the same format.
Hi RT Edward
I feel there is some issue in the LVS logic, it sometimes shows there is mismatch in Pin Difference between RTL and Spice netlist. Here is a failure log's extract.
Subcircuit pins: Circuit 1: spim_top |Circuit 2: spim_top
-------------------------------------------|------------------------------------------- spi_debug[19] |(no matching pin)
spi_debug[18] |(no matching pin)
spi_debug[20] |(no matching pin) io_oeb[3] |(no matching pin) ... (no matching pin) |io_in[1]
(no matching pin) |io_in[0]
(no matching pin) |io_oeb[3]
(no matching pin) |spi_debug[20]
(no matching pin) |spi_debug[19]
(no matching pin) |spi_debug[18]
Even though "spi_debug[19],spi_debug[18],spi_debug[20],io_oeb[3]" are matching each other, it reports as unmatched.
Regarding io_in[0] & io_in[1] there are unused input ports. Not sure why it reports as mismatch, I see port declarations in both RTL and Spice.
I see tools also report that they are disconnected nodes .. Cell spim_top disconnected node: io_in[0] Cell spim_top disconnected node: io_in[1]
Cell spim_top disconnected node: io_in[1] Cell spim_top disconnected node: io_in[0]
Not clear on reason for LVS failure, Attached the complete Setup with input data. Run command: run_cmd
Let me know if you see any real issue in design or SPICE netlist OR we should avoid unused port declaration ?
-Thanks Dinesh.A
On Thu, Jul 1, 2021 at 12:59 AM R. Timothy Edwards @.***> wrote:
This is not "wrong". Based on typical/historical schematic-derived netlists, the devices would typically be "X1", "X2", etc.; to provide information about the instance "1" in a meaningful way, the subcircuit or device name is put in front, e.g., "nmos1". In the case where tools make complicated hierarchical instance names, the output looks a little strange, but it is following the same format.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/RTimothyEdwards/netgen/issues/20#issuecomment-871670152, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7HAVUZZJ262XC7KUHNQLTTVNWALANCNFSM47SX5MYA .
Tried one more experimenting with removing 2 un-used input.
Still LVS fails here is failure looks
Subcircuit pins: Circuit 1: spim_top |Circuit 2: spim_top
-------------------------------------------|-------------------------------------------
spi_debug[18] |(no matching pin) spi_debug[19] |(no matching pin) spi_debug[20] |(no matching pin) io_oeb[3] |(no matching pin) (no matching pin) |io_oeb[3]
(no matching pin) |spi_debug[20]
(no matching pin) |spi_debug[19]
(no matching pin) |spi_debug[18]
Attached the test setup for your reference.
On Wed, Jul 7, 2021 at 2:50 PM Dinesh A @.***> wrote:
Hi RT Edward
I feel there is some issue in the LVS logic, it sometimes shows there is mismatch in Pin Difference between RTL and Spice netlist. Here is a failure log's extract.
Subcircuit pins: Circuit 1: spim_top |Circuit 2: spim_top
-------------------------------------------|------------------------------------------- spi_debug[19] |(no matching pin)
spi_debug[18] |(no matching pin)
spi_debug[20] |(no matching pin) io_oeb[3] |(no matching pin) ... (no matching pin) |io_in[1]
(no matching pin) |io_in[0]
(no matching pin) |io_oeb[3]
(no matching pin) |spi_debug[20]
(no matching pin) |spi_debug[19]
(no matching pin) |spi_debug[18]
Even though "spi_debug[19],spi_debug[18],spi_debug[20],io_oeb[3]" are matching each other, it reports as unmatched.
Regarding io_in[0] & io_in[1] there are unused input ports. Not sure why it reports as mismatch, I see port declarations in both RTL and Spice.
I see tools also report that they are disconnected nodes .. Cell spim_top disconnected node: io_in[0] Cell spim_top disconnected node: io_in[1]
Cell spim_top disconnected node: io_in[1] Cell spim_top disconnected node: io_in[0]
Not clear on reason for LVS failure, Attached the complete Setup with input data. Run command: run_cmd
Let me know if you see any real issue in design or SPICE netlist OR we should avoid unused port declaration ?
-Thanks Dinesh.A
On Thu, Jul 1, 2021 at 12:59 AM R. Timothy Edwards < @.***> wrote:
This is not "wrong". Based on typical/historical schematic-derived netlists, the devices would typically be "X1", "X2", etc.; to provide information about the instance "1" in a meaningful way, the subcircuit or device name is put in front, e.g., "nmos1". In the case where tools make complicated hierarchical instance names, the output looks a little strange, but it is following the same format.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/RTimothyEdwards/netgen/issues/20#issuecomment-871670152, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7HAVUZZJ262XC7KUHNQLTTVNWALANCNFSM47SX5MYA .
If netgen lists the same pin on each side with "(no matching pin)", then it means that the pin names are connected to different nets. The names match, but the netlists don't.
From my netlist review, I see these failing pins are having multiple fan-in/fan-out.
Is it possible to add additional debug message on which are the different net connected to these failing pins.
I don't see STA tool reporting any issue while reading netlist vs spice. Which means there is no invalid connectivity/Timing Arc.
When total number nets & pins are matching + STA not reporting issue. I feel issue is more related to netgen handling multi fan-in/fan-out pins.
As a experiment, on the failing three pins i added a Buffer towards the Pins. Now i don't see LVS failure on these Pins. I assume this is not the correct method to fix the LVS.
Let me know your view.