Stats

  • Locked Locked
  • Replies 3
  • Subscribers 143
  • Views 1619
  • 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

Hierarchy editor for netlisting w/o modifying CDF

tito80

Problem statement is:

===========================

User would provide i/p in hierarchy editor on an instance-basis (Tree view) through an user-introduced property (Edit-->Add property column). And during netlisting, I need to read that property and instantiate that instance to my_subckt. Else usual descend and netlisting as per set view. Also, the property need not propagate hierarchically for child instances.

 Now, I understand this can be achieved in the CDF way, too:

 

===============================

1) Introduce CDF property "model" (base/user/effective) for the cell. Set it to default "my_subckt".

2) Create a new view out of symbol view (say my_spectre view)

3) Put my_spectre view in the stop and view lists in the config.

4) Change the particular instance desired to my_spectre view

But say I don't want it to do it that way since I don't want to create new views or introduce new CDF properties for almost every cell in the library, etc. since -- (a) I have to create my_spectre view on-the-fly for that instance's master (b) If I want to change base CDF, I do not have write permissions (c) Even if I achieve (a) or (b) [through local copies, effective CDFs, etc.], things might just not scale for bigger and bigger blocks.

 

So is custom netlisting routine the only way? If so, some pointer would be helpful for this kind of problem statement:

 

For any instance, read a hierarchy editor property (say my_prop) --> If my_prop=a, introduce my_subckt for model/subckt defintion. Else, if my_prop=<nothing>/b, fall back to usual netlisting.

Any help would be greatly appreciated for this custom IC SKILL problem.

Regards,

Tito 

Parents
  • tito80

    Andrew, sure --- Let me give you some background on the bigger problem statement (caters to some timing needs one level up). 

    In an analog hierarchical design, say I have total of "Tot" instances. I am trying to have some of them expanded (say "Some" instances) and netlisted in the usual manner. And all other instances need to be blackboxed (i.e. not descend into them) -- say "BB" instances. Now,

    1) The design schematics should not be edited

    2) We do not want to introduce and maintain cell copies for space issues, more so since they are large hierarchical desings. Also, "Some" << "BB". 

    3) We do not want to introduce new "my_view" views since mastercells for "BB" is pretty large (encompassing lot of std cell and template libraries).

    Summarizing, since we do not want to pursue the CDF-->modelname path through new view, etc., what might be a good alternative path?This is one solution that comes to my mind. Anything else would be really appreciated. 

    Regards,

    Tito 

Reply
  • tito80

    Andrew, sure --- Let me give you some background on the bigger problem statement (caters to some timing needs one level up). 

    In an analog hierarchical design, say I have total of "Tot" instances. I am trying to have some of them expanded (say "Some" instances) and netlisted in the usual manner. And all other instances need to be blackboxed (i.e. not descend into them) -- say "BB" instances. Now,

    1) The design schematics should not be edited

    2) We do not want to introduce and maintain cell copies for space issues, more so since they are large hierarchical desings. Also, "Some" << "BB". 

    3) We do not want to introduce new "my_view" views since mastercells for "BB" is pretty large (encompassing lot of std cell and template libraries).

    Summarizing, since we do not want to pursue the CDF-->modelname path through new view, etc., what might be a good alternative path?This is one solution that comes to my mind. Anything else would be really appreciated. 

    Regards,

    Tito 

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.