Stats

  • Locked Locked
  • Replies 3
  • Subscribers 125
  • Views 6132
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

the same extraction view got netlisted differently in 2 different test setup

a048

Hi, there.

I've got an instances i_1 (cell_1) in testbench test_1 and and i_2(cell_2) in testbench test_2.

cell_2 has some minor differences from cell_1 but their symbols/pins are exactly the same (for this reason I have copied the extraction view from cell_1 to cell_2 for debug simulation purpose).

The setup of test_1 is 2 years older than test_2 and they are a bit different, but for all the inputs (reg settings and differential clk inputs) of i_1 in test_1 and all the inputs of i_2 in test_2 are almost exactly the same (with only a few mV of differences on analog vdd/vss). But I'm observing about 40 mV of cml Vp swing difference between i_1 and i_2 outputs.

Basically I'm simulating two different cells in 2 different testbenches, but configured with the exact same extraction view and fed with the same inputs and their output swings are quite different.

After comparing some of the exact same instances in the extraction netlist, since the extraction netlist seems the only thing that could introduce the difference, I saw an extra parameter cps=0.15 and another parasiticL=3.25 present in test_1 but not in test 2 as shown in the pic below.

So my questions are -

Are these parameters used for simulations or they just got printed out but not used?

Are these common modeling parameters or pdk related parameters that cadence forum users are not familiar with?

Can they possibly add more parasitics and reduce output swings?

What could cause the extra parameters being netlisted in test_1 but not in test_2? Which of the log files could I try to look into?

These extra parameters are the only things I can find that might have introduced such difference on output swings. If they're not the root cause, what else could be, knowing it's the same extraction view fed with the same inputs that's being simulated?

Thanks

 

  • Please contact customer support (submit a support case after logging in). These are all PDK-specific and possibly design-specific and so we'd need to see more info (versions, PDK, PDK versions, and probably the data itself) to understand what's going on.

    Regards,

    Andrew 

  • Hi,

    It was a hierarchy editor setup issue and was resolved last week. The output swing difference was caused by the extra netlist parameter parasiticL from RES_ZTC_PW, which is a subcell of the same extraction used in test_1 and test_2.

    In the higher swing test_1, the Inherited View List of RES_ZTC_PW is used as spectre schematic_empty $sch veriloga (in black), so when I use the extraction view for the top cell cell_1 that contains RES_ZTC_PW, RES_ZTC_PW will automatically inherit $assura used for its top cell and netlist with schemAssuraPost, which doesn’t contain parasiticL as part of its expression.

    In the lower swing test test_2, the Inherited View List of RES_ZTC_PW is used as spectre $sch veriloga (in blue), because when I tried to delete the schematic_empty view from the Inherited View List spectre schematic_empty $sch veriloga, I did Set View List as spectre $sch veriloga (in blue), which will force the RES_ZTC_PW to incorrectly netlist with $schm, instead of inheriting $assura used for its top cell cell_2. So if I had directly deleted schematic_empty from spectre schematic_empty $sch veriloga and leave it as black (which was exactly what I did for the higher swing test_1 two years ago), RES_ZTC_PW would've inherited $assura used for its top cell and correctly netlisted with schemAssuraPost. 

    Feel like I should've done more debug on my end before posting this one on the forum...

    Thanks

  • in reply to a048

    Just want to make a very quick correction… earlier I mentioned if I directly deleted schematic_empty from RES_ZTC_PW Inherited View List spectre schematic_empty $sch veriloga, it might be left as black, which I just realized was not true…  it’ll actually end up being blue too, forcing RES_ZTC_PW to incorrectly netlist with $schm when its top level extraction is using $assura. So the correct thing (which is what I think I really did two years ago for the higher swing test) should be not touching and leaving RES_ZTC_PW Inherited View List as spectre schematic_empty $sch veriloga in black such that RES_ZTC_PW will inherit $assura used for its top cell and correctly netlist with schemAssuraPost.

    Thanks

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.