• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Digital Implementation
  3. First Encounter pin placement/layer

Stats

  • Locked Locked
  • Replies 9
  • Subscribers 91
  • Views 7938
  • 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

First Encounter pin placement/layer

archive
archive over 17 years ago

Hi there,

can anyone tell me how to make Encounter place pins on restricted layers, for example on metals 1 & 2 only. Ultimately i'd like my pins placed on a given boundary edge & in a pre-determined order.

Thanks

Stu

p.s I'm actually an alaog layout guy using Encounter (for the first time) to place and route a large digital block in an analog chip. Apologies for the simple Q's, there will be more.


Originally posted in cdnusers.org by sreilly
  • Cancel
Parents
  • Kari
    Kari over 17 years ago

    Hi Kul,

     Using "1" for the specifyCellPad factor is not doing you much good. If you recall from the docs, the factor is multiplied by the metal2 pitch in the LEF file. A standard buffer in your library could be 10 or so metal2 pitches, so you would want to use 10 instead of 1. (Just an example. Pick the buffer you'd like space reserved for, and divide its length by your metal2 pitch. Then use that number.)

    I think you're onto something with the dont_use and fanout. Typically, we will set_dont_use the really low-strength buffers and a couple of really high-strength ones for general optimization. Then for CTS, we specify in the .ctstch file a small list of buffers/inverters to use. As for fanout, I'm not sure if setting a max_fanout in the sdc file will override what's in the .lib; usually the more restrictive option will take precedence, but we need to look that up to be sure. It's unlikely that the fanouts of your buffers really need to be restricted to 1. Can you ask the vendor about that?

    It is recommended to route the clock nets during CTS. The optAddBuffer option is only relevant if you're doing postOpt - please check out the user guide for more about these options.

    For your io file issue, could you explain more or post a picture? What you are trying to do should work, but we need to figure out why the numbers don't match what you expect.

    - Kari 

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Kari
    Kari over 17 years ago

    Hi Kul,

     Using "1" for the specifyCellPad factor is not doing you much good. If you recall from the docs, the factor is multiplied by the metal2 pitch in the LEF file. A standard buffer in your library could be 10 or so metal2 pitches, so you would want to use 10 instead of 1. (Just an example. Pick the buffer you'd like space reserved for, and divide its length by your metal2 pitch. Then use that number.)

    I think you're onto something with the dont_use and fanout. Typically, we will set_dont_use the really low-strength buffers and a couple of really high-strength ones for general optimization. Then for CTS, we specify in the .ctstch file a small list of buffers/inverters to use. As for fanout, I'm not sure if setting a max_fanout in the sdc file will override what's in the .lib; usually the more restrictive option will take precedence, but we need to look that up to be sure. It's unlikely that the fanouts of your buffers really need to be restricted to 1. Can you ask the vendor about that?

    It is recommended to route the clock nets during CTS. The optAddBuffer option is only relevant if you're doing postOpt - please check out the user guide for more about these options.

    For your io file issue, could you explain more or post a picture? What you are trying to do should work, but we need to figure out why the numbers don't match what you expect.

    - Kari 

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information