Stats

  • Locked Locked
  • Replies 9
  • Subscribers 125
  • Views 19022
  • 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

LVS does not accept proper termOrder

Kabal

This problem differentiates from another post, but it is more relevant to termOrder case, thats why I created separate this thread.

The problem is that during LVS I get a lot of pin mismatches, however; according to the CDL netlist for LVS all the schematic-to-pin connection in the top cell are correct.

Again, I have one cell with layout view generated before, and with a auCdl view as a symbol. So it has just two views, layout and auCdl. The name of that cell with two views is refleks_switcher. I instantiate the auCdl view of refleks_switcher cell in another top level cell called refleks_switcher_wrapper. 

After that, I export the CDL netlist for LVS. Then I go ahead and create another layout, that layout is basically a wrapper layout, I just instantiate refleks_switcher layout view and then add ports with "_top<N>" suffix in them, where N is just number of each individual port. 

Then I perform the LVS of the top layout view, and get a lot of pin mismatch errors. For example something like this:

Pin           SchNet                      : LayNet
---             ------                           : ------
rst            pwm_ctrl_top              : rst_top
pwm_ctrl   pwm_out_top<0>        : pwm_ctrl_top

This does not make any sense! If you look at the attached CDL netlist file, you will see that the cell refleks_switcher or XI19 is connected properly pin-by-pin according to SUBCKT and PININFO statements! and same goes for layout! I have no idea why this tools acting crazy!

 


I am attaching 5 files in this and next posts:

cdf_properties.png - snapshot of refleks_switcher CDF properties, where you can clearly see my termOrder defined.
schematic_top.png - snapshot of schematic in top cell called refleks_switcher_wrapper with the auCdl view of refleks_switcher cell
refleks_switcher_wrapper.netlist.lvs - a CDL file produced from top schematic for LVS.
cdf_dump.txt - CDF dump of refleks_switcher cell
lvs_output.txt - an LVS output which shows pin errors.

 

 

Parents

  • I partially figured out the problem.. The biggest problem was in < > [ ] bus expansion symbols!! 
    The thing is, layout was generated from Verilog, and there busses had to be with [, but in auCdl and higher level block I used <> 

    So there is an option to change <> to [ during CDL generation, I used that option and it changed <> to [, however; for some reason all VDD! and GND! nets lost their ! symbol, and just became VDD and GND. So I had to manually correct for that.

    I hate to say this but this software has tons of bugs! And sometimes its just "anything goes" principle which works out. 

    Anyway, the reason I am saying problem is partially solved is because CDF temOrder is still not being respected by netlister. 
    In this post, I am attaching the manually corrected final CDL netlist for which LVS worked out without errors.

    You can see that the ports and busses for instance XI19 have a different term order than in the CDF properties window attached in previous posts. But that is a combination which worked! And also, note, that it is NOT in alphabetical order! 

    In the top layout, I connected each port pin to corresponding xxx_top[N] pin, where N is a right number. (also, layout has [ for pins belonging to buss).

    Now what should I make out of it? If someone can notice some errors I would like to know them.

    Let me actually be even more precise: It's not that the order which I set in CDF property editor line does not appear, its just I do not know what order to write there.

    For example, if I write some term order in that CDF window in the auCdl line, it will appear in exactly same order in XI19 instance in netlist file during netlisting.

    The real problem is, that I do not know which order will work out and I have to guess it to find the one which works and results in successful LVS.

    refleks_switcher_wrapper.netlist.zip
Reply

  • I partially figured out the problem.. The biggest problem was in < > [ ] bus expansion symbols!! 
    The thing is, layout was generated from Verilog, and there busses had to be with [, but in auCdl and higher level block I used <> 

    So there is an option to change <> to [ during CDL generation, I used that option and it changed <> to [, however; for some reason all VDD! and GND! nets lost their ! symbol, and just became VDD and GND. So I had to manually correct for that.

    I hate to say this but this software has tons of bugs! And sometimes its just "anything goes" principle which works out. 

    Anyway, the reason I am saying problem is partially solved is because CDF temOrder is still not being respected by netlister. 
    In this post, I am attaching the manually corrected final CDL netlist for which LVS worked out without errors.

    You can see that the ports and busses for instance XI19 have a different term order than in the CDF properties window attached in previous posts. But that is a combination which worked! And also, note, that it is NOT in alphabetical order! 

    In the top layout, I connected each port pin to corresponding xxx_top[N] pin, where N is a right number. (also, layout has [ for pins belonging to buss).

    Now what should I make out of it? If someone can notice some errors I would like to know them.

    Let me actually be even more precise: It's not that the order which I set in CDF property editor line does not appear, its just I do not know what order to write there.

    For example, if I write some term order in that CDF window in the auCdl line, it will appear in exactly same order in XI19 instance in netlist file during netlisting.

    The real problem is, that I do not know which order will work out and I have to guess it to find the one which works and results in successful LVS.

    refleks_switcher_wrapper.netlist.zip
Children
No Data

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.