Stats

  • Locked Locked
  • Replies 9
  • Subscribers 144
  • Views 19456
  • 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

Question on Schematic Porting from X-Foundry PDK to Y-Foundry PDK

yjwu

Hi,

I am trying to make a schematic conversion from X-Foundry PDK to Y-Foundry PDK.

I found the skill codes "abConvertComponentParams" by Andrew very helpful.

However, I have two questions below that would need some quidences:

(1) How to remove unwanted CDF properties in the original symbol of X-Foundry?

     After the skill code conversion, some CDF properties become user properties in the new symbol.

     Those proporties are specific to X-Foundry and it would be better to remove them during the conversion.

     Specifically, it would be even better to just map the parameters specified in "conv.config" only and remove all other parameters. 

(2) How to map a parameter type of "string" to type "integer"?

     The example fixIt procedure seemed to return a string and caused the following warning message:

      *WARNING* Invalid type (string) for property 'segments' on instance 'R1'

Any help/suggestions would be much appreciated.

Thanks.

Ethan

Parents

  • aelSuffixNotation has its uses (probably aelNumber() is more useful in this context though), but I'd use cdfParseFloatString as a matter of good practice. The benefit of cdfParseFloatString is that it's in all executables - so is also "pcell safe", whereas aelSuffixNotation/aelNumber is not in dbAccess, the stream interfaces and so on, because it's ADE-related. Not a big issue for your application, but if you get into the habit of using cdfParseFloatString you won't be surprised.

    I always advise against using evalstring. One it's using run-time evaluation, but more importantly if the string happens to contain a bit of SKILL code, you may not get what you get. For example, if the string happens to contain "(exit)"...

    Regards,

    Andrew.

Reply

  • aelSuffixNotation has its uses (probably aelNumber() is more useful in this context though), but I'd use cdfParseFloatString as a matter of good practice. The benefit of cdfParseFloatString is that it's in all executables - so is also "pcell safe", whereas aelSuffixNotation/aelNumber is not in dbAccess, the stream interfaces and so on, because it's ADE-related. Not a big issue for your application, but if you get into the habit of using cdfParseFloatString you won't be surprised.

    I always advise against using evalstring. One it's using run-time evaluation, but more importantly if the string happens to contain a bit of SKILL code, you may not get what you get. For example, if the string happens to contain "(exit)"...

    Regards,

    Andrew.

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.